Model Context Protocol is an open spec from Anthropic, first released November 2024. It defines a JSON-RPC contract for how an AI client talks to a tool server. Three concepts: Tools — functions the model can call (getcustomer, createticket) Resources — read-only data the model can fetch (file://, db://) Prompts — reusable prompt templates the host can offer to users Servers expose these.

Writing the server is easy. The 30-line example above is real. Production is where the work lives: Hosting. Streamable HTTP works on stateless serverless functions, but if you want server-initiated messages (sampling, elicitation, progress) you need a long-lived connection — and that means session affinity. Auth. The spec mandates OAuth 2.1 with PKCE for remote servers.

The MCP spec — the canonical reference, dense but worth a read MCP server SDK (TypeScript) — what the example above uses Protobox pricing — free tier covers the first server Protobox docs — five-minute quickstart If you have an internal API that an AI client should be able to call, MCP is now the answer. The fragmentation tax is paid; the protocol won.

What is MCP, and why it matters now

Q: What is The ergonomic shift?

The mental model change is small but consequential: tools are now infrastructure, not features. A tool used to belong to a single client integration. "Our Claude bot can look up orders." Now a tool belongs to the company. "Our order lookup is exposed as MCP.

If you have shipped an AI feature in the last two years, you have probably written the same integration three times.

Once for Claude. Once for ChatGPT function calling. Once for whatever Cursor or Continue or your IDE of the week wants. Every client has its own tool format, its own auth dance, its own rate-limit semantics, its own retry behavior. The tool itself — the actual call to your CRM, your billing system, your search index — is twenty lines of code wrapped in two hundred lines of glue.

This is the problem MCP fixes.

The fragmentation tax

Before MCP, the integration matrix looked like this:

                Claude   ChatGPT   Cursor   Continue   Custom
your CRM         ✓         ✓         ✓        ✓          ✓
your KB          ✓         ✓         ✓        ✓          ✓
your billing     ✓         ✓         ✓        ✓          ✓
your search      ✓         ✓         ✓        ✓          ✓

Five clients × four tools = twenty integrations. Each cell is a different SDK, schema, and auth pattern. When the OpenAI tool-calling spec changed, every cell in the ChatGPT column broke. When Anthropic shipped streaming tool use, the Claude column needed work. The matrix is the bug.

The deeper problem: the people building tools (your backend team) and the people choosing models (your AI team) end up locked into a vendor before the integration is even written. Switching costs are real and they live in tool code, not model code.

What MCP is

Model Context Protocol is an open spec from Anthropic, first released November 2024. It defines a JSON-RPC contract for how an AI client talks to a tool server. Three concepts:

Tools — functions the model can call (get_customer, create_ticket)
Resources — read-only data the model can fetch (file://, db://)
Prompts — reusable prompt templates the host can offer to users

Servers expose these. Clients consume them. Transport is Streamable HTTP for remote servers (introduced in the 2025-03-26 revision) or stdio for local processes. The current spec revision is 2025-11-25.

The reason this matters now and not in November 2024: adoption. The spec is open, so the early-adopter list grew fast. Anthropic's clients support it natively, including Custom Connectors for remote servers in Claude. OpenAI's Agents SDK adopted MCP in 2025. Cursor, Continue, Sourcegraph, Zed, Windsurf, and most serious agent frameworks now read MCP servers as a first-class input.

You write the tool once. Every client that speaks MCP can use it.

A real MCP server in TypeScript

Here is a complete MCP server using the official TypeScript SDK. One tool, copy-paste runnable.

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: "crm-tools",
  version: "1.0.0",
});
 
// Register a tool: name, schema, handler.
server.registerTool(
  "get_customer",
  {
    description: "Look up a customer by email",
    inputSchema: {
      email: z.string().email().describe("Customer email"),
    },
  },
  async ({ email }) => {
    const customer = await fetch(
      `https://api.crm.internal/v1/customers?email=${email}`,
    ).then((r) => r.json());
    return { content: [{ type: "text", text: JSON.stringify(customer) }] };
  },
);
 
