You already have an API. Do you need an MCP server?

Sometime this year, someone on your leadership team asked whether you need an MCP server. It's a fair question. An MCP server is how an AI assistant like Claude or ChatGPT finds your product's actions and calls them for a user. By December 2025, Anthropic counted more than 10,000 active public MCP servers, and it had handed the Model Context Protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation that it co-founded with Block and OpenAI.

If you build one, treat it as what it is: a second front door into your product, used by a client that reads your descriptions and decides on its own what to call.

What is an MCP server, and how is it different from your API?

Your API was designed for developers. A person reads the docs, writes code against your endpoints, and ships it. The code calls exactly what the developer told it to call.

An MCP server is designed for models. It publishes a list of tools, each with a name, a description, and an input schema, and an AI model decides at runtime which tool to call and with what arguments. The backend can be identical. The consumer is completely different: something that reasons from your descriptions instead of your docs, and acts on behalf of a user who isn't watching each call.

Most APIs weren't built with that consumer in mind. Postman's 2025 State of the API report, a survey of more than 5,700 developers, found that only 24% actively design APIs with AI agents in mind.

Does your company actually need an MCP server?

It depends on who the agent is.

Your own agents. If the only AI calling your systems is an assistant your team built, you may not need MCP at all. Direct tool calling inside your own AI agent works fine. MCP starts paying off when several agents or several AI clients need the same tools.
Your customers' agents. If your buyers already work inside Claude, ChatGPT, or Copilot and want to act in your product from there, an MCP server is a product surface, in the same category as your public API or your Zapier integration. This is the strongest case.
Nobody yet. Then don't build it. Keep your API clean and documented, because that's what a good MCP server sits on later.

Should you turn every API endpoint into an MCP tool?

The tempting move is to generate one tool per endpoint and call it done. Plenty of builders start there: in a survey of MCP builders published by the API platform Zuplo in January 2026, 58% said they were wrapping existing APIs. Anthropic's own engineering guidance names this directly: "A common error we've observed is tools that merely wrap existing software functionality or API endpoints."

Endpoint-shaped tools make the model do your integration work. To answer "which enterprise invoices are overdue?" it has to list customers, filter, page through invoices, and join the results, several calls where one should do. Task-shaped tools match how people describe the work: find_overdue_invoices, summarize_account, draft_refund. Every tool definition also takes up the model's context, so a server with 80 thin tools is slower and more expensive than one with 8 good ones.

How do you secure an MCP server?

The same Zuplo survey found that security and access control was the top challenge, named by 50% of builders, and about a quarter said their servers had no authentication at all. Fine for a tool on one laptop, not for anything on the network.

Three rules close most of that gap:

The agent acts as the user, never as a shared service account. OAuth tokens tied to the person, so the agent can only do what they're allowed to do. Your server accepts only tokens issued for it and never forwards them to the APIs behind it.
Least privilege per tool. A tool that reads invoices shouldn't hold a token that can delete them.
Writes wait for a human. Anything that sends, deletes, or spends stops at an approval step your server enforces, not one you hope the AI client shows. It's the same approval gates that make agentic features trustworthy in your own product.

What changed in the July 2026 MCP spec?

If you're starting now, design for the specification revision dated 2026-07-28, and check which revisions your target AI clients speak. Three changes matter for B2B teams:

MCP is now stateless. The revision removes protocol-level sessions and the initialize handshake, and every request carries its own protocol version and capabilities, so a server can run behind a load balancer or on a serverless platform without sticky sessions.
Client registration changed. OAuth Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. Confirm your identity provider supports them.
Tracing is documented. The spec now documents how OpenTelemetry trace context travels with each request, so you can follow an agent's call from the AI client into your own backend.

Treat agent traffic as a new client class

Agents don't behave like browsers or like integration partners. They retry, they fan out, and they run at 3 a.m. on behalf of someone who's asleep. Give them their own rate limits per client and per user, an audit log of every tool call with the user it acted for, and alerts when one user's token calls a write tool more often than any person would. It's the same discipline you apply to a public API, pointed at a client that doesn't get tired.

A first build that's worth shipping

Start small enough to learn from: one read-only server, three task-shaped tools, and one AI client you control, such as your support team's assistant. Instrument which tools get called, which calls fail, and what people ask for that no tool covers. That last list is your roadmap. Add write tools only after the read path has earned trust, and only behind approval.

An MCP server touches three practices at once: AI for the tool design, Secure for the auth and audit trail, and Build for the API underneath. That's why we scope it as one piece of work, not three hand-offs. And if your agents will read customer data, settle who can see what before the first tool ships.