MCP vs API: What We Learned Running an MCP Server in Production

MCP vs API: What We Learned Running an MCP Server in Production

, Head of AI & Frontend | | 8 min read

The brief

How MCP differs from a classic API, when to use each, the attacks an MCP server faces and the server-side gates we run in production.

An API gives a programmer a fixed contract of endpoints, while MCP lets an AI agent ask a server which tools it offers and choose among them by their descriptions. Anthropic introduced the Model Context Protocol (MCP) on 25 November 2024 as "an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools".

Since 9 July 2026 we have run a production MCP server for our own CMS, built on Wagtail. AI agents can call 164 tools on it, and no agent can publish a page whose brief a person has not approved.

How MCP works: host, client and server

Claude Code terminal windows, an example of an MCP host and client on a developer machine

MCP uses a client-host-server architecture. The host is the AI application the user works in. It creates and coordinates several clients and enforces security policies and user consent. Each client connects to exactly one server, and each server exposes capabilities to the model.

MCP architecture diagram: a host with MCP clients connected over JSON-RPC to MCP servers that expose tools, resources and prompts

The protocol runs on JSON-RPC. A server can be a local process on the developer's machine or a remote service reached over the network. The specification dated 2026-07-28 describes MCP as stateless: every request carries its own protocol version and capabilities, with no session at the protocol level.

Tools, resources and prompts

A server offers three kinds of building blocks:

  • Tools are functions the model can call, such as "create a page" or "list case studies".
  • Resources are passive data the model can read, for example a log file or a database schema.
  • Prompts are ready-made templates for a type of interaction.

Capability negotiation and isolation

Client and server declare which features they support. In the 2026-07-28 specification the client attaches its capabilities to every request and the server announces its own in response to server/discover. Our public endpoint declares the earlier versions 2025-06-18, 2025-03-26 and 2024-11-05, so it does not use server/discover or stateless requests.

By design, a server should not see the whole conversation or look into other servers. The full history stays with the host, and a server only learns what the host passes to it.

Who maintains MCP

Since December 2025 MCP has belonged to the Agentic AI Foundation, hosted by the Linux Foundation, after Anthropic donated it; governance of the project did not change. Anthropic, Block and OpenAI co-founded the foundation, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg, among others. The first adopters named in the November 2024 announcement were Block and Apollo, plus the developer tools Zed, Replit, Codeium and Sourcegraph. Anthropic's December 2025 announcement counted more than 10,000 active public MCP servers.

MCP vs API: the difference

A traditional API exposes fixed endpoints and assumes that the programmer knows in advance which operations to call. An MCP server publishes a list of tools, each with a name, a description and a typed input schema; the client asks what is available and passes those descriptions to the model, which picks the tool it needs. Comparisons such as Codecademy's "Model Context Protocol (MCP) vs. APIs: Architecture & Use Cases" and TrueFoundry's "MCP vs API" describe the difference the same way.

How a traditional API and an MCP server differ for the client that uses them.
CriterionTraditional APIMCP server
Who discovers what is availableThe programmer, from the documentationThe AI client, by asking the server for its tools
ContractFixed endpointsA list of tools, resources and prompts
Description of operationsWritten for people in the docsName, description and typed input schema read by the model
Main userApplication code written by a developerAn AI agent working inside a host application
Authentication and consentHandled by the integrating applicationThe host enforces user consent and policies; the server can offer a public scope and a token-only scope
When the contract changesThe client code has to changeThe client reads the updated tool list
Typical useSystem-to-system integrationAI assistants and agents working with your system

MCP does not replace APIs. In many production systems the MCP server calls an existing API underneath, so the API marks the boundary of the service and MCP marks the boundary of the agent.

When to use MCP and when an API is enough

Use a plain API when a programmer writes the integration and knows the operations up front. That covers most system-to-system work with a stable contract.

MCP makes sense when an AI agent or assistant (ChatGPT, Claude, Cursor) will use your system and has to choose tools from their descriptions. It also helps when one server should serve many AI clients at once, because each client reads the same tool list instead of getting its own integration.

MCP is not tied to Claude. According to Anthropic's December 2025 announcement, ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code support it too.

MCP server security: what can go wrong

The main risks for an MCP server are confused deputy, token passthrough, server-side request forgery, state handle hijacking, compromise of a local server and unvalidated OAuth authorization URLs. Part of MCP security sits in the protocol itself. The host enforces user consent and policies, and a server sees neither the full conversation nor other servers. The rest depends on how you build and deploy the server.

