DEV Community: Alastair McClelland

An Alternative to MCP - Python CLI-Based Agent Skills

Alastair McClelland — Tue, 03 Mar 2026 08:13:42 +0000

I wrote recently about MCP's patchy reliability and how mature CLI tools wrapped in skills felt more stable. I wanted to explore that idea further — specifically, what if you could build custom Python CLI tools with a skills wrapper and have the same success without managing virtual environments?

Python-tool-skills are that exploration. They're Python CLI tools built with Click, run via uvx, and bundled inside skills. No venv pollution, locked dependencies, just works.

What works: wrapping mature CLI tools

Most CLI tools are battle-tested, predictable, well-documented. Wrapping them in skills works brilliantly. The agent calls a command, parses the output, moves on.

These tools have been used by thousands of developers across wildly different contexts. Error messages are clear. Edge cases are handled. You're building on solid ground.

Most importantly, they are a text efficient, well understood textual interface — one well suited to LLMs. With in-context --help output, the agent can discover capabilities progressively rather than loading full schemas upfront.

But what if you need a custom tool? Skills today tend towards writing a bash script, but anything beyond basic text parsing gets messy. Python's cleaner, but then you're managing virtual environments, dependencies, import paths.

Enter uvx — a tool runner that handles Python package isolation automatically, no venv required. Well, not one you have to manage yourself at least!

Python-tool-skills: CLI tools bundled in skills

So why don't we try building custom tools the same way — as standalone CLIs that just happen to be written in Python?

I've put together what I'm calling a python-tool-skill — an AI agent tool packaged as a skill that bundles a Python CLI in its assets/ directory. The CLI is built with Click and runs via uvx.

You can see examples and try it yourself at github.com/almcc/python-tool-skill-creator.

f1/
├── SKILL.md          ← trigger description + agent instructions
└── assets/
    ├── f1.py         ← Click CLI entry point
    ├── pyproject.toml
    └── uv.lock

The agent runs it with:

uvx --from /path/to/skill/assets f1 races

No venv, no __pycache__, no .pyc files. uvx handles isolation automatically. Dependencies are pinned in a committed uv.lock — reproducible and offline-capable after first cache population.

(I chose F1 as a subject because we are very excited for the 2026 season in our house!)

Why Click

Click is the most mature (and my favourite!) Python CLI framework. It handles argument parsing, option validation, help text generation, error formatting and more.

A minimal Click CLI:

import click
from urllib.request import urlopen
import json

@click.group()
def cli():
    """F1 CLI — Formula 1 data powered by OpenF1."""
    pass

@cli.command("races")
@click.option("--year", default=None, type=int)
def races_cmd(year: int):
    """List all races for a season with circuit and local times."""
    if year is None:
        year = datetime.now().year

    # Fetch from OpenF1 API
    meetings = fetch(f"/meetings?year={year}")
    # ... format and display race calendar
    click.echo(f"Fetching {year} calendar...")

if __name__ == "__main__":
    cli()

Top-level @click.group(), sub-commands with @cli.command(), output via click.echo(). That's it.

Why uvx

uv is a fast Python package manager. uvx is its tool runner — like npx for Python.

Point uvx at a directory with a pyproject.toml, and it installs the package in an isolated environment and runs it. The environment is cached. Subsequent calls are fast.

# First run: installs dependencies, runs command
uvx --from /path/to/assets f1 races

# Subsequent runs: uses cached environment
uvx --from /path/to/assets f1 race 5

# After editing f1.py: force reinstall
uvx --from /path/to/assets --reinstall f1 races

No pip install, no python -m venv, no activation scripts. It just works.

Seeing it in action

Here's what it looks like when the agent uses the F1 skill:

# Agent calls the tool
$ uvx --from /path/to/f1/assets f1 races --year 2026

# Output: formatted race calendar
Fetching 2026 calendar...
  2026 Formula 1 Season — 24 Races
  #  Race                        Circuit               Race Time (Circuit)       Race Time (GMT)         When      
-------------------------------------------------------------------------------------------------------------------
  1  Australian GP               Melbourne             Sun 08 Mar, 15:00 UTC+11  Sun 08 Mar, 04:00       in 9d     
  2  Chinese GP                  Shanghai              Sun 15 Mar, 15:00 UTC+8   Sun 15 Mar, 07:00       in 16d    