// Run over stdio (for local Claude Desktop) — or swap to a HTTP transport for remote.
await server.connect(new StdioServerTransport());

Point Claude Desktop at this binary and get_customer shows up in any conversation. Point Cursor at it and the same tool appears in agent mode. The server has no idea who is calling. That is the point.

The ergonomic shift

The mental model change is small but consequential: tools are now infrastructure, not features.

A tool used to belong to a single client integration. "Our Claude bot can look up orders." Now a tool belongs to the company. "Our order lookup is exposed as MCP. Anything that speaks MCP — including the agent we have not built yet, the client our customers use, and the ChatGPT GPT a partner publishes — can call it under the same auth and rate limits."

That changes how you think about API surface area. Instead of duplicating endpoints across REST, GraphQL, and per-client tool schemas, you ship one MCP server and let clients discover it. The schema is published. The auth is OAuth 2.1 with PKCE per the spec. The rate-limit story is yours to tell once.

It also changes who owns the integration. In the per-client world, the AI team owns Claude integration code, the support team owns ChatGPT custom GPTs, and the IDE plug-in is somebody's side project. Three teams shipping three versions of the same tool, drifting independently. With MCP, the team that owns the underlying API also owns the MCP server. There is one tool, one schema, one set of tests. Clients are downstream consumers — the same way they consume a REST endpoint today.

For internal tools, the win shows up immediately. Onboarding a new AI client (Cursor for engineering, Claude for support, a custom agent for sales) becomes a config change, not a project. The MCP URL goes in, the tools appear, the team is productive that afternoon.

Where it gets hard

Writing the server is easy. The 30-line example above is real. Production is where the work lives:

Hosting. Streamable HTTP works on stateless serverless functions, but if you want server-initiated messages (sampling, elicitation, progress) you need a long-lived connection — and that means session affinity.
Auth. The spec mandates OAuth 2.1 with PKCE for remote servers. That's great until you actually have to implement the token exchange, refresh, and revocation. Most teams want their existing identity provider to do this.
Rate limiting. Per-tenant, per-tool, per-client.
Observability. When a tool call fails, you need to know which client, which user, which arguments, and which downstream API. Tracing across MCP boundaries is not in the spec — you wire it in.
Versioning. Adding a tool is easy. Renaming an argument breaks every conversation that has that tool in context.

This is the boring middle layer between "I wrote a tool" and "I can sleep at night while it runs."

The same shape as the API gateway problem from a decade ago. Writing an HTTP endpoint is trivial; running a fleet of them at scale, behind auth, with rate limits and observability, is what Kong and Apigee and AWS API Gateway were built for. MCP is sitting at the same point in its lifecycle now. The protocol is settled. The runtime is up for grabs.

What Protobox does

Protobox is a managed runtime for MCP servers. You define tools; we host the server, handle OAuth, enforce per-tenant rate limits, and stream tool-call traces into an observability dashboard. You get a https://your-server.protobox.app/mcp URL to drop into any MCP client.

That is the whole pitch. The 30-line server above runs on Protobox unchanged — we add the production layer underneath.

If you are evaluating whether to roll your own MCP infra or use a platform, the calculus is the same as Postgres-versus-Neon or Redis-versus-Upstash: at small scale, self-hosting is fine; at the point where auth and rate limits become a feature your customers ask for, the platform pays for itself.

Try it

The MCP spec — the canonical reference, dense but worth a read
MCP server SDK (TypeScript) — what the example above uses
Protobox pricing — free tier covers the first server
Protobox docs — five-minute quickstart

If you have an internal API that an AI client should be able to call, MCP is now the answer. The fragmentation tax is paid; the protocol won. The only question is whether you want to run the plumbing yourself.

Want to ship your first MCP server in five minutes? Read the quickstart guide — we walk through it end to end with a real example.

Key Takeaway

Testing edge cases before production deployment can reduce customer complaints by 80% and prevent costly emergency fixes post-launch.

mcp ai-infrastructure developer-tools integrations

Dean Grover

Founder, Protobox

Building TBD bio at Protobox — tools, testing, and observability for customer experience.