The official MCP guide "Security Best Practices" (version 2026-07-28) describes the main attacks:

  • Confused deputy. A server with its own privileges acts on behalf of a client that should not have them, for example through a shared OAuth client.
  • Token passthrough. The server accepts a token that was not issued for it and forwards it to downstream services, which breaks audit and access control.
  • Server-side request forgery (SSRF). The server is tricked into requesting internal addresses it can reach and the attacker cannot.
  • State handle hijacking. An attacker reuses or guesses a handle that ties requests to an earlier interaction.
  • Local MCP server compromise. A server running on the user's machine is started or controlled by an untrusted party.
  • Unvalidated OAuth authorization URLs. A malicious server sends the client to an authorization address it should not trust.

The guide also covers stdio transport in setups with a proxy, several OAuth topics (mix-up attacks, localhost redirect impersonation, trust policies for Client ID Metadata Documents) and scope minimization. Scope minimization means asking for the minimal read scope first and raising permissions only when an operation needs them. The guide gives mitigations for each.

What we learned running an MCP server in production

Developer working at a monitor with code in a dark office

On our production MCP server, three server-side gates decide what an AI agent can create, write and publish. The server connects AI agents to the CMS that runs this website. Its 164 tools (as of 20 October 2026) cover pages, content, SEO and GEO (generative engine optimization, that is, visibility in AI answers), schema.org, media, menus, redirects, Search Console and GA4 analytics, and leads. Access tokens and the call log are managed in the Wagtail admin panel. We have no business metrics from this deployment.

Checklist for CTOs: hard gates on an MCP server exposed to AI agents

  1. No page without a strategy brief. Calling create_page without a strategy, which ties the page to a goal in our content plan and to its role in the sales funnel, returns HTTP 400.
  2. No content before human approval. Writing content while the brief has not been approved by a person returns HTTP 409.
  3. No publication while the audit has errors. Publishing returns HTTP 409 when the audit finds facts outside the approved checklist, client names covered by an NDA or no verdict from an independent critic agent.

No tool on the server has a parameter that skips these gates. The gates have two exceptions: a correction mode for pages that are already live, which publishes a draft only when its audit finds nothing worse than the live version, and manual publication by a person in the Wagtail admin panel.

MCP security best practices from our production server

Put the rules the agent must not break in the server. An instruction in the prompt asks the model to follow a rule; a response code or a validation step on the server enforces it. We keep the rules in HTTP codes and validation, and the prompt only explains them.

Give every agent its own token and log every call. Each agent gets its own token, so every entry in the call log points to one agent and answers the question "which agent did what".

Split the public scope from the authenticated one. Since 8 October 2026 we have also run a public MCP endpoint for AI assistants at https://ordergroup.co/mcp. It needs no token and offers only reading and contact, through two tools: list_case_studies and submit_project_enquiry. It is listed in the official MCP registry as co.ordergroup/public (status active, version 1.0.0, published 8 October 2026). Writing to the CMS is possible only with a token, so an agent without authorization can read and send an enquiry and nothing more.

MCP vs API: frequently asked questions

What is the difference between MCP and an API?

An API exposes fixed endpoints for a programmer who knows the operations in advance. An MCP server publishes a list of tools, each with a name, a description and an input schema, and an AI client asks what is available and lets the model choose. In production the two usually work together.

Does MCP replace APIs?

No. MCP adds a layer for AI agents on top of the systems you already have. In many production setups the MCP server calls an existing API underneath, so the API stays the boundary of the service and MCP becomes the boundary of the agent.

When should you use MCP instead of an API?

Use MCP when an AI agent or assistant such as ChatGPT, Claude or Cursor will work with your system and has to pick tools from their descriptions, or when one server should serve many AI clients. When a programmer writes a system-to-system integration with a stable contract, an API is enough.

Is MCP secure?

The protocol builds in some protection: the host enforces user consent and policies, and a server does not see the full conversation or other servers. The rest depends on the server. The official guide lists attacks such as confused deputy, token passthrough and server-side request forgery, each with mitigations.

What are MCP security best practices?

Keep the rules an agent must not break on the server as response codes and validation. Give every agent its own token and log every call. Separate a public read-only scope from the authenticated one, and ask for the smallest scope first, raising permissions only when an operation needs them.

Is MCP only for Claude?

No. Anthropic created MCP, but in December 2025 it handed the protocol to the Agentic AI Foundation, hosted by the Linux Foundation. According to the same announcement, ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code also support MCP.

Next steps

If you are deciding whether your product needs an MCP server, an API or both, see our MCP server development services, our AI software development services or book a free consultation.

Deciding between an MCP server and an API?

Book a free consultation

Accessibility settings

Text size

100%