MCP Is Boring in the Best Possible WayMCP Is Boring in the Best Possible Way

The Model Context Protocol is a standard that lets LLMs call tools and read resources through a consistent interface. An MCP server exposes tools (functions the model can invoke), resources (data it can read), and prompts (reusable instructions). The client — Claude, Cursor, your own agent — connects to these servers over a standard transport and gets a uniform API regardless of what's behind it. That's the whole thing. It is, deliberately, not interesting. And that's why it's the most important piece of AI infrastructure to understand right now.

---

Why Boring Is the Point

HTTP is boring. JSON is boring. REST is boring. These are the protocols that built the web precisely because they were boring enough that everyone could implement them, compose them, and build on them without negotiating a new handshake every time.

MCP is that for AI tool use. Before MCP, every agent framework had its own tool definition format. LangChain had its tools, OpenAI had function calling, Anthropic had their tool schema, and if you built a tool for one you had to rewrite it for another. Your Slack integration, your database connector, your file system reader — all of it was framework-specific.

MCP breaks that coupling. Build an MCP server once and any MCP-compatible client can use it. The ecosystem becomes composable because the interface is standardized. That's not exciting, but it's enormously productive.

How MCP Servers Work

An MCP server is a process that implements the MCP protocol over stdio or HTTP/SSE. It advertises three things: tools, resources, and prompts.

Tools are functions. The model calls a tool with arguments, the server executes something, and returns a result. This is the most-used primitive.

Resources are data sources the model can read — a file, a database record, a web page. Resources have URIs and mime types.

Prompts are reusable instruction templates the client can surface to users.

A minimal MCP tool definition in TypeScript using the official SDK:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

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

server.tool(
  "get_ticket",
  "Fetch a Linear ticket by ID",
  { ticket_id: z.string().describe("The ticket ID, e.g. ENG-123") },
  async ({ ticket_id }) => {
    const ticket = await linearClient.issue(ticket_id);
    return {
      content: [{ type: "text", text: JSON.stringify(ticket) }],
    };
  }
);

That's a complete tool. The server advertises it, the model sees it in its context, decides to call it, and gets back structured data. The client handles the protocol; you handle the logic.

What Building One Feels Like

Building an MCP server is closer to writing a REST endpoint than to prompt engineering. You're thinking about inputs, outputs, error handling, and what the model actually needs in the response to do its job. The schema is zod, the transport is mostly handled by the SDK, and the runtime is whatever you'd normally write server code in.

The interesting design question is what to expose as a tool vs. what to handle internally. A tool should do one thing and return data that's directly useful to the model. If your tool returns a 500-line JSON blob when the model needs one field, you've made the model do work that belongs in the server. Shape your output for the consumer.

The other design question is granularity. Too many fine-grained tools and the model spends its context budget deciding which one to call. Too few coarse tools and you lose composability. I've found that matching tool granularity to natural user-intent steps works well — one tool per meaningful action, not one tool per database operation.

Why It Matters for Product Development

If you're building products that integrate AI, MCP changes the integration calculus. Instead of writing custom glue code for every model you support, you write MCP servers. The servers become reusable assets. Your Stripe server works with Claude, works with your internal agents, works with whatever comes next.

More concretely: the emerging pattern for AI-integrated products is a core application with MCP servers exposing its data and actions, and one or more model-backed clients that consume those servers. The application doesn't couple to any specific model. The models don't need custom integrations. The protocol handles the seam.

That is very boring. It is also exactly correct. Good infrastructure disappears and lets you build the interesting parts.