Python

Generate Synthetic JSON Requests to Test an API on macOS built two generators and a CLI that fires batches at an order-intake API. This article puts the same generators behind an MCP server, so an agent can preview a payload, check the target, and trigger a batch by asking for one. Wrapping a generator in tools is the easy half. The half worth attention is the control surface: which decisions the caller gets to make and which ones the server keeps. A model that can pick the destination of a traffic generator is a server-side request forgery primitive with a friendly name, and a model that can pick the batch size can turn one sentence into fifty thousand POSTs. Here the target comes from the environment and the batch size is capped, so the tools stay useful without handing over either decision. ...

Hand-written JSON fixtures cover the two or three cases you thought of while writing them. A generator covers hundreds, and it keeps covering them after the schema changes. This article builds two generators for the same order-intake API: a naive one that invents every field from random primitives, and a second one that samples a JSON seed database so every request refers to a product and a customer the API actually knows about. ...

uvx ruff check . works without installing anything. That is the whole appeal: one command, a throwaway environment, nothing left behind. It is also the problem. Every invocation re-resolves the package, the version you get today is not necessarily the version you got last week, and which ruff comes back empty because there is nothing on PATH. uv tool install is the other half of the story. It builds a persistent, isolated environment for a Python CLI and links its executables into a directory on your PATH, so ruff becomes a real command with a version you chose and control. Homebrew’s pipx niche, in other words, handled by the tool you already have. ...

Most teams have a procedure that only lives in someone’s head. Cutting release notes, triaging a breaking change, prepping an on-call handoff: five steps, done slightly differently every time, and badly the week the person who knows them is on vacation. MCP gives you three primitives to fix that, and the interesting one is the least used. Tools are called by the model. Resources are read for context. Prompts are chosen by a person: named, parameterized templates a client surfaces as a slash command. That makes a prompt the natural home for a procedure — the user picks it, fills in one argument, and the model runs the same five steps in the same order every time. ...

A resource that returns a picture is the most demanding shape an MCP resource takes. It has to survive base64 encoding, arrive with a MIME type the client will accept, stay small enough to attach, and — if the picture is meant to reflect something live — return different bytes the next time the same URI is read. Serve Resources Well from an MCP Server on macOS covered the shapes of resources with an eight-byte PNG magic number standing in for a binary body. This article replaces that stub with a real image: a bar chart rendered on every read from state that anything can change, packaged so uvx runs it from a local directory, and wired into opencode so a model can read it, watch it change, and read it again. ...

Give a language model a database tool and the obvious failure mode is not a clever exploit. It is a well-meaning model running DELETE FROM orders because a prompt told it to “clean up test data,” or issuing SELECT * FROM events against a billion-row table and stalling everything behind it. A database MCP server has to assume the caller is careless, and sometimes hostile. In this tutorial you will build a FastMCP server that exposes a Postgres database to an MCP client as strictly read-only, with the safety built in layers so no single mistake opens a hole: ...

A sibling article, Publish a FastMCP Server to PyPI and Run It Anywhere with uvx, ships a package to the public PyPI index. This one skips the index entirely. If your code is a Git repository, uvx can install and run its console script straight from the repo: uvx --from git+https://github.com/your-username/textkit textkit --help That command clones the repo into a cached, throwaway environment, builds the package, and runs its console script — no git clone, no virtualenv, no pip install on the user’s side. For a personal utility, an internal tool, or anything you are not ready to name on PyPI, a GitHub repo is the whole distribution channel. ...

Packaging an MCP server as a Docker image gives clients one launch command with no Python, no uv, and no virtual environment to manage on the host: they run the container. This tutorial builds a small, non-root image for a FastMCP server with a multi-stage build, runs it over stdio the way a client does, and wires it into a client’s .mcp.json with docker run. The build uses uv in the builder stage and copies only the finished virtual environment into a slim runtime stage, so the final image carries the app and its dependencies — not the build toolchain. ...

An installable MCP server needs the same release discipline as any Python package: lint and test every change, build the artifact, and publish on a tagged release. This tutorial wires that pipeline with GitHub Actions and uv — ruff for linting and formatting, pytest for tests, uv build for the wheel/sdist, and PyPI trusted publishing (OIDC, no stored token) on a version tag. It is the CI/CD companion to Publish a FastMCP Server to PyPI and Run It Anywhere with uvx. ...

An MCP server is an attack surface. It runs with real privileges (a filesystem, API credentials, a database), it accepts arguments chosen by a model that may be under an attacker’s influence, and its results flow straight back into a model’s context. Most MCP defenses are the server author’s responsibility — the client cannot enforce them for you. This tutorial builds one hardened FastMCP server, a sandboxed “knowledge base,” and demonstrates a defense for each of the common MCP threats: input validation, the confused-deputy problem, prompt injection carried in tool results, tool poisoning, and the token-passthrough anti-pattern. Every defense is backed by a test, so you can see it hold. ...