Python

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. ...

The MCP Inspector is the official developer tool for MCP servers. It has two faces: a web UI for clicking through tools, resources, and prompts interactively, and a CLI mode that drives the same server headlessly and prints JSON — scriptable, diffable, and easy to drop into a Makefile or CI. This tutorial uses both against a small FastMCP server, then reproduces and diagnoses a broken stdio handshake, the most common failure when a client refuses to connect. ...

An email allowlist answers one question: is this caller allowed in at all? Real servers need a second answer: which of my tools may this particular caller use? A reader should be able to list notes but never delete one; an admin should be able to delete anyone’s. That is authorization, and FastMCP gives you two levers for it: a declarative require_scopes(...) on each tool, and the caller’s identity inside a handler for checks a static scope cannot express. ...

Most MCP servers get a handful of assert result == ... tests bolted on and nothing more. That misses the failures that actually bite: a tool quietly renamed, a parameter that changed type, a result that grew a field, an error that stopped being an error. A server is a contract a model depends on, and the contract needs its own tests. This tutorial builds a small, deterministic FastMCP server and then a layered test suite around it with four kinds of tests, each catching a different class of regression: ...

A command-line tool you already trust makes a good MCP tool: it has a stable interface, it is installed on the box, and its behavior is documented. The work is not reimplementing it, it is exposing it safely — mapping subcommands and flags to typed inputs, feeding untrusted input as data rather than shell, bounding runtime, and turning a non-zero exit into a clean tool error instead of a stack trace. ...

If you already run a FastAPI service, you do not have to hand-write an MCP tool for each endpoint or maintain a separate OpenAPI file. FastMCP.from_fastapi takes the app object itself, reads the schema FastAPI already generates, and mounts the app in-process: every operation becomes an MCP tool, resource, or resource template, and each call runs the real route handler with no network hop. The API stays the single source of truth for schemas, validation, and behavior. ...

If a service already publishes an OpenAPI spec, you do not have to hand-write a tool for each endpoint. FastMCP.from_openapi reads the spec and generates the whole server: every operation becomes an MCP tool, resource, or resource template, and each call is proxied to the real API through an HTTP client you supply. Point it at a spec, attach your auth, decide which routes to expose, and you have an MCP server. ...