...

The agent reads the output, extracts what it needs, and moves on. Same experience as calling and other cli. The fact that it's a custom Python tool is invisible.

Why this works for me

I've been using python-tool-skills for a week or so and they feel significantly more user-friendly than creating custom MCP servers. The biggest win? The tools are just CLI programs. I can run them directly from my terminal, test them independently, and use them outside the agent context.

Comparing to MCP servers

MCP servers offer fine-grained control — you can enable and disable specific tools, control exactly what the agent sees. With CLI-based skills, you lose that granularity. You load the skill, the agent gets access to everything the CLI can do.

But as we trust LLMs more, is this much of a concern? The underlying authentication model of the tool you're calling might be enough. If the tool requires credentials, the agent still can't do anything you haven't authorized. The permission boundary shifts from the agent runtime to the tool itself.

Of course, the LLM still needs a way to instigate a tool call. That mechanism may be MCP, or some kind of custom tool schema specific to that agent runtime. The proposal here isn't about replacing those mechanisms — it's about shifting the interface at which we (the community) build our tooling. Rather than building custom protocols and servers, we build portable CLI tools that any agent can wrap.

I do wonder if we'll eventually see a shell dedicated for LLMs — a safer sandbox in which they can work. Something that provides better guardrails, audit logging, and resource limits than a standard shell, while maintaining the familiar CLI interface pattern.

The cost advantage

There's another compelling reason to prefer CLI tools: they're dramatically cheaper to use. As documented by Kan Yilmaz, CLI-based tools use ~94% fewer tokens than equivalent MCP servers through progressive disclosure — the agent only loads tool details when it needs them via --help, rather than loading complete JSON schemas for every tool upfront.

With 84 tools loaded, MCP burns ~15,540 tokens at session start. The same tools via CLI? ~300 tokens. The agent discovers what it needs on-demand, keeping context focused and costs low.

Beyond Python

Of course, this pattern isn't limited to Python. You could bundle Ruby tools with gem install, Node.js tools with npx, Go binaries, Rust crates — anything that can run as a CLI and be distributed in a portable way. Python-tool-skills just happen to be the convenient starting point I chose.

The future of agent tooling

Sentry clearly agrees that CLI tools are the way forward — they've published official agent tooling documentation centered around their CLI, not MCP. Will we see skills become a new distribution method for application tooling? Package your CLI, add usage instructions, ship it as a skill. Developers get tools they can use directly. Agents get tools they can discover progressively. Everyone wins.

Getting into Serverless with CDK, Lambda & DynamoDB - Part 2

Alastair McClelland — Wed, 27 May 2020 05:41:39 +0000

In this second post, we are going to add a DynamoDB Table to our stack for our lambda function to pull data from. See Part 1 on getting started to get caught up.

Before we go too far, you are going to need:

Python 3.8 with Pip installed
AWS SAM CLI

Step 1 - Defining the table.

Install the DynamoDB CDK module, being careful to use the same release you used before.

npm install @aws-cdk/aws-dynamodb@1.33.1

And add it to our imports in lib/myapp-stack.ts.

import * as dynamodb from "@aws-cdk/aws-dynamodb";

Next, we can add a DynamoDB Table construct to our stack. DynamoDB is a no-sql database and requires you to think a little bit about how your data will be accessed. Read about the key concepts over here on dynamodbguide.com

const tourfinishersTable = new dynamodb.Table(this, "TourFinishersTable", {
  partitionKey: { name: "Year", type: dynamodb.AttributeType.NUMBER },
  sortKey: { name: "Position", type: dynamodb.AttributeType.NUMBER },
  tableName: "TourFinishers",
  billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
  removalPolicy: cdk.RemovalPolicy.DESTROY,
});

We have chosen in this instance to make the Year the primary key and Position the sort key, together this will be a unique value within this simple context a high cardinality. It will support our access pattern later as will.

Next step is to grant our function read access to the table.

tourfinishersTable.grantReadData(myFunction);

I think this is one of the most powerful features of CDK, it makes dealing with permissions so easy that you don't feel the need to grant overly permissive policies.

Step 2 - Updating out function

