TL;DR

An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc).
The Twelve-Factor App

Storing the often changing parts of configuration in environment variables is
one of the principles of The Twelve-Factor App.

From this principle follows the need to:

1. ensure that all the required environment variables are set with
   appropriate values, and

2. store those environment variables and their values in easily accessible ways suitable both for development and for running in production.

Both are typical DevOps problems. To help solve them, use Env::Assert and Env::Dot, two programs which, while doing two very different things, are designed to work in unison.

Env::Assert

Env::Assert was born from frustration. One too many times:

$ PLAEC='Stockholm'
$ if [[ "$PLACE" == '' ]]; then echo "Normal OK"; fi
OK

... And the program fails with no errors!

Not quite what we want!

Another example, from a real life Docker execution script:

perl -Ilib bin/repos-gh-yaml.pl --verbose         \
    | perl -Ilib bin/repos-yaml-csv.pl --verbose  \
    | az storage blob upload --data @-            \
        --content-type 'text/csv'                 \
        --content-encoding 'UTF-8'                \
        --content-language 'en_US'                \
        --name "$blob_name"                       \
        --container "$CONTAINER_NAME"             \
        --account-name "$AZURE_STORAGE_ACCOUNT"   \
        --sas-token "$AZURE_STORAGE_SAS_TOKEN"

If the environment variables are wrongly set, or not set at all, it won't become evident until after the run has started. It could take hours before the run reaches the point when they are used.

Describe The Environment

Env::Assert, or rather the executable envassert, that comes with it provide an easy way to find out if the environment variables are what we require them to be.

envassert is a CLI command to assert that your environment variables match your Environment Description.

Envdesc or Environment Description is a way to describe which environment variables are required by your program.

Environment Description is written in a file. Default file name is .envdesc.

.envdesc actually looks a lot like a .env file, except instead of
defining variables and their content, it defines regular expressions
which control the variables' content. These regexps are Perl's
extended regular expressions (m/<regexp>/msx).

Example .envdesc:

CONTAINER_NAME=^[a-z0-9-]{1,}$
AZURE_STORAGE_ACCOUNT=^[a-z0-9]{1,}$
AZURE_STORAGE_SAS_TOKEN=^[?].*$
GITHUB_TOKEN=^[[:word:]]{1,}$

In normal circumstances, envassert only verifies the variables that you specifically describe. If you want more control over your environment, there is the meta command envassert (opts: exact=1)
which will make envassert also assert that the environment doesn't contain any unknown variables.

## envassert (opts: exact=1)
USER=^username$
HOME=^/home/username$
PATH=^/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin$

Running Env::Assert

You can create an airtight environment description to verify environment variables in both test and production. Just run envassert as the first command during container execution or any script run:

envassert --env-description /home/me/.envdesc \
    || ( echo 'Break execution ...' 1>&2 && exit 1 )

If it detects problems, envassert will report errors and exit with an error, e.g.:

$ envassert
Environment Assert: ERRORS:
    variables:
        FIRST_VAR: Variable FIRST_VAR is missing from environment
        FOURTH_VAR: Variable FOURTH_VAR has invalid content

Running Self-Contained

A .envdesc file is really convenient for a bigger app which may have many disconnected parts and execution scripts. But if you have only a single script which nevertheless is dependent on having certain predefined environment variables, you can also include the .envdesc file in the script. An example:

#!/usr/bin/env sh
envassert --stdin <<'EOF' # Ensure the required environment.
NUMERIC_VAR=^[[:digit:]]+$
TIME_VAR=^\d{2}:\d{2}:\d{2}$
EOF
echo "${NUMERIC_VAR}: ${TIME_VAR}"

Using Env::Assert in a Program

Env::Assert is a Perl language module. If your application is a Perl script or package, you can also call Env::Assert directly in the code.

If you know you will always have a .envdesc file in the working directory, call:

use Env::Assert 'assert';

But it would probably be better to specify the Environment Description file. Other parameters are also available. break_at_first_error will make Env::Assert to only report the first error it detects:

use Env::Assert assert => {
    envdesc_file => 'another-envdesc',
    break_at_first_error => 1,
};

Inlining the description file is also possible:

use Env::Assert assert => {
    exact => 1,
    envdesc => <<'EOF'
NUMERIC_VAR=^[[:digit:]]+$
TIME_VAR=^\d{2}:\d{2}:\d{2}$
EOF
};

Env::Dot

Env::Dot is the other piece of the puzzle, the one which will provide the environment repeatably and reliably.

There is plenty of existing DotEnv solutions. Env::Dot, however, can offer a few unique features. The .env files are treated more like source files, not as ready shell (Unix standard sh or Bash) files. With meta commands user can specify if the .env file is compatible with shell or is written in the more limited format that Docker is using:

For standard shell:

# envdot (file:type=shell)
VAR="value"

For Docker:

# envdot (file:type=plain)
VAR=My var value

You can chain .env files. When seeing meta command read::from_parent**Env::Dot** will search for another.env` file in any parent directory. It will load the first .env file it finds from the current directory upwards to root. If you have several applications in different subdirectory which share some environment variables but also have some unique ones, you can place the common ones in the parent directory and refer to it:

# envdot (read:from_parent)
DIR_VAR="dir"
COMMON_VAR="dir"

Env::Dot uses environment variable ENVDOT_FILEPATHS to read dotenv files located somewhere else than in the current work dir. You can specify several file paths; just separate them by ":". Env::Dot will load the files in the reverse order, starting from the last. This is the same ordering as used in PATH variable: the first overrules the following ones, that is, when reading from the last path to the first path, if same variable is present in more than one file, the later one replaces the one already read.

If you are using Windows, separate the paths by ";"!

For example, if you have the following directory structure:

project-root
| .env
+ - sub-project
  | .env

and you specify ENVDOT_FILEPATHS=project-root/sub-project/.env:project-root/.env, then the variables in file project-root/.env will get replaced by the more specific variables in project-root/sub-project/.env.

In Windows, this would be ENVDOT_FILEPATHS=project-root\sub-project\.env;project-root\.env

Env::Dot Executable

Use executable envdot to bring the variables into your shell.
The executable is distributed together with Env::Dot package.

envdot supports the following Unix shells: sh and its derivatives, including bash and ksh, csh and its derivative tcsh', and fish`.

