AI

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

This is the Rust companion to Build an MCP Server in Go with the Official SDK and Build an MCP Server in TypeScript with the Official SDK. It builds the same kind of server — two tools and a resource — with the official Rust SDK (rmcp), served over the stdio transport so a local client launches it as a subprocess. The result is a single compiled binary with no runtime beyond itself. ...

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

Resources are the read side of MCP: addressable, cacheable data a client fetches by URI, separate from the tools that take action. Serving them well means more than returning a string. A resource has a MIME type, metadata a client shows in a picker, a choice between a fixed URI and a parameterized template, a text-or-binary body, and, for data that changes, a way to push updates instead of making clients poll. ...