MCP: stop building the same AI integration five times.

Your support team wanted an AI assistant that could check order status. So an engineer wired GPT-4 to the orders database, wrote a function-calling schema for it, and shipped it. A few months later, someone wanted the same lookup inside Claude, for an internal ops tool. Same database, same query — but Anthropic's tool-calling format doesn't look like OpenAI's, so it got rebuilt from scratch. Then a developer wanted it inside Cursor while writing customer-facing code. Rebuilt again. One database, one query, three codebases doing the same job — and three things to fix the day the orders API changes its response shape.

Why every AI tool needed its own glue code

Every model vendor invented its own way to describe a tool to a model: OpenAI has one function-calling format, Anthropic's tool_use looks different, Google's function declarations are different again. So "connect the AI to the orders database" really meant: write a client for the database, then wrap it in whichever format that assistant expected, then repeat for the next assistant. Multiply that by every internal system you want an agent to reach, and every AI tool your teams pick up, and the integration work grows by systems times tools, not systems plus tools.

What MCP actually standardises

Model Context Protocol (MCP) is an open standard, published by Anthropic in November 2024, for how an AI application talks to a tool or a data source. A small server describes the tools it offers — their names, their inputs, what they return — over a plain JSON-RPC connection (a lightweight, vendor-neutral request-response format). Any MCP-aware client can read that description and call the tools, without you writing vendor-specific glue for each one. Think of it as a USB-C port for AI tools: one physical connector, and any device that speaks the same protocol plugs in.

It's no longer a single-vendor bet either. In December 2025, Anthropic handed governance of the standard to the Agentic AI Foundation, a vendor-neutral body under the Linux Foundation, with OpenAI and Block joining as co-founding members alongside AWS, Google, Microsoft, Cloudflare, GitHub and Bloomberg as supporting members. Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot and VS Code all now speak MCP as clients, alongside dozens of smaller tools.

Build the tool once

Here's that order-status lookup as an MCP server, in TypeScript. It exposes one tool, describes what it needs and what it returns, and doesn't know or care which AI will eventually call it.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import { ordersApi } from "./orders-client.js";

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

server.registerTool(
  "get_order_status",
  {
    description: "Look up the current status of a customer order by ID",
    inputSchema: { orderId: z.string() },
  },
  async ({ orderId }) => {
    const order = await ordersApi.get(orderId);
    return {
      content: [
        {
          type: "text",
          text: `Order ${orderId} is ${order.status}, last updated ${order.updatedAt}.`,
        },
      ],
    };
  },
);

await server.connect(new StdioServerTransport());

Connect it to whatever your team already uses

Wiring a new client to that server is configuration, not code. Claude Desktop, Cursor and VS Code each keep their own settings file, but the shape is the same everywhere: a name for the server, and the command that starts it.

{
  "mcpServers": {
    "orders": {
      "command": "node",
      "args": ["./mcp-servers/orders/dist/index.js"]
    }
  }
}

That's the entire integration for the second assistant, and the third. The logic that actually knows your database schema and your auth was written exactly once, in the file above.

What it replaces, and what it doesn't

MCP replaces the vendor-specific wrapper — the OpenAI-shaped function definition, the Anthropic-shaped tool_use block, rewritten every time you add a system or swap a model. It does not replace deciding what an agent is allowed to do. The protocol will happily transport a call to delete_order if you expose one; it has no opinion on whether that call should need a human's approval first. Scoping which tools an agent can reach, and gating anything irreversible, is still your design work — the same as it is for any agent you put in production.

When it's the wrong tool

Skip it for a single prototype talking to a single system — writing the vendor's function-calling schema directly is less code than standing up a server, and you don't yet know if the assistant is sticking around. Skip it too when the "tool" is really just static reference data small enough to paste into the prompt; a lookup table doesn't need a protocol. MCP earns its cost the moment a second assistant, agent, or internal tool needs to call the same system — which, for a team that has already adopted more than one AI tool this year, is closer to day one than it sounds.

The question isn't whether you'll add a second AI tool. It's whether the third one costs you a sprint or an afternoon.

The next AI tool your team picks up won't be the last — a better model, a new coding agent, a vendor's chat assistant bundled into some other SaaS you already pay for. Building each internal connection once, behind a protocol instead of inside whichever SDK is fashionable this quarter, is the difference between that adoption costing an afternoon and costing the CRM integration all over again. If you're looking at three systems and four AI tools and wondering where to start, that's exactly the kind of wiring we map out in an AI Opportunity Assessment.