Normally the variables are created in a way that also exports them into any subsequent programs which are run in the same shell, i.e. they become environment variables. However, envdot can also create them as simple variables only for the current process.

Examples of usage:

eval `envdot --no-export --shell csh`
eval `envdot --dotenv subdir/.env`
ENVDOT_FILEPATHS='../.env:subdir/.env:.env' eval `envdot`

Using Env::Dot in a Program

Env::Dot is a Perl language module. If used in code, having the .env file is not mandatory. By default, Env::Dot will do nothing if there is no .env file. You can also configure *Env::Dot * to break execution if there is no .env file.

# If your dotenv file is `.env` or there is no `.env` file:
use Env::Dot;

# If you have a dotenv file in a different filepath:
use Env::Dot read => {
    dotenv_file => '/other/path/my_environment.env',
};

# When you absolutely require a `.env` file:
use Env::Dot read => {
    required => 1,
};

Existing environment variables always take precedence to dotenv variables. A dotenv variable (variable from a file) does not overwrite an existing environment variable. This is by design because
a dotenv file is to augment the environment, not to replace it. This means that you can override a variable in .env file by creating its counterpart in the environment.

An example of how that works in a normal shell:

#!/usr/bin/env sh
unset VAR
echo "VAR='Good value'" >> .env
perl -e 'use Env::Dot; print "VAR:$ENV{VAR}\n";'
# VAR:Good value
VAR='Better value'; export VAR
perl -e 'use Env::Dot; print "VAR:$ENV{VAR}\n";'
# VAR:Better value

If your .env file(s) contain variables which need interpolating,
for example, to combine their value from other variables or execute a command to produce their value, you have to use the envdot program. Env::Dot does not do any interpolating. It cannot because that would involve running the variable in the shell context within the calling program.

Env::Assert And Env::Dot

If you are in the habit of using .env files, .envdesc complements it. Commit your .envdesc file into your repository and it will act as a template for user or developer to create his/her .env file which should not be committed into Git anyway.

• Env::Assert
• Env::Dot
• The Twelve-Factor App

Leveraging Gemini CLI and the underlying Gemini LLM to build Model Context Protocol (MCP) AI applications in Perl with a local development environment.

Why not just use Python?

Python has traditionally been the main coding language for ML and AI tools. One of the strengths of the MCP protocol is that the actual implementation details are independent of the development language. The reality is that not every project is coded in Python- and MCP allows you to use the latest AI approaches with other coding languages.

Perl? Is that even a language anymore?

The goal of this article is to provide a minimal viable basic working MCP stdio server in Perl that can be run locally without any unneeded extra code or extensions.

The Perl MCP module is here:

MCP-0.06

What Is Perl?

Perl is a general-purpose, high-level programming and scripting language, primarily known for its powerful text manipulation capabilities. Originally created by Larry Wall in 1987 for easier report processing, it has evolved to be used for a wide range of tasks, including system administration, web development, and network programming.

The main site for Perl is :

The Perl Programming Language - www.perl.org

Installing Perl

The step by step instructions vary by platform- for a basic Debian system here are the steps:

sudo apt-get install perl cpanminus

xbill@penguin:~/gemini-cli-codeassist/mcp-stdio-perl$ perl --version

This is perl 5, version 36, subversion 0 (v5.36.0) built for x86_64-linux-gnu-thread-multi
(with 60 registered patches, see perl -V for more detail)

Gemini CLI

If not pre-installed you can download the Gemini CLI to interact with the source files and provide real-time assistance:

npm install -g @google/gemini-cli

Testing the Gemini CLI Environment

Once you have all the tools and the correct Node.js version in place- you can test the startup of Gemini CLI. You will need to authenticate with a Key or your Google Account:

gemini

Node Version Management

Gemini CLI needs a consistent, up to date version of Node. The nvm command can be used to get a standard Node environment:

GitHub - nvm-sh/nvm: Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions

Perl MCP Documentation

The official MCP CPAN page provides samples and documentation for getting started:

MCP

Where do I start?

The strategy for starting MCP development is a incremental step by step approach.

First, the basic development environment is setup with the required system variables, and a working Gemini CLI configuration.

Then, a minimal Hello World Style Perl MCP Server is built with stdio transport. This server is validated with Gemini CLI in the local environment.

This setup validates the connection from Gemini CLI to the local process via MCP. The MCP client (Gemini CLI) and the MCP server both run in the same local environment.

Next- the basic MCP server is extended with Gemini CLI to add several new tools in standard code.

Setup the Basic Environment

At this point you should have a working Perl environment and a working Gemini CLI installation. The next step is to clone the GitHub samples repository with support scripts:

cd ~
git clone https://github.com/xbill9/gemini-cli-codeassist

Then run init.sh from the cloned directory.

The script will attempt to determine your shell environment and set the correct variables:

cd gemini-cli-codeassist
source init.sh

If your session times out or you need to re-authenticate- you can run the set_env.sh script to reset your environment variables:

cd gemini-cli-codeassist
source set_env.sh

Variables like PROJECT_ID need to be setup for use in the various build scripts- so the set_env script can be used to reset the environment if you time-out.

Hello World with STDIO Transport

One of the key features that the standard MCP libraries provide is abstracting various transport methods.

The high level MCP tool implementation is the same no matter what low level transport channel/method that the MCP Client uses to connect to a MCP Server.

The simplest transport that the SDK supports is the stdio (stdio/stdout) transport — which connects a locally running process. Both the MCP client and MCP Server must be running in the same environment.

The connection over stdio will look similar to this:

# Explicitly use stdio transport
$server->to_stdio;

Perl Package Information

The code depends on several standard Perl libraries for MCP and logging:

requires 'Mojolicious::Lite';
requires 'MCP::Server';
requires 'JSON::MaybeXS';
requires 'WWW::Google::Cloud::Auth::ServiceAccount';
requires 'URI::Encode';
requires 'LWP::Protocol::https';

on 'develop' => sub {
    requires 'Perl', '5.010';
    requires 'Perl::Critic';
    requires 'Perl::Tidy';
};

Installing and Running the Perl Code

Run the install make release target on the local system:

xbill@penguin:~/gemini-cli-codeassist/mcp-stdio-perl$ make
Installing dependencies...
--> Working on .
Configuring /home/xbill/gemini-cli-codeassist/mcp-stdio-perl ... OK
<== Installed dependencies for .. Finishing.
Running tests...
t/00_compile.t .. ok   

