The tools in the earlier articles computed their answers locally. Most useful tools instead reach out to an external service: a weather API, a payments provider, an internal microservice. That introduces three problems a naive httpx.get ignores: where the API key lives, what happens when the call is slow, and how a failure reaches the user. This article builds a FastMCP tool that calls a real HTTP API and handles all three, the macOS way. ...

Every deployment article so far bound the server to 127.0.0.1 over plain HTTP. That is correct for local use and unusable for anything else: a client on another machine cannot reach loopback, and sending bearer tokens or OAuth codes over plain HTTP leaks them. The fix is a TLS reverse proxy. This article puts Caddy in front of a FastMCP server so it is reachable over HTTPS, with certificates Caddy obtains and renews on its own. ...

Gate a FastMCP Server to Paying Customers sold tiered access: Basic and Pro plans. Selling tiers only matters if the tiers actually differ, and the most common difference is how much a customer may call. This article adds per-plan rate limiting to a FastMCP server: a middleware reads each caller’s plan from their verified token and enforces that plan’s request quota, keyed on the caller’s identity. A Basic customer gets a small quota, a Pro customer a larger one, and over-limit calls are rejected cleanly. ...

Two earlier articles secured a FastMCP server two ways: Gate a FastMCP Server to Paying Customers verified opaque license keys you minted and stored yourself, and Add GitHub OAuth delegated login to GitHub. This one takes a third path that sits between them: you run your own token authority that issues asymmetrically signed JWTs, and the server verifies each token’s signature against a JWKS (JSON Web Key Set) it publishes. No per-request database lookup, no third-party login. The signature and claims are self-contained, and only the holder of the private key can mint a valid token. ...

In Gate a FastMCP Server to Paying Customers you minted your own license keys and verified them yourself. That works, but it means you own the hard parts: issuing credentials, storing them, revoking them. This tutorial takes the other approach: delegate authentication to a real identity provider, GitHub, using FastMCP’s GitHubProvider. Your server never sees a password; users log in with GitHub, and the MCP client handles the whole OAuth 2.0 dance (Dynamic Client Registration, the browser login, PKCE, token exchange). ...

The FastMCP tutorials so far returned pure, stateless results. Real tools usually need state that persists — a record that is still there after the process restarts. In this tutorial you will build a FastMCP task-manager server whose tools read and write a SQLite database, so tasks survive restarts, redeploys, and reboots. You will separate the persistence layer (db.py) from the MCP tools (server.py), expose a live-stats resource, cover it with pytest (including a test that proves data survives a restart), and deploy it as a launchd service. The stack is Mac-native: uv, make, and Python’s built-in sqlite3 — no database server to install. ...

MCP tools usually return text. But a tool can also return media (an image, a document), and sometimes the right answer isn’t the bytes at all but a link to them. This tutorial builds a FastMCP server that does both, and lets you choose per request: Inline delivery — the tool returns the media object directly (a PNG image, an SVG image, a Markdown document). Best for small, renderable results. Link delivery — the tool stores the bytes in a bucket and returns a URL. The URL is either permanent or expiring after N minutes. Best for large media (video) or anything you want to share by link. The bucket here is self-contained: the server stores files in a local directory and serves them itself over HTTP, using HMAC-signed URLs so an expiring link simply stops working after its time-to-live — no per-object cleanup job. The last section shows how to swap in real object storage (S3/R2/GCS presigned URLs) without touching the tools. The stack is Mac-native: uv, make, and a launchd service. ...

The friendliest way to ship a Python command-line tool today is to make it runnable with uvx, uv’s equivalent of pipx run. A user types uvx macmcp and uv fetches the package, builds an ephemeral environment, and runs it, with no clone, no virtualenv, and nothing left installed. That is a perfect distribution model for a FastMCP server: you publish once, and anyone can run your MCP server (or wire it into an MCP client config) with a single command. ...

Most tutorials hand you code to type. This one does the opposite: you will stand up a FastMCP server on your Mac in which you never write a line of application code. You describe behavior in plain English and Cucumber/Gherkin scenarios, and Claude Code (driven by subagents and slash commands you configure once) writes and maintains server.py until every scenario passes. Your entire job is to run make (or let CI run it). ...

Building an MCP server is easy; making sure only the people who paid for it can call it is the part that turns a demo into a product. In this tutorial you will build a FastMCP server that authenticates every request against a license store: paying customers hold a license key, the server verifies it, and unknown or expired keys are rejected with 401 Unauthorized. Premium tools are further gated so that only the Pro plan can call them. ...