Python

You have a working MCP server (see Build an MCP Server with FastMCP and Create and Deploy a FastMCP Server on macOS). A server on its own does nothing until a client connects to it. This tutorial wires one server into the two Claude clients you are most likely to use on a Mac: Claude Code (the CLI) and Claude Desktop (the chat app). They use different configuration systems, so each gets its own walkthrough, and the tricky remote case gets a mcp-remote bridge. ...

In Add GitHub OAuth to a FastMCP Server you delegated login to GitHub. That is a good fit when your users already have GitHub accounts, but it ties your server to one social provider. This tutorial uses Clerk instead: a full authentication platform where you own the user directory. Clerk gives you email/password, magic links, social logins, and MFA behind a single OAuth authorization server, and FastMCP’s ClerkProvider plugs that server into your MCP server with a few lines of configuration. ...

The previous tutorial built a uv workspace with a single packages/ folder holding a library and a CLI. That layout mixes reusable libraries and runnable programs in one directory. A common convention is to split them: packages/ for importable libraries, apps/ for deployable programs. This tutorial builds a workspace with both, where a shared greetings library in packages/ is consumed by two apps in apps/: a simple command-line app and a FastAPI web app. A root Makefile runs, serves, and tests every member. ...

A uv workspace lets several related Python packages live in one repository, share a single lockfile and virtual environment, and depend on each other by name without publishing to a registry. This tutorial builds a two-package workspace: a greetings library and a cli application that imports it. A root Makefile drives sync, run, test, and inspection across every member with one command each. By the end you will have a reproducible layout where editing the library is immediately visible to the application, and make test runs every package’s tests in one pass. ...

Most of the MCP articles in this repo connect an agent downward to tools: an agent is a client, and a server exposes functions it can call. That is the vertical axis. The Agent2Agent (A2A) protocol covers the horizontal axis, where one agent talks to another agent as a peer. Instead of “call this function,” the message is “here is a task, you handle it and report back.” The two protocols are complementary: an agent can be an MCP client (reaching down to tools) and an A2A server (answering peers sideways) at the same time. ...

The earlier MCP articles built servers that expose tools and a client that calls those tools by hand: you name the tool, you supply the arguments. An agent is the piece that makes those decisions for you. Given a question and a set of MCP tools, it asks a model which tool to call, runs it, feeds the result back, and repeats until the model has an answer. This article builds that agent with the Anthropic Python SDK and FastMCP, on macOS with uv, make, and pytest. The loop is the standard Anthropic tool-use loop; the only twist is that the tools come from an MCP server instead of being defined inline. ...

As an MCP deployment grows, one giant server file stops scaling. FastMCP offers two ways to build bigger servers from smaller ones: Composition mounts independently-developed sub-servers into one gateway, so a team can own a math server and another own a text server, and a client sees them as one. Proxying puts a FastMCP server in front of an existing MCP server (even a remote one), forwarding every request to it. That lets you add TLS, auth, or rate limiting in front of a server you do not control, or expose a remote server under your own address. This article builds both: a gateway composed from two sub-servers, and a proxy that fronts an existing HTTP server. The stack is Mac-native: uv and make. ...

Most tools take their inputs up front and return an answer. Two MCP capabilities turn that around and let a tool ask the client for something mid-run: Elicitation asks the user for structured input, so a tool can request a missing value or a confirmation instead of failing. Sampling asks the client’s LLM for a completion, so a tool can use the model the client already has rather than calling one itself. Both are server-to-client requests: the tool pauses, the client answers, and the tool continues. This article builds a FastMCP server that uses each, and a client that answers them. The final tool chains the two: it elicits who a bio is for, then samples the model to write it. The stack is Mac-native: uv and make. ...

A tool that returns in a few milliseconds needs no ceremony. A tool that runs for several seconds does: without feedback, the client looks frozen, and a user (or a model) cannot tell a slow success from a hang. MCP solves this with progress notifications and log messages that stream back to the client while the tool is still running. This article builds a FastMCP tool that reports progress as it works, and a client that renders a live progress bar from those notifications. ...

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