To test the code:

xbill@penguin:~/gemini-cli-codeassist/mcp-stdio-perl$ make test
Running tests...
t/00_compile.t .. ok   
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.01 usr 0.00 sys + 0.17 cusr 0.05 csys = 0.23 CPU)
Result: PASS

Gemini CLI settings.json

In this example — the Perl source code uses a Perl interpretor that can be called directly from Gemini CLI.

The default Gemini CLI settings.json has an entry for the source:

{
  "mcpServers": {
    "hello-stdio-perl": {
      "command": "perl",
      "args": [
        "-I$HOME/gemini-cli-codeassist/mcp-stdio-perl/local/lib/perl5",
        "$HOME/gemini-cli-codeassist/mcp-stdio-perl/server.pl"
      ]
    }
  }
}

Validation with Gemini CLI

Finally- Gemini CLI is restarted and the MCP connection over stdio to the Perl Code is validated, The full Gemini CLI Session will start:

> /mcp list

🟢 hello-stdio-perl - Ready (1 tool)
  Tools:
  - greet

> greet Camel

✦ I will call the greet tool with the parameter Camel.

╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ? greet (hello-stdio-perl MCP Server) {"param":"Camel"} ← │
│ │
│ MCP Server: hello-stdio-perl │
│ Tool: greet │
│ │
│ Allow execution of MCP tool "greet" from server "hello-stdio-perl"? │
│ │
│ 1. Allow once │
│ 2. Allow tool for this session │
│ ● 3. Allow all server tools for this session │
│ 4. No, suggest changes (esc) │
│ │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ greet (hello-stdio-perl MCP Server) {"param":"Camel"} │
│ │
│ Camel │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ Hello Camel! How can I help you today?

Extending the MCP Server with Gemini CLI

Now that the basic MCP functionality has been tested and verified with Gemini CLI- the Perl server code can be extended with new MCP tools:

> with the perl project add new MCP tools - 
one that gets detailled Perl system information, 
one that gets server information
and one that gets the current time

Gemini CLI will get right to work:

│ 53 │
│ 54 + $server->tool( │
│ 55 + name => 'get_perl_system_info', │
│ 56 + description => 'Get detailed Perl system information (Config::myconfig).', │
│ 57 + input_schema => { │
│ 58 + type => 'object', │
│ 59 + properties => {}, │
│ 60 + }, │
│ 61 + code => sub ( $tool, $args ) { │
│ 62 + $log->info("Executed get_perl_system_info tool"); │
│ 63 + return Config::myconfig(); │
│ 64 + } │
│ 65 + ); │
│ 66 + │ │

Once completed — the changes will be summarized:

✦ I have added the three requested MCP tools to server.pl and verified them with a new test suite.

  Summary of changes:
   1. Modified `server.pl`:
       * Imported Config module.
       * Added get_perl_system_info: Returns detailed Perl configuration using Config::myconfig().
       * Added get_server_info: Returns server name, version, status, and transport type.
       * Added get_current_time: Returns the current system time.
       * Refactored the script to be testable (returns $server and only runs to_stdio if run as a script).
   2. Created `t/01_tools.t`:
       * A new test file that loads server.pl, inspects the registered tools, and executes their callbacks to verify correctness.

  Verification:
   * t/00_compile.t passed.
   * t/01_tools.t passed, confirming all 3 tools are registered and return expected data.

Restart Gemini CLI and check for the new MCP tools:

xbill@penguin:~/gemini-cli-codeassist/mcp-stdio-perl$ make
Installing dependencies...
--> Working on .
Configuring /home/xbill/gemini-cli-codeassist/mcp-stdio-perl ... OK
<== Installed dependencies for .. Finishing.
Running tests...
t/00_compile.t .. ok   
t/01_tools.t .... 1/? {"asctime":"2026-01-12T01:08:56.49922Z","levelname":"INFO","message":"Executed get_server_info tool","name":"root"}
{"asctime":"2026-01-12T01:08:56.49954Z","levelname":"INFO","message":"Executed get_current_time tool","name":"root"}
{"asctime":"2026-01-12T01:08:56.49965Z","levelname":"INFO","message":"Executed get_perl_system_info tool","name":"root"}
t/01_tools.t .... ok    
All tests successful.
Files=2, Tests=13, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.35 cusr 0.05 csys = 0.42 CPU)
Result: PASS

And list the new MCP Tools:

🟢 hello-stdio-perl - Ready (4 tools)
  Tools:
  - get_current_time
  - get_perl_system_info
  - get_server_info
  - greet

to run the tools:

> get_current_time

✦ I will get the current time for you.
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ? get_current_time (hello-stdio-perl MCP Server) {} ← │
│ │
│ MCP Server: hello-stdio-perl │
│ Tool: get_current_time │
│ │
│ Allow execution of MCP tool "get_current_time" from server "hello-stdio-perl"? │
│ │
│ 1. Allow once │
│ 2. Allow tool for this session │
│ ● 3. Allow all server tools for this session │
│ 4. No, suggest changes (esc) │
│ │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ I will get the current time for you.
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ get_current_time (hello-stdio-perl MCP Server) {} │
│ │
│ Sun Jan 11 20:12:02 2026 │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ I've retrieved the current time. I am now ready for your first command.

and Perl information:

> get_perl_system_info

✦ I will retrieve the Perl system information for you.
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ get_perl_system_info (hello-stdio-perl MCP Server) {} │
│ │
│ Summary of my perl5 (revision 5 version 36 subversion 0) configuration: │
│ │
│ Platform: │
│ osname=linux │
│ osvers=4.19.0 │
│ archname=x86_64-linux-gnu-thread-multi │
│ uname='linux localhost 4.19.0 #1 smp debian 4.19.0 x86_64 gnulinux ' │

and system information:

> get_server_info

✦ I will get the information about this MCP server.

╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ get_server_info (hello-stdio-perl MCP Server) {} │
│ │
│ {"name":"Perl MCP Stdio Server","perl_version":"v5.36.0","status":"running","transport":"stdio","version":"1.0.0"} │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
✦ The server is running version 1.0.0 of the Perl MCP Stdio Server on Perl v5.36.0.

Summary

