Posts

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

Sometimes the MCP server you want your team to use already exists — published to a registry, a GitHub repo, or a container image by someone else. You do not need to fork it or vendor its source into your plugin. A Claude Code plugin can be pure configuration: a .mcp.json that tells Claude Code how to launch that external server over stdio, wrapped in a manifest and a marketplace so a teammate installs it with one command. ...

A Claude Code plugin can ship an MCP server the same way it ships a command or a hook: drop a .mcp.json at the plugin root, and Claude Code starts the server for anyone who installs the plugin. The user runs no pip install, edits no config, and copies no path. They install the plugin, and the server’s tools appear. The trick that makes this painless is launching the server with uv run --script against a file that declares its own dependencies inline (PEP 723). The consumer needs only uv on their PATH; uv builds an ephemeral environment with the right packages on first run. No committed virtualenv, nothing to install ahead of time. ...

A Claude Code plugin is a directory with a .claude-plugin/plugin.json manifest that bundles the things you would otherwise drop into ~/.claude/ by hand: slash commands, subagents, hooks, skills, and MCP servers. Wrapping them in a plugin turns a pile of personal config into one versioned artifact that a teammate installs with a single command, namespaced so it never collides with their own setup. This tutorial builds one plugin that uses three of those surfaces at once, then distributes it through GitHub: ...

A Claude Code skill is a SKILL.md file plus optional supporting files that teach Claude a repeatable procedure. Kept in ~/.claude/skills/ or a project’s .claude/skills/, a skill is personal or project-local. To hand one to a teammate, ship it across every project, or publish it to the community, you wrap it in a plugin and list that plugin in a marketplace that others can add with one command. This tutorial builds a real skill, packages it as a plugin, catalogs it in a marketplace, validates the manifests with the claude CLI, tests it locally, and distributes it through GitHub. The end result is a repository anyone can install with /plugin marketplace add your-org/your-repo followed by /plugin install. ...

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

Build a Hugo static site whose /premium/ section is locked behind a Stripe subscription, with the access decision made by a Cloudflare Worker at the edge. Free posts stay cached and public. A request for a premium page runs the Worker first: it checks a signed session cookie and confirms the subscription is still active in KV before it hands back the file. Payment, activation, and cancellation flow through Stripe Checkout and a webhook. ...