MCP: tools you can share

You've been writing tools for your app. Now imagine you've built a great set for your company's issue tracker, and you want them in Claude Code, in Claude Desktop, in your teammate's editor and in your own agent. Rewriting them for each one gets old fast.

The Model Context Protocol (MCP) is the open standard for this. You package tools once as an MCP server, and any app that speaks MCP can use them. The MCP site compares it to a USB-C port: one plug shape, lots of devices. Claude, ChatGPT, VS Code and Cursor all support it.

Three roles, in MCP's words. The host is the AI app (Claude Code, say). It opens a client connection to each server it uses. A server can offer tools (actions), resources (data to read) and prompts (reusable templates). Tools are the part you already know.

Look at the first tab. That's what an MCP server answers when a client asks for its tools (a tools/list request, trimmed here). It's the same three parts you've written all course: a name, a description and a JSON Schema for the input, spelled inputSchema. Everything you learned about descriptions applies here too. An MCP server with vague descriptions is just as confusing, in every app at once.

How you plug one in depends on the host. In Claude Code, it's one command: claude mcp add <name> <command>. Local servers run on your machine and talk over standard input and output (stdio). Remote servers run on the web and talk over Streamable HTTP.

From your own code, you have two options. The MCP connector (second tab) lets the Messages API connect to a remote server for you. It's a beta, it only does tools, and it can't reach local stdio servers. Or you use an MCP client library in your app, list the server's tools, and pass them to Claude as ordinary client tools: the same round trip you already know.

One caution. An MCP server is code someone else wrote, and its tool results are text someone else controls. Install servers from sources you trust, and take extra care with tools that write, delete or spend money.