The strategy for using Perl with MCP development with Gemini CLI was validated with a incremental step by step approach.

A minimal stdio transport MCP Server was started from Perl source code and validated with Gemini CLI running as a MCP client in the same local environment.

Gemini CLI was then used to extend the sample Perl code with several MCP tools and use these tools inside the context for the underlying LLM.

Originally published at Perl Weekly 755

Hi there!

Dave Cross has an article showing position of Perl on the TIOBE index. As I don't see any up-tick in new subscribers to the Perl Weekly nor do I see any increase in the MetaCPAN activity I keep track of, I doubt that the changes in the position reflects actual changes in the market. However I wonder, could the TIOBE index have an impact on the interest in Perl? How and when could we see that?

Speaking of the MetaCPAN report, I'd love if someone sent a PR to the Perl Weekly that would generates same graphs using these numbers. Here is the issue for it.

And another comment related to those stats. I just noticed that the No CI column went up from 30-40% to 80-90% in recent weeks. I wonder why? Is it because some changes in the way I am collecting the data or are those real changes? Is it real change? I also just noticed some negative numbers in the No VCS (%) column. That's not good. I guess I have to investigate this. Maybe during one of the Perl code reading and open source contribution events.

Enjoy your week!

--
Your editor: Gabor Szabo.

Announcements

New York Perlmongers (NY.PM)

New York Perlmongers (NY.PM) has a new mailing-list organized as a Google Group. Sign up here. (Note: we are not doing unrequested transfers from our previous mailing list.) NY.PM social event: Thursday, January 15, 6:00 pm EST at Barcade, 148 West 24 St, Manhattan: send-off for a long-time member returning to the U.K.

ANNOUNCE: Perl.Wiki V 1.37

Get it, as usual, from his Wiki Haven.

Articles

Marlin Racing

Which of the 7 OOP frameworks of Perl is the fastest?

The Perl Claude Agent

It's a library that brings the agentic capabilities of Claude Code into your Perl applications.

Manwar sending a Pull-Request to JQ::Lite

This video was recorded during the most recent Perl code reading and open source contribution event. For links check out the OSDC Perl page and join us at our next event!

Perl in the TIOBE Index

See also the discussion.

DBIx::Class::Async - UPDATE

Discussion

nfo - a user-friendly info reader

Why do you need Perl for this? - asks the first commenter.

convert string to regex

Allowing your users to put regexes in a configuration file. Is it a good idea? How to do it?

MetaCPAN

perlmodules.net is (was) down for 1-2 weeks

Is the MetaCPAN API changing?

The ElasticSearch upgrade on MetaCPAN impaceted a number of other web site, but it seems things are working again.

Perl

This week in PSC (210) | 2026-01-05

The Weekly Challenge

The Weekly Challenge by Mohammad Sajid Anwar will help you step out of your comfort-zone. You can even win prize money of $50 by participating in the weekly challenge. We pick one champion at the end of the month from among all of the contributors during the month, thanks to the sponsor Lance Wicks.

The Weekly Challenge - 356

Welcome to a new week with a couple of fun tasks "Kolakoski Sequence" and "Who Wins". If you are new to the weekly challenge then why not join us and have fun every week. For more information, please read the FAQ.

RECAP - The Weekly Challenge - 355

Enjoy a quick recap of last week's contributions by Team PWC dealing with the "Thousand Separator" and "Mountain Array" tasks in Perl and Raku. You will find plenty of solutions to keep you busy.

Mountain Separator

The post demonstrates an idiomatic and compact use of Raku for typical programming challenges. It balances expressive language features with clarity, though readers unfamiliar with hyperoperators and the pipeline style might need supplemental explanation.

Perl Weekly Challenge: Week 355

Technically solid, readable, and well-structured. The solutions are both correct and practical, illustrating good problem decomposition and Perl/Raku coding style.

Separated Mountains

Efficient and idiomatic Perl for the thousand separator using a classic unpack pattern.️ A formally defined mountain array solution with vectorised and language-diverse implementations.

number formatting and sorting

This is a well‑engineered, comprehensive, and professionally presented technical write‑up that goes beyond minimal solutions to showcase how to solve the Weekly Challenge across ecosystems. It favors clarity and breadth over micro‑optimizations, making it valuable for learners and polyglot developers alike.

Perl Weekly Challenge 355

The solutions for Weekly Challenge #355 are technically strong, correct, and efficient. Task 2 (Mountain Array) leverages PDL for vectorized comparisons, producing a concise, single-pass check for mountain arrays while correctly handling edge cases such as plateaus and short arrays.

Thousand Mountains

This is technically excellent, showing a high level of Perl proficiency, algorithmic awareness, and performance consciousness. Both tasks are solved correctly, with multiple alternative implementations explored and benchmarked, demonstrating a thoughtful and professional approach rather than a "just pass the tests" mentality.

Oh to live on Array Mountain…

This post is a strong, well-executed multi-language technical write-up that emphasizes algorithmic reasoning, clarity of transformation, and comparative programming paradigms over minimalism or raw performance.

Thousands of mountains

This submission demonstrates strong problem understanding, solid algorithmic choices, and pragmatic Perl coding. The solutions are intentionally explicit, readable, and correct, favoring clarity and single-pass logic over clever one-liners. Both tasks are handled with approaches that scale reasonably and align well with Perl’s strengths.

The Weekly Challenge #355

This submission is technically strong, correct, and deliberately written for clarity and maintainability rather than brevity. It reflects an experienced Perl programmer who values explicit logic, readable structure, and thorough documentation.

Mountains by the Thousand

This is a thoughtful, well-structured solution to both Weekly Challenge tasks, with a clear emphasis on explicit logic and state-based reasoning rather than relying on library tricks. Roger demonstrates good cross-language fluency and a solid grasp of algorithm design.

Commify every mountain

This post delivers clean, pragmatic, and idiomatic solutions to both tasks in The Weekly Challenge #355. It emphasizes using the right tool for the job, clarity, and efficiency over algorithmic novelty.

Weekly collections

NICEPERL's lists

Great CPAN modules released last week.

Events

Perl Maven online: Live Open Source contribution

January 24, 2025

Boston.pm - online

February 10, 2025

German Perl/Raku Workshop 2026 in Berlin

March 16-18, 2025

You joined the Perl Weekly to get weekly e-mails about the Perl programming language and related topics.