Our python function is going to be a little more complex than before and will require some dependencies. Therefore we first need to move it into its own src directory.

mkdir function/src
mv function/index.py function/src/

Next, we will want to add a requreiments.txt file at function/src/requirements.txt and add the following dependencies.

boto3>=1.12.43

Now we will write a build.sh script at the base of our project to build are code bundle. AWS Lambda's require a code bundle to come pre-packaged with all its dependencies.

#!/bin/bash

mkdir -p function/_bundle
pip3.8 install -r function/src/requirements.txt --target function/_bundle
cp -r function/src/* function/_bundle
pushd function/_bundle
zip -r --quiet ../bundle.zip .
popd
rm -rf function/_bundle

And now we can update our code function/src/index.py to pull the data from dynamoDB.

import boto3
from boto3.dynamodb.conditions import Key

logger = logging.getLogger()
logger.setLevel(logging.DEBUG)

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('TourFinishers')

def main(event, context):
    logger.info("Start of function")

    response = table.query(
        KeyConditionExpression=Key('Year').eq(2019)
    )

    return {
        "statusCode": 200,
        "body": response["Items"],
        "headers": {
            "Content-Type": "application/json"
        }
    }

Next, we run ./build.sh to build are bundle and then we can point CDK at our code bundle by updating the code property of our lambda in lib/myapp-stack.ts.

code: lambda.Code.fromAsset(
  path.join(__dirname, "../function/bundle.zip")
),

Step 3 - Deploy the changes

Simply build and deploy are changes to AWS.

npm run build
cdk deploy

To speed things along for this demo, I have a gist that has the top 3 winners of the last 3 Tours that we can import into our table in AWS directly.

aws dynamodb batch-write-item --request-items https://gist.githubusercontent.com/almcc/1437d07e5f344bb8a5b03376a9473af2/raw/a96c545774c5a046b8e7b32e597ded0f7a84306c/TourFinishers.json

Step 4 - Execute to lambda

Now to run your function in AWS we can use the AWS command.

aws lambda invoke --function-name MyappStack-MyFunction3BAA72D1-1H78B5LRDK3NI >(cat | jq) --log-type Tail | jq --raw-output .LogResult | base64 -d

You should see something a bit like this as the output.

{
  "statusCode": 200,
  "body": [
    {
      "RiderNumber": 2,
      "Position": 1,
      "FirstName": "Egan",
      "LastName": "Bernal",
      "TeamName": "Team INEOS",
      "Year": 2019
    },
    {
      "RiderNumber": 1,
      "Position": 2,
      "FirstName": "Geraint",
      "LastName": "Thomas",
      "TeamName": "Team INEOS",
      "Year": 2019
    },
    {
      "RiderNumber": 81,
      "Position": 3,
      "FirstName": "Steven",
      "LastName": "Kruijswijk",
      "TeamName": "Team Jumbo-Visma",
      "Year": 2019
    }
  ],
  "headers": {
    "Content-Type": "application/json"
  }
}
...

Bonus Step - Running the function locally

You can also run the function locally with the AWS sam CLI which can be handy during development.

The first thing to do is to get hold of the CloudFormation template that CDK is creating behind the scenes for us.

cdk synth --no-staging > template.yaml

Now you can use the sam CLI to invoke your function. (Check the contents of template.yaml for the functions name)

sam local invoke MyFunction3BAA72D1 --no-event | jq

This will run your code locally, using your local credentials to query the live table in AWS.

Then if you make any changes to you code you will need to run ./build.sh again, if you make a change to your template, you will need to do the following.

npm run build
cdk synth --no-staging > template.yaml

Job done!

That's it for this post, Next time we will look at adding the API gateway.

If you would like to clean up everything you have created in AWS, see Step 6 - Cleaning up from the first post in this series.

Getting into Serverless with CDK, Lambda & DynamoDB - Part 1

Alastair McClelland — Tue, 21 Apr 2020 18:35:49 +0000

AWS Cloud Development Kit (CDK) is a great tool for using code to deploy resources to AWS. In a series of posts, we will cover a few of the key concepts you need to be aware of getting started with AWS and CDK. We will create a Lambda Function that returns some data from a DynamoDB table over an API Gateway.

CDK allows you to define Constructs in code that map to AWS components or resources, you can then collect those Constructs together into a Stack which is what we deploy to an AWS region. Finally, a Stack is defined within an App which is the root of our project, it can contain many instances of the same stack for say multiple regions or multiple different stack instances.

You can choose to develop CDK projects with TypeScipt, JavaScript, Python Java or C#. While initially learning CDK I went for Python as it is usually my language of choice, I have later found TypeScript to be much more comfortable as there is a wealth of examples already out there. We will use TypeScript for this post.

Note: Many tutorials and guides on learning AWS will suggest using the web console to setup and configure resources, however, beyond simple examples I have felt uncomfortable building so much in an unrepeatable fashion. If you are someone who learns by doing, then a pattern I have found works really well is building a setup partially with CDK, then using the web console to learn and experiment further before refactoring those changes back into the CDK stack itself. Simply rinse and repeat to develop ever bigger or more bespoke setups. Having AWS best practice built into the CDK constructs is a comforting safety net.

So that is already too many words, let's get started.

Prerequisites

You have the AWS CLI installed and configured, this post was created using V1 of the CLI however both V1 and V2 should work. The aws configure list command is a good way to test if you have your credentials set up correctly. For those of you who use profiles with the --profile flag, the cdk command works in the same way,

Step 1, Install the CDK CLI.

Assuming you have node already installed, you just now need TypeScript and the CDK CLI

npm install -g typescript
npm install -g aws-cdk

Step 2, Create our project.

Let's make a directory and initialise a typescript app project.

mkdir myapp
cd myapp/
cdk init app --language typescript

And a quick test that it builds ok.

npm run build

Step 3, The Lambda Function

Install the lambda package.

npm install @aws-cdk/aws-lambda

Add the dependency to our stack (lib/myapp-stack.ts).

import * as cdk from "@aws-cdk/core";
import * as lambda from "@aws-cdk/aws-lambda";

export class MyappStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // The code that defines your stack goes here
  }
}

Next, we need to write some function lambda code. Create a file inside a newly created function directory (function/index.py). In this case, we are just going to return the top 3 finishers of the 2019 Tour de France, later we will work on returning their names from a DynamoDB table.

import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)


def main(event, context):
    logger.info("Start of function")
    return {
        "statusCode": 200,
        "body": ["Egan Bernal", "Geraint Thomas", "Steven Kruijswijk"],
        "headers": {
            "Content-Type": "application/json"
        }
    }

Notice that I have also set up a logger with a simple logging statement, this will be useful later to demonstrate how we retrieve those logs.

Now we need to define our lambda function in our stack, we can use the Function construct from the aws-lambda package. Inside the MyappStack construct in lib/myapp-stack.ts add the following code.

const myFunction = new lambda.Function(this, "MyFunction", {
  runtime: lambda.Runtime.PYTHON_3_8,
  handler: "index.main",
  code: lambda.Code.fromAsset(path.join(__dirname, "../function")),
});

Don't forget to add import * as path from "path"; as well.

You can see that I have defined a function imaginatively named MyFunction, it uses the Python 3.8 runtime, it's handler points to main function inside the [index.py](http://index.py) module and finally, the code lives in the function directory which is in the parent directory to our lib directory.

As it stands, this is enough for us to deploy our code. However, to invoke our function later we are going to need the function name that is created. CDK will take our MyFunction name and add's to it to make sure that it's unique. To extract that name of the function that will be created in AWS we can add a CloudFormation Output to our stack.

Again in lib/myapp-stack.ts and the following code under our lambda function declaration.

new cdk.CfnOutput(this, "FunctionNameOutput", {
  value: myFunction.functionName,
  exportName: "Lambda-Function-Name",
});

Note here that the exportName is the identifier for how we will reference the value and it must be unique across your entire AWS account, regardless of the stack. You can also see the reason we defined our function to a variable.

Step 4, Build and Deploy

Let's quickly check that our project builds.

npm run build

We can also check that CDK can successfully convert (or synthesise) are code into a CloudFormation template.

cdk synth

I tend to pipe the output of cdk synth to less as output is long and it's useful to have a way to search it.

cdk synth | less

If all that worked then we are almost good to go. If this is the first time out have deployed a CDK project to your aws account you will need to bootstrap you account.

cdk bootstrap

Now we are ready to deploy our stack.

cdk deploy

You will be asked to approve any IAM policies and statements that CDK is creating. This is also a good insight into how policies are stitched together in AWS as well as a good reminder of the heavy lifting that CDK is doing for you.

When making changes to your project and deploying again, it can be useful to chain the build command and the deploy command together to avoid deploying a stale stack without your changes and then scratching your head as to why you change didn't work.

npm run build && cdk deploy

As I have used &&, cdk deploy will only run if the previous command (the build command) succeeds.

Step 5, Invoking our Function

In the output of the deploy command, you should see our CloudFormation Output. It will look a little like the following:

Outputs:
MyappStack.FunctionNameOutput = MyappStack-MyFunction3BAA72D1-173G8DYDM9QA7

This is a function that we are now ready to invoke. We can do this with the aws lambda invoke command.

aws lambda invoke --function-name MyappStack-MyFunction3BAA72D1-173G8DYDM9QA7 out.txt

This will invoke our function and push the output to out.txt which should look like this.

{"statusCode": 200, "body": ["Egan Bernal", "Geraint Thomas", "Steven Kruijswijk"], "headers": {"Content-Type": "application/json"}}

If you also want to see the logging output you can use the --log-type Tail option and it will include the LogResult in the function invocation response that was printed to the terminal.

aws lambda invoke --function-name MyappStack-MyFunction3BAA72D1-173G8DYDM9QA7 out.txt --log-type Tail

Unfortunately, this will be in base64. You can paste it into your favourite base64 decoder to view the logs. For example, you could use the base64 command.

echo <insert-base64-content-here> | base64 -d

You should get some output that looks a little like this:

START RequestId: 1fc4012a-3963-449b-8085-347e0a12e961 Version: $LATEST
[INFO]  2020-04-21T05:47:14.519Z        1fc4012a-3963-449b-8085-347e0a12e961    Start of function
END RequestId: 1fc4012a-3963-449b-8085-347e0a12e961
REPORT RequestId: 1fc4012a-3963-449b-8085-347e0a12e961  Duration: 1.15 ms       Billed Duration: 100 ms Memory Size: 128 MB     Max Memory Used: 49 MB

Warning: Below I get a little sidetracked with command line tricks, if you are not a fan of the one-liner bash commands please feel free to skip ahead, otherwise make sure you have the jq command installed and read on!

We could also use some jq trickery to do that on the command line with the base64 command.

aws lambda invoke --function-name MyappStack-MyFunction3BAA72D1-173G8DYDM9QA7 out.txt --log-type Tail | jq --raw-output .LogResult | base64 -d

While we are at it, it can be cumbersome to always be having to peek inside the out.txt file to see the output. We can avoid creating that file all together with the use of a process substitution that will work in most shells. We can also use jq again to clean up the output. We simply replace out.txt with >(cat | jq).

aws lambda invoke --function-name MyappStack-MyFunction3BAA72D1-173G8DYDM9QA7 >(cat | jq) --log-type Tail | jq --raw-output .LogResult | base64 -d

You should now see the output of your lambda function printed cleanly to the terminal followed by any logging.

Finally, while we are down this rabbit hole, could we pull out the function name from CloudFormation programmatically so that you can just copy and paste the command? Well, yes we could.

aws lambda invoke --function-name $(aws cloudformation list-exports --query 'Exports[?Name==`Lambda-Function-Name`].Value' --output text) >(cat | jq) --log-type Tail | jq --raw-output .LogResult | base64 -d

Step 6, Cleaning up

We have covered quite a bit there already and your at the point where you can experiment further on your own. In the next post, we will look at building a DynamoDB table and querying our data.

You could choose to leave your stack in place, AWS gives you 1 Million free lambda invocations per month and the S3 Bucket created by CDK will be free if your account is less than 12 months old.

However, if you would like to destroy your stack you can do the following.

cdk destroy

And if you would like to remove the CDKToolkit stack you will need to use the aws command to get the name of the cdk bucket (or use the web console)

aws s3 ls

You can then empty the bucket and delete the stack.

aws s3 rm s3://cdktoolkit-stagingbucket-19rslbj9gvcos --recursive
aws cloudformation delete-stack --stack-name CDKToolkit