"Do we need an MCP server?" has become a standard question in roadmap meetings, usually followed by "isn't that just our API?" Both questions are fair. Below we cover what MCP actually is and what changed in the July 2026 version of the spec. It ends with a simple rule for when an MCP server is worth building.
MCP vs API in one paragraph
Your API is the contract between your system and the software you know about, such as your frontend, mobile apps and partners. The Model Context Protocol (MCP) is a contract between your system and AI clients you do not control. Those are Claude, ChatGPT, coding assistants and the agents your customers build. An MCP server tells those clients which tools exist and what arguments they take, then returns results in a form models handle well. Under the hood, most MCP servers call an existing API.
What an MCP server exposes
An MCP server offers three kinds of things. Tools are actions the model can call, like create_invoice, search_orders or refund_payment, and each one has a JSON schema for its inputs. Resources are data the client can read and give the model as context, such as a document, a record or a file. Prompts are reusable prompt templates the user can pick in the client.
Clients connect over one of two standard transports.
| Transport | How it works | Use it for |
|---|---|---|
| stdio | The client launches the server as a local subprocess and exchanges JSON-RPC messages over stdin/stdout | Local tools: CLIs, file access, developer utilities |
| Streamable HTTP | Each message is an HTTP POST to one endpoint; responses come back as JSON or a short stream | Remote, multi-user servers, like a SaaS product's MCP endpoint |
The older HTTP+SSE transport is deprecated.
What changed in the 2026-07-28 spec
Most articles about MCP describe the protocol as it was before this summer. The current version, 2026-07-28, changed the architecture in ways that matter if you are building a server.
The big one is that MCP is now stateless. The initialize handshake is gone, and so are protocol-level sessions (the Mcp-Session-Id header). Every request carries its protocol version and client capabilities instead. So a remote MCP server can now sit behind an ordinary load balancer with no sticky sessions.
Discovery is explicit. Clients call a server/discover method to learn what a server supports. Tool and resource lists are cacheable too, because list results carry cache hints, and clients no longer have to re-fetch them constantly. Server-initiated requests were replaced by a multi-round-trip pattern, which fits the stateless model.
Several features were deprecated. Sampling and Roots are among them, and so is Logging. A new policy keeps deprecated features supported for at least 12 months.
Authorization was tightened. OAuth issuer validation is stricter now, and Client ID Metadata Documents replace dynamic client registration as the recommended approach.
Client support is still rolling out. The new version is designed to interoperate with servers built for the previous one (2025-11-25). If you are starting fresh, build against 2026-07-28 with an official SDK.
When you need an MCP server (and when you don't)
The rule is simple. Build an MCP server when an AI client needs to act on your system and your API alone can't get it there.
You probably want one if:
- Customers are asking to use your product from Claude, ChatGPT or their IDE.
- You are building internal agents that need to work across several of your systems.
- You want one integration that works with every MCP client instead of a custom plugin for each.
- Your team has custom GPTs with actions. OpenAI retires custom GPTs on December 11, 2026 and the actions don't carry over, so they need rebuilding. See what to do before custom GPTs go away.
You probably don't need one if your only AI feature lives inside your own app. In that case, call your own functions directly. The same goes for integrating two systems with no AI in the loop. That is a normal API integration, and MCP adds nothing.
How to design a good MCP server
The most common mistake is auto-generating one tool per API endpoint. It feels complete. It makes the server worse.
Design tools around tasks. A single find_customer_and_open_orders tool beats making the model chain list_customers, get_customer, list_orders and filter_orders on its own. Aim for 5 to 15 well-named tools.
Part of the reason is token cost. Every tool's name and description is sent to the model as context, along with its schema. Dozens of verbose tools cost tokens on every request and make tool selection less accurate. Anthropic reported one agent workflow dropping from about 150,000 to 2,000 tokens by loading tool definitions on demand. See our guide to reducing LLM API costs for more on that.
Write the descriptions for the model. Say when to use the tool and when not to, what the arguments mean, and what errors look like. Keep results compact and structured, too. Large raw JSON payloads burn context, so return what the model needs for the next step.
And make write tools safe to retry, because models and clients will retry. If a tool creates records, charges money or sends messages, idempotency keys are not optional.
Security: treat the model as an untrusted caller
An MCP server gives an AI model the ability to take actions. Design as if the model can be tricked, because it can. Content it reads, such as emails, web pages or documents, can contain instructions meant to hijack it.
Authenticate every request with OAuth, following the spec's authorization rules, and scope tokens to the user's own permissions. Keep read tools and write tools separate, and require confirmation in the client for destructive or financial actions.
Rate limit every tool call. Log each one with the user, the arguments and the result, so you can audit what an agent did. Validate arguments on the server as well, since you should never trust the model to respect a schema.
MCP is not free to operate
Some platforms bill MCP tool calls explicitly. Zapier, for example, counts two tasks per successful MCP tool call (see how that compares in our n8n vs Zapier vs Make breakdown). Every call also costs model tokens on the client side. Budget for both, and prefer fewer, more capable tools.
Our take
For most companies, MCP will be a thin layer over the API they already have, and the API stays where it is. If customers or internal teams want to use your product from AI clients, a well-designed MCP server with a handful of task-level tools is a small project with outsized reach. Start read-only. Then add write tools with idempotency and confirmations, and build on the stateless 2026-07-28 spec from day one.