Want to see more? See the archives of all the issues.

Not yet subscribed to the newsletter? Join us free of charge!

(C) Copyright Gabor Szabo
The articles are copyright the respective authors.

When I first introduced Marlin, it seemed the only OO framework which could beat its constructor in speed was the one generated by the new Perl core class keyword. Which seems fair, as that’s implemented in C and is tightly integrated with the Perl interpreter. However, I’m pleased to say that Marlin’s constructors are now faster.

(Though also I forgot to include Mouse in previous benchmarks, so I’ve rectified that now.)

         Rate  Plain   Tiny    Moo  Moose   Core Marlin  Mouse
Plain  1357/s     --    -1%   -48%   -55%   -73%   -77%   -78%
Tiny   1374/s     1%     --   -48%   -54%   -72%   -77%   -78%
Moo    2617/s    93%    91%     --   -13%   -47%   -56%   -58%
Moose  3001/s   121%   118%    15%     --   -39%   -50%   -52%
Core   4943/s   264%   260%    89%    65%     --   -17%   -21%
Marlin 5976/s   340%   335%   128%    99%    21%     --    -4%
Mouse  6237/s   359%   354%   138%   108%    26%     4%     --

The main way I’ve squeezed out a bit of improved performance is by improving how Class::XSConstructor keeps its metadata.

Previously, if you called Local::Person->new(), the XS constructor would look up the list of supported attributes for the class in @Local::Person::__XSCON_HAS and loop through that array to initialize each attribute like "name", "age", etc. If the attribute had a type constraint, it would need to fetch the coderef to validate the value from $Local::Person::__XSCON_ISA{"name"}, and so on. All these involved looking things up in the class’s stash, which isn’t exactly slow when done via XS, but could be faster.

I’ve changed it so that the first time the constructor is called, the XS code pulls together all the data it needs into C structs.

typedef struct {
    char   *name;
    I32     flags;
    char   *init_arg;
    char  **aliases;
    I32     num_aliases;
    SV     *default_sv;
    SV     *trigger_sv;
    CV     *check_cv;
    CV     *coercion_cv;
} xscon_param_t;

typedef struct {
    char   *package;
    bool    is_placeholder;
    xscon_param_t *params;
    I32     num_params;
    CV    **build_methods;
    I32     num_build_methods;
    bool    strict_params;
    char  **allow;
    I32     num_allow;
} xscon_constructor_t;

Rather than having to deal with attribute names being Perl SVs, they’re just simple C strings (char*).

The flags field does a lot of heavy lifting. It is a bit field with booleans indicating whether an attribute is required or optional, whether it should be a weaken reference, and other features. A lot of common defaults (attributes which default to common values like undef, true, false, 0, 1, the empty string, an empty arrayref, or an empty hashref) and common type constraints (Str, Num, Int, ArrayRef, etc) are also encoded into the flags field, so the constructor can often skip even having to look at default_sv and check_cv.

At the same time, the number of features Class::XSConstructor supports has increased, so Marlin now never needs to fall back to generating Pure Perl constructors. (The code for generating Perl constructors has now been deleted!)

A second trick is one I learned from Mouse in how it implements its strict constructor check. As a reminder, a strict constructor check is like the ones implemented by MooseX::StrictConstructor, MooX::StrictConstructor, and MouseX::StrictConstructor, along these lines:

sub new {
  # Unpack @_
  my $class = shift;
  my %args  = ( @_ == 1 and ref($_[0]) eq 'HASH' ) ? %{+shift} : @_;

  # Create new object
  my $object = bless( {}, $class );

  # Initialize each attribute
  if ( exists $args{name} ) {
    $object->{name} = $args{name};
  }
  if ( exists $args{date} ) {
    $object->{date} = $args{date};
  }

  # Strict constructor check
  for my $key ( %args ) {
    die "Unrecognized key: $key" unless $key =~ /^(name|date)$/;
  }

  return $object;
}

Strict constructors are a really useful feature as a protection against mistyped attributes. But they do come with a speed penalty, which I guess is why Moose and Moo don’t have this feature built in. (Mouse does actually have the feature built in, but requires an extension (MouseX::StrictConstructor) to toggle it on.)

Mouse’s strict constructor check has virtually zero performance impact. I took a look at the source code to figure out how, and it is pretty smart. It just counts the number of arguments the constructor has used to initialize attributes, and only bothers with the strict constructor check if the total number of arguments is greater than that. Something like this:

sub new {
  # Unpack @_
  my $class = shift;
  my %args  = ( @_ == 1 and ref($_[0]) eq 'HASH' ) ? %{+shift} : @_;

  # Create new object
  my $object = bless( {}, $class );
  my $used_keys = 0;

  # Initialize each attribute
  if ( exists $args{name} ) {
    $object->{name} = $args{name};
    $used_keys++;
  }
  if ( exists $args{date} ) {
    $object->{date} = $args{date};
    $used_keys++;
  }

  # Strict constructor check
  if ( keys(%args) > $used_keys ) {
    for my $key ( %args ) {
      die "Unrecognized key: $key" unless $key =~ /^(name|date)$/;
    }
  }

  return $object;
}

Genius!

With these changes, Marlin is now significantly faster than the Perl core class keyword.

Mouse still has around 10% faster accessors than Marlin, which I think might be largely down to having an integrated type system allowing pure C function calls for type constraints instead of needing to use call_sv to call an XS or Perl type check function.

Marlin does however beat Mouse significantly (around 70% faster) when it comes to delegated methods. Things like:

use v5.36;

package API_Client {
  use Marlin
    -modifiers,
    _log => {
      isa          => 'ArrayRef[HashRef]',
      default      => [],
      handles_via  => 'Array',
      handles      => {
        add_to_log   => 'push',
        responses    => 'all',
      },
    },
    ua => {
      isa          => 'HTTP::Tiny',
      default      => sub { HTTP::Tiny->new },
      handles      => {
        http_get     => 'get',
        http_post    => 'post',
      },
    };

    around 'http_get', 'http_post' => sub ( $next, $self, @args ) {
      my $response = $self->$next( @args );
      $self->add_to_log( $response );
      return $response;
    };
}

my $client = API_Client->new;
$client->http_get( ... );
$client->http_get( ... );
$client->http_get( ... );
my @responses = $client->responses;

