What Is MCP (Model Context Protocol), and Why Did It Suddenly Matter So Much?

Last post compared a hand-built agent against a trigger-action platform. One line from the very first post in this series has been sitting unexplained since: MCP, mentioned there as one of the reasons agents got practical, without saying what it actually is. It's time to open that up properly.

MCP, the Model Context Protocol, is an open standard for connecting an AI model to tools and data sources, so that a tool gets built once, as an MCP server, and any MCP-compatible application can use it without custom integration code for that specific pairing. Anthropic introduced it in November 2024; within months OpenAI and Google had both adopted it, and in December 2025 Anthropic donated the protocol itself to a vendor-neutral Linux Foundation project, the Agentic AI Foundation, co-founded with Block and OpenAI. That's the “why now” in one sentence: a protocol one company controlled became infrastructure the whole industry maintains together.

The Problem It Actually Solves

Every tool shown in this series so far — get_weather, convert_currency, add_expense — was defined directly inside one piece of code, in the exact shape that one specific project needed. That's fine for one project. It stops being fine the moment a second project wants the same weather lookup: copy the function, copy the schema, copy the description, keep both copies in sync by hand forever. Multiply that by every tool and every project that wants it, and the number of custom integrations grows with both numbers at once.

flowchart TB
    subgraph "Without MCP: custom glue per pair"
        App1[App 1] -->|custom code| ToolA[Tool A]
        App1 -->|custom code| ToolB[Tool B]
        App2[App 2] -->|custom code| ToolA
        App2 -->|custom code| ToolB
    end
    subgraph "With MCP: one server, any client"
        AppX[App 1] -->|MCP| ServerA[Tool A as an MCP server]
        AppY[App 2] -->|MCP| ServerA
        AppX -->|MCP| ServerB[Tool B as an MCP server]
        AppY -->|MCP| ServerB
    end

Flow summary: Without MCP, every app needs its own custom integration code for every tool, so connections multiply as apps and tools multiply. With MCP, each tool is exposed once as a server, and any app that speaks the protocol can reach it without writing new integration code for that pairing.

What's Actually on Each Side

An MCP server is a small program that exposes one or more tools (and optionally data “resources” and reusable prompts) over a standard protocol. An MCP client lives inside an application — Claude Desktop, Claude Code, an IDE, your own agent — and knows how to talk to any server that follows the spec. The host is the application the person actually uses; it holds one or more clients, each connected to one server.

None of this replaces what the tool-calling post taught. A tool exposed through MCP still reaches the model as a name, a description, and a schema, exactly like the tools array built by hand in that post — MCP just defines a standard way to publish and fetch that definition instead of writing it into one project at a time. Every lesson about writing a clear, well-scoped description from the prompt-engineering post applies exactly as much to an MCP tool as to one defined inline.

A Real MCP Server

Install the SDK with npm install @modelcontextprotocol/sdk zod, save this as mcp/weather-server.ts, and run it with npx tsx mcp/weather-server.ts. On its own it just sits there listening — the next section shows how to actually talk to it.

// mcp/weather-server.ts
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

const weatherData: Record<string, { condition: string; temp_c: number }> = {
  Dhaka: { condition: 'humid and cloudy', temp_c: 31 },
  Chittagong: { condition: 'light rain', temp_c: 29 },
};

const server = new McpServer({ name: 'weather-server', version: '1.0.0' });

server.registerTool(
  'get_weather',
  {
    title: 'Get Weather',
    description: 'Get the current weather condition and temperature in Celsius for a named city.',
    inputSchema: { city: z.string() },
  },
  async ({ city }) => {
    const data = weatherData[city];
    const result = data ? { city, ...data } : { error: `no weather data for ${city}` };
    return { content: [{ type: 'text', text: JSON.stringify(result) }] };
  },
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main();

Compare this to the get_weather tool from the tool-calling post: same name, same description, same one input field. inputSchema here takes a plain object of Zod validators instead of hand-written JSON Schema, and the SDK converts it for you — that's the whole reason tools/list later shows a proper JSON Schema with a $schema field attached, generated rather than typed by hand. The tool talks over stdin and stdout using StdioServerTransport, which is why this process looks like it does nothing when run directly: it's waiting for a client to connect and speak the protocol, not printing anything to the terminal on its own.

Actually Talking to It

A real MCP host — Claude Desktop, Claude Code, an IDE — would spawn this process and handle the conversation automatically once it's added as a connection. To see the protocol itself work without installing a full host, the same SDK ships a client that can spawn the server and talk to it directly:

// mcp/test-client.ts
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';

async function main() {
  const transport = new StdioClientTransport({ command: 'npx', args: ['tsx', 'mcp/weather-server.ts'] });
  const client = new Client({ name: 'test-client', version: '1.0.0' });
  await client.connect(transport);

  const tools = await client.listTools();
  console.log(tools);

  const result = await client.callTool({ name: 'get_weather', arguments: { city: 'Dhaka' } });
  console.log(result);

  await client.close();
}

main();

Running this spawns weather-server.ts as a child process, does the real MCP handshake, lists exactly one tool with the Zod schema turned into JSON Schema, and gets back Dhaka's weather in the standard content shape — the same mechanics host applications use, just driven from a script instead of a chat window.

The Mistake That Took a Rewrite, Not a Fix

The first version of weather-server.ts ended with a bare await server.connect(transport); at the top level of the file. It type-checked fine. Running the client against it failed immediately with the connection closing before anything else happened. The actual cause had nothing to do with MCP: the way this file gets executed transforms it to a module format that doesn't support a top-level await, so the process crashed on startup before the server ever got a chance to listen. Wrapping the same two lines in an async function main() and calling it fixed the whole thing — a module-system detail, not a protocol detail, but one that fails exactly where an MCP server's entrypoint usually sits, so it's worth knowing before it surprises you too.

Common Mistakes With MCP

• Writing a top-level await at the entrypoint. Wrap server startup in an async function, the way main() does here, so the file runs the same way regardless of how the module system transforms it.
• Treating a vague tool description as a smaller problem on MCP than inline. It's the identical description field the prompt-engineering post covered — one bad sentence now affects every project that connects to this server, not just one.
• Connecting to a third-party MCP server without reviewing what it exposes. A tool's description is text that server controls, and the model reads it as an instruction, the same way it reads yours. Treat an unfamiliar server's tools with the same caution as any other untrusted input before wiring it in.
• Building a server for a tool that already has one. Public registries already list servers for common services like GitHub, Slack, and various databases; check before writing one from scratch.

What's Next

MCP solves how an agent reaches a tool it doesn't own. How far that agent gets to go on its own with the tools it has — one step at a time with a human checking in, or several steps unsupervised — is a different question, and the next one worth answering.

Frequently Asked Questions

Does MCP replace the tool-calling mechanism from earlier in this series?

No. An MCP tool still reaches the model as a name, a description, and a schema, exactly like the tools array built by hand in the tool-calling post. MCP is a standard way to publish and fetch that definition so it can be reused across projects, not a different mechanism underneath.

Do I need to build my own MCP servers?

Only for a tool that doesn't already have one. Public registries list thousands of existing servers for common services, so checking there first is usually faster than writing and maintaining one yourself.

Is it safe to connect to any MCP server I find?

Not automatically. A server's tool descriptions are text it controls, and the model reads that text as instructions the same way it reads a trusted prompt. Review what an unfamiliar server actually exposes before connecting it, the same caution worth applying to any input you don't control.