You wire Claude into your database. Then you want the same lookup inside your editor, so you write a second integration. Then a third AI app ships and you write it again — three integrations doing one job, three sets of auth and quirks to maintain. That is the problem MCP solves, and it is the reason I keep coming back to one question from other developers: what is an MCP server? The plain answer: it is a small program that exposes your tools and data to an AI assistant through the Model Context Protocol, an open standard introduced by Anthropic. You write the server once, and every MCP-compatible client — Claude Desktop, Claude Code, various IDEs — can use it. I have built a couple of these now, and the mental model that finally made it click for me is that MCP is an API for AI assistants.
What does an MCP server actually expose?
An MCP server exposes three kinds of things to a client. Each maps to a different need the model has during a conversation:
- Tools — actions the model can call. Example: a create_issue tool that files a ticket in your tracker, or a run_query tool that executes SQL against a read replica.
- Resources — data the model can read. Example: the contents of a file at config://app/settings, or a row from a database the model can pull in as context.
- Prompts — reusable templates. Example: a 'summarize-pr' prompt that takes a diff and produces a standardized review, so the user does not retype the instructions every time.
The distinction matters in practice. Tools have side effects and the client may gate them behind a confirmation. Resources are read-only context. Prompts are user-invoked shortcuts. When you design a server, deciding which bucket each capability falls into is most of the work.
Write one MCP server and every MCP-compatible client can use it, instead of building a custom integration per app. That single shift is why the standard caught on.
Why does this matter to a working developer?
The honest reason MCP matters is that it kills the N-times-M integration problem. Say you have four data sources and three AI clients. Without a standard, that is potentially twelve bespoke integrations, each with its own auth, its own quirks, its own maintenance burden. With MCP it is four servers and three clients that already speak the protocol — they just connect. This is the same reason REST and the language server protocol won: a shared contract means you build the hard part once. If you have already wired Claude into your stack with custom glue, this is the cleaner path — I wrote more about the broader approach in connecting Claude to your tools.
There is a second, quieter benefit. Because the contract is standardized, the tooling around it is too. SDKs exist for TypeScript and Python, so you are not hand-rolling JSON-RPC framing. You describe your tools, the SDK handles the wire format.
How does a client connect to a server? Transports and config
MCP defines two transports, and which one you pick depends on where the server runs. Use stdio for a local server that the client launches as a subprocess — the client spawns your process and talks to it over standard input and output. Use Streamable HTTP for a remote server the client reaches over the network. Local file-system tools are almost always stdio; a shared team service is HTTP.
Registering a server is mostly configuration. Here is a minimal client config that wires up two stdio servers — the official filesystem server and a hypothetical local one:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/you/projects"
]
},
"my-db": {
"command": "node",
"args": ["./build/my-db-server.js"],
"env": {
"DATABASE_URL": "postgres://localhost:5432/app"
}
}
}
}The client reads that, launches each command as a subprocess, and the two servers' tools and resources become available in the conversation. No code change in the client — it is all config. For Claude Code specifically, you install it with npm install -g @anthropic-ai/claude-code, then register servers either through this kind of config or its own commands.
What does a tiny server look like?
Here is a minimal stdio server in TypeScript that exposes one tool. This is the whole shape: create a server, register a tool with a name, a description, and an input schema, implement the handler, then connect over stdio.
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
const server = new McpServer({
name: "order-lookup",
version: "1.0.0",
});
server.tool(
"get_order_status",
"Look up the current status of a customer order by its ID",
{ orderId: z.string().describe("The order ID, e.g. ORD-1234") },
async ({ orderId }) => {
const status = await db.orders.statusFor(orderId);
return {
content: [{ type: "text", text: `Order ${orderId}: ${status}` }],
};
}
);
const transport = new StdioServerTransport();
await server.connect(transport);That description string is not decoration — the model reads it to decide when to call the tool, so be prescriptive about when it applies, not just what it does. The input schema is plain JSON Schema (here via Zod), the same shape you would pass in the tools array of a direct Claude API call to POST /v1/messages. Under the hood, tool use is the same mechanism: the model returns a tool_use block, the client routes it to your server, your handler runs, and the result goes back as a tool_result.
Where does this go from here?
The ecosystem already has servers worth stealing from. The filesystem server gives a model scoped read and write access to a directory. The GitHub server exposes issues, pull requests, and repository contents as tools and resources. Database servers let a model run read queries against Postgres or SQLite without you exposing raw credentials to the model. You can run these as-is or read their source as a template for your own. If your stack is WordPress, I walked through a concrete setup in configuring an MCP server for WordPress, and for remote boxes there is running Claude Code on a remote Linux server.
Where it is heading is more interesting than any single server. As more clients ship MCP support, the value of writing a server compounds — the same server that helps you in your editor today works in whatever AI tool you adopt next year, because they all speak the protocol. If you want the canonical spec and the server registry, the open standard lives at modelcontextprotocol.io. My advice: pick one painful manual workflow, expose it as a single tool, and wire it into a client you already use. You will understand MCP better from one working tool than from any amount of reading.