Marlin outperforms all other OO frameworks in this kind of method.

If you want a fast, concise OO framework, consider using Marlin.

So over the past few days I've built a new addition to the Perl ecosystem: the Claude Agent SDK. It's a library that brings the agentic capabilities of Claude Code into your Perl applications.

At its core, the SDK enables you to build AI agents that can read files, run shell commands, search the web, edit code, and interact with external systems. All orchestrated from familiar Perl code. Whether you're automating code reviews, building intelligent DevOps tooling, or integrating AI capabilities into legacy systems, this SDK provides the foundation you need.

The architecture is built around a streaming JSON Lines protocol (using my JSON::Lines module) that communicates with the Claude Code CLI, supporting both synchronous operations and fully asynchronous patterns via IO::Async and Future::AsyncAwait. Although we send valid JSON lines, the CLI doesn't always return valid JSON lines, so some extension to my module was needed to handle malformed responses gracefully. Here's what a simple interaction looks like:

use Claude::Agent qw(query);
use Claude::Agent::Options;

my $options = Claude::Agent::Options->new(
    allowed_tools   => ['Read', 'Glob', 'Grep'],
    permission_mode => 'bypassPermissions',
);

my $iter = query(
    prompt  => "What files in ./lib need the most refactoring?",
    options => $options,
);

while (my $msg = $iter->next) {
    if ($msg->isa('Claude::Agent::Message::Result')) {
        print $msg->result;
        last;
    }
}

The real power emerges when you explore the SDK's advanced features: custom MCP tools that can run directly in your Perl process with full access to your application state, a subagent system for spawning specialised AI workers with isolated contexts, session management for resuming or forking conversations, and structured output with JSON Schema validation for automation-ready responses.

The SDK is complemented by two separate distributions I wrote that showcase what's possible: a Code Review module for AI-powered analysis with severity-based issue detection and Perlcritic integration, and a Code Refactor module that implements an automated review-fix-repeat loop until your codebase is clean.

Let's dive into how it all works.

Custom MCP Tools That Run in Your Process

One of the most powerful features of the Claude Agent SDK is the ability to create custom MCP tools that execute directly in your Perl process. Unlike external MCP servers that run as separate services, SDK tools have full access to your application's state: your database connections, configuration, session data, and any Perl modules you're already using.

This architecture enables significant functional extensibility. To permit Claude to execute queries against production databases, retrieve customer records, or access inventory data, these operations can be exposed as callable tools within the conversational interface. All tool invocations adhere to JSON Schema validation, ensuring type safety and structural integrity throughout the execution pipeline.

You define a tool with four components: a name, a description (which helps Claude understand when to use it), an input schema (JSON Schema defining the parameters), and a handler (your Perl code that does the actual work):

use Claude::Agent qw(tool create_sdk_mcp_server);

my $find_user = tool(
    'find_user',                              # Tool name
    'Find a user by their email address',    # Description for Claude
    {                                         # JSON Schema for inputs
        type       => 'object',
        properties => {
            email => {
                type        => 'string',
                description => 'Email address to search for'
            },
        },
        required => ['email'],
    },
    sub {                                     # Handler (runs in your process!)
        my ($args) = @_;
        # Your code here with full access to application state
        return {
            content => [{ type => 'text', text => 'Result goes here' }],
        };
    }
);

The magic is in that handler. It's not running in some sandboxed external process. It's running right in your Perl application, with access to everything you've already set up. Let's build a complete database query tool to see this in action:

#!/usr/bin/env perl
use 5.020;
use strict;
use warnings;

use Claude::Agent qw(query tool create_sdk_mcp_server);
use Claude::Agent::Options;
use IO::Async::Loop;
use DBI;

# Your existing database connection. The tool handler can use this directly
my $dbh = DBI->connect(
    'dbi:SQLite:customers.db',
    '', '',
    { RaiseError => 1, AutoCommit => 1 }
);

# Tool 1: Find a customer by email
my $find_customer = tool(
    'find_customer',
    'Look up a customer record by email address. Returns their name, plan, and signup date.',
    {
        type       => 'object',
        properties => {
            email => {
                type        => 'string',
                description => 'Customer email to search for'
            },
        },
        required => ['email'],
    },
    sub {
        my ($args) = @_;

        # Direct database access with no external API, no serialisation overhead
        my $customer = $dbh->selectrow_hashref(
            'SELECT name, email, plan, created_at FROM customers WHERE email = ?',
            undef,
            $args->{email}
        );

        if ($customer) {
            return {
                content => [{
                    type => 'text',
                    text => sprintf(
                        "Found customer: %s <%s>\nPlan: %s\nMember since: %s",
                        $customer->{name},
                        $customer->{email},
                        $customer->{plan},
                        $customer->{created_at}
                    ),
                }],
            };
        }

        return {
            content => [{
                type => 'text',
                text => "No customer found with email: $args->{email}"
            }],
        };
    }
);

# Tool 2: Get aggregate statistics
my $customer_stats = tool(
    'customer_stats',
    'Get statistics about customers, optionally filtered by plan type',
    {
        type       => 'object',
        properties => {
            plan => {
                type        => 'string',
                enum        => ['free', 'pro', 'enterprise'],
                description => 'Filter by plan type (optional)'
            },
        },
        required => [],  # No required params so Claude can call this with no arguments
    },
    sub {
        my ($args) = @_;

        my ($sql, @bind);
        if ($args->{plan}) {
            $sql = 'SELECT COUNT(*) as count, plan FROM customers WHERE plan = ? GROUP BY plan';
            @bind = ($args->{plan});
        } else {
            $sql = 'SELECT COUNT(*) as count, plan FROM customers GROUP BY plan ORDER BY count DESC';
        }

        my $rows = $dbh->selectall_arrayref($sql, { Slice => {} }, @bind);

        my @lines = map { "$_->{plan}: $_->{count} customers" } @$rows;
        return {
            content => [{
                type => 'text',
                text => join("\n", @lines) || "No customers found"
            }],
        };
    }
);

Now bundle these tools into an SDK MCP server and use them in a query:

# Create the MCP server
my $server = create_sdk_mcp_server(
    name    => 'customerdb',
    tools   => [$find_customer, $customer_stats],
    version => '1.0.0',
);

# Configure the agent to use our tools
my $options = Claude::Agent::Options->new(
    mcp_servers     => { customerdb => $server },
    allowed_tools   => $server->tool_names,  # ['mcp__customerdb__find_customer', ...]
    permission_mode => 'bypassPermissions',
    max_turns       => 10,
);

# Now Claude can query your database naturally
my $loop = IO::Async::Loop->new;
my $iter = query(
    prompt  => 'How many customers do we have on each plan? ' .
               'Also, look up the customer with email alice@example.com',
    options => $options,
    loop    => $loop,
);

# Stream the response
while (my $msg = $iter->next) {
    if ($msg->isa('Claude::Agent::Message::Assistant')) {
        for my $block ($msg->content_blocks) {
            print $block->text if $block->isa('Claude::Agent::Content::Text');
        }
    }
    elsif ($msg->isa('Claude::Agent::Message::Result')) {
        print "\n\nQuery complete.\n";
        last;
    }
}

When you run this, Claude will intelligently call both tools to answer your question. It might first call customer_stats with no arguments to get the plan breakdown, then call find_customer with email => 'alice@example.com' to look up that specific record. You'll see output like:

Let me check our customer data for you.

We have the following customers by plan:
- pro: 1,247 customers
- free: 3,892 customers
- enterprise: 89 customers

For alice@example.com, I found:
- Name: Alice Chen
- Plan: enterprise
- Member since: 2024-03-15

Behind the scenes, the SDK creates a Unix socket for communication between your main process and a lightweight MCP protocol handler. When Claude calls a tool, the request flows through the socket to your handler, which executes synchronously with full access to $dbh and any other state in scope. The result flows back to Claude, and the conversation continues.

This pattern is incredibly useful for building AI-powered interfaces to your existing systems. You're not building a new API. You're exposing capabilities that your Perl code already has, with Claude handling the natural language understanding and your handlers doing the actual work. The JSON Schema validation ensures Claude passes the right parameters, and your handlers can return structured results or friendly error messages.

A few things to note about handler implementation:

• Return structure: Always return a hashref with a content array. Each element should have type => 'text' and a text field.
• Error handling: Set is_error => 1 in your return value when something goes wrong. Claude will understand the operation failed.
• Input validation: The SDK validates inputs against your JSON Schema, but you may want additional business logic validation in your handler.
• Security: Be thoughtful about what you expose. The enum constraint in customer_stats limits which plans can be queried. You can use similar patterns to restrict what data Claude can access.

The Hook System for Fine-Grained Control

When you're running AI agents in production, you need visibility. What tools is Claude calling? With what parameters? How long did each operation take? Did anything get blocked? The Claude Agent SDK's hook system gives you complete control over the agent's tool execution lifecycle, letting you intercept, inspect, modify, or block any operation.

Think of hooks as middleware for AI agent operations. Every time Claude wants to call a tool, whether it's reading a file, running a bash command, or calling one of your custom MCP tools: your hooks get first dibs. You can log the operation, check it against security policies, modify the parameters, or shut it down entirely. And you get hooks for multiple lifecycle points: before execution, after success, after failure, and more.

The system is built around matchers that bind patterns to callbacks:

use Claude::Agent::Hook::Matcher;
use Claude::Agent::Hook::Result;

my $matcher = Claude::Agent::Hook::Matcher->new(
    matcher => 'Bash',           # Tool name pattern (regex or exact match)
    timeout => 60,               # Hook execution timeout in seconds
    hooks   => [                 # Array of callback subroutines
        sub {
            my ($input, $tool_use_id, $context) = @_;
            # Your logic here
            return Claude::Agent::Hook::Result->proceed();
        },
    ],
);

Each hook callback receives three arguments: $input (a hashref with tool_name and tool_input), $tool_use_id (a unique identifier for this specific invocation), and $context (a Claude::Agent::Hook::Context object with session metadata like session_id and cwd).

Your hooks return decisions using the Claude::Agent::Hook::Result factory:

# Let the operation proceed unchanged
return Claude::Agent::Hook::Result->proceed();

# Allow but modify the input parameters
return Claude::Agent::Hook::Result->allow(
    updated_input => { command => 'sanitized_command' },
    reason        => 'Modified for security',
);

# Block the operation entirely
return Claude::Agent::Hook::Result->deny(
    reason => 'This operation violates security policy',
);

The available hook events cover the tool execution lifecycle:

These three events are the workhorses of the hook system, giving you complete visibility into tool execution. The SDK also defines additional event types (SessionStart, SessionEnd, SubagentStart, SubagentStop, PermissionRequest, Notification, Stop, PreCompact, UserPromptSubmit) that cover session lifecycle, subagent management, and user interactions.

# Security hook, only fires for Bash tool
my $bash_security = Claude::Agent::Hook::Matcher->new(
    matcher => 'Bash',  # Exact match on tool name
    hooks   => [sub {
        my ($input, $tool_use_id, $context) = @_;

        my $command = $input->{tool_input}{command} // '';

        # Define blocked patterns
        my @dangerous_patterns = (
            qr/\brm\s+-rf\s+[\/~]/,      # rm,rf against root or home
            qr/\bsudo\b/,                 # No sudo commands
            qr/\bchmod\s+777\b/,          # World-writable permissions
            qr/>\s*\/etc\//,              # Redirecting to /etc
            qr/\bcurl\b.*\|\s*\bbash\b/,  # Piping curl to bash
            qr/\beval\b/,                 # Command eval
        );

        for my $pattern (@dangerous_patterns) {
            if ($command =~ $pattern) {
                write_audit_log({
                    timestamp   => scalar(gmtime) . ' UTC',
                    event       => 'TOOL_BLOCKED',
                    tool_use_id => $tool_use_id,
                    tool_name   => 'Bash',
                    reason      => 'Matched dangerous pattern',
                    pattern     => "$pattern",
                    severity    => 'CRITICAL',
                });

                return Claude::Agent::Hook::Result->deny(
                    reason => 'This command has been blocked by security policy.',
                );
            }
        }

        return Claude::Agent::Hook::Result->proceed();
    }],
);

• Hook execution order matters. When you provide multiple matchers for the same event, they run in array order. Within a single matcher, if any hook returns allow or deny, subsequent hooks in that matcher don't execute. The decision is final.

• Matcher patterns are flexible. Use an exact string like 'Bash' to match a specific tool, a regex pattern like 'mcp__.*' to match all MCP tools, or omit the matcher entirely to catch everything. The SDK includes ReDoS protection to prevent pathological regex patterns from hanging your process.

• Hooks are exception-safe. If your callback throws, the SDK catches it and returns { decision => 'error' }. Your agent keeps running, and you can enable CLAUDE_AGENT_DEBUG=1 to see the full stack trace.

• The context object is your friend. The $context parameter gives you the session ID (essential for correlating logs across a conversation), the current working directory, and the tool details. Use this metadata to make intelligent decisions about what to allow.

Subagents for Specialised Tasks

Sometimes a single agent isn't enough. Maybe you need to run multiple analyses in parallel, checking for security vulnerabilities while simultaneously reviewing code style. Maybe you want to isolate a complex task so it doesn't pollute your main conversation context. Or maybe you need specialised expertise: one agent focused purely on security, another on performance, each with tailored instructions and tool access.

This is what subagents are for. The Claude Agent SDK lets you define specialised agent profiles that your main agent can spawn on demand. Each subagent runs in its own isolated context with its own system prompt, tool permissions, and even model selection. Think of them as expert consultants your agent can call in when it needs help.

The architecture is elegant. You define subagents as configuration objects with four properties:

use Claude::Agent::Subagent;

my $subagent = Claude::Agent::Subagent->new(
    description => '...',   # When should Claude use this agent?
    prompt      => '...',   # System prompt defining expertise
    tools       => [...],   # Allowed tools (optional, inherits if not set)
    model       => '...',   # Model override (optional, 'sonnet', 'opus', 'haiku')
);

The description is key. Claude uses this to decide when to delegate. Write it like you're explaining to a colleague: "Expert security reviewer for vulnerability analysis" tells Claude exactly what this agent does. The prompt is the system prompt that shapes the subagent's behaviour, giving it the specialised knowledge and instructions it needs.

The subagent architecture provides several powerful capabilities:

Context isolation. Each subagent starts fresh with only its system prompt. There is no accumulated context from earlier in the conversation. This prevents context pollution and keeps analyses focused.

Tool restriction. Notice how secrets_detector doesn't have Bash access. It can only read files. This is defense in depth: even if the AI were to malfunction, a secrets-scanning agent physically cannot execute commands.

Model selection. Use Opus for complex security analysis where you need the strongest reasoning. Use Haiku for straightforward pattern-matching tasks. Your main agent can be Sonnet as the orchestrator. This optimises both cost and capability.

Parallel potential. While Claude currently executes subagents sequentially, the architecture supports parallel execution. When you spawn multiple subagents, their isolated contexts mean results can be combined without interference.

Async Tool Handlers

For tools that perform I/O operations—HTTP requests, database queries, file operations—blocking the event loop is wasteful. The SDK supports async tool handlers that return Futures, enabling true non-blocking execution.

Your handler receives the IO::Async::Loop as its second parameter. Use it to perform async operations and return a Future that resolves with your result:

use Future::AsyncAwait;
use Net::Async::HTTP;

my $fetch_url = tool(
    'fetch_url',
    'Fetch content from a URL asynchronously',
    {
        type       => 'object',
        properties => {
            url => { type => 'string', description => 'URL to fetch' },
        },
        required => ['url'],
    },
    async sub {
        my ($args, $loop) = @_;

        my $http = Net::Async::HTTP->new;
        $loop->add($http);

        my $response = await $http->GET($args->{url});

        return {
            content => [{
                type => 'text',
                text => sprintf("Status: %d\nBody: %s",
                    $response->code,
                    substr($response->decoded_content, 0, 1000)),
            }],
        };
    }
);

The same pattern works for hooks. Your hook callback can return a Future for async validation:

my $async_security_hook = Claude::Agent::Hook::Matcher->new(
    matcher => '.*',
    hooks   => [
        async sub {
            my ($input, $tool_use_id, $context, $loop) = @_;

            # Async check against a security policy service
            my $http = Net::Async::HTTP->new;
            $loop->add($http);

            my $resp = await $http->POST(
                'https://security.internal/check',
                content => encode_json($input),
            );

            if ($resp->code == 403) {
                return Claude::Agent::Hook::Result->deny(
                    reason => 'Blocked by security policy',
                );
            }

            return Claude::Agent::Hook::Result->proceed();
        },
    ],
);

One powerful pattern enabled by the shared event loop: spawning nested queries from within a tool handler. Your tool can invoke Claude as a sub-agent:

my $research_tool = tool(
    'deep_research',
    'Spawn a sub-agent to research a topic',
    {
        type       => 'object',
        properties => {
            topic => { type => 'string' },
        },
        required => ['topic'],
    },
    sub {
        my ($args, $loop) = @_;

        # Spawn a sub-query using the shared event loop
        my $sub_query = query(
            prompt  => "Research thoroughly: $args->{topic}",
            options => Claude::Agent::Options->new(
                allowed_tools   => ['Read', 'Glob', 'WebSearch'],
                permission_mode => 'bypassPermissions',
                max_turns       => 5,
            ),
            loop => $loop,
        );

        my $result = '';
        while (my $msg = $sub_query->next) {
            if ($msg->isa('Claude::Agent::Message::Result')) {
                $result = $msg->result // '';
                last;
            }
        }

        return {
            content => [{ type => 'text', text => $result }],
        };
    }
);

Sync handlers continue to work unchanged. The SDK automatically wraps synchronous return values in Futures, so you can mix sync and async tools freely.

Wrapping Up

The Claude Agent SDK for Perl brings agentic AI capabilities directly into your existing infrastructure. From custom MCP tools that access your application state, to a flexible hook system for security and observability, to specialised subagents for parallel expertise—the toolkit is designed for real-world automation. Whether you're building intelligent code review pipelines, DevOps automation, or AI-powered interfaces to legacy systems, the SDK provides the primitives you need while keeping you in control. The code is available on CPAN, and I look forward to seeing what you build with it.

https://metacpan.org/pod/Claude::Agent

Here are some extensions I've built already using the SDK:

https://metacpan.org/pod/Claude::Agent::Code::Review

https://metacpan.org/pod/Claude::Agent::Code::Refactor

https://metacpan.org/pod/Wordsmith::Claude

https://metacpan.org/dist/Acme-Claude-Shell/view/bin/acme_claude_shell