What Is Model Context Protocol (MCP) and Why Your Product Needs an MCP Server

The Model Context Protocol (MCP) is an open standard, published by Anthropic in late 2024, that defines how AI agents and LLM-powered clients talk to external tools and data sources. In simple terms: it is the USB-C of AI integrations. Before MCP, every team connecting an AI agent to a product had to build a bespoke interface — custom tool definitions, authentication flows, custom schemas. MCP standardises the contract so a single server can serve Claude, ChatGPT, Cursor, Cline, and every other MCP-compatible client that ships after it.

This post covers what MCP actually is, how it works under the hood, what a production-safe MCP server requires, and how to decide whether building one is worth doing now.

How MCP Actually Works

An MCP server sits between an AI client — the LLM interface the user interacts with — and your product's existing API. It exposes a set of named tools: search_catalogue, create_order, get_account_status. Each tool has a structured description the model uses to decide when and how to call it. The client sends a request, the MCP server validates it, authenticates the caller, calls your API, and returns a structured result.

The transport layer is deliberately simple. MCP runs over stdio for local tools, or HTTP with server-sent events for remote, production deployments. You do not need to rebuild your existing API to support it. You write a thin MCP adapter layer over what you already have. The protocol handles the messaging format, capability negotiation, and error contract. Your server handles business logic and auth.

When an AI client wants to use your server, it fetches the tool list, reads the descriptions, and decides at inference time which tool to call for a given user request. The decision is made by the model, not hardcoded by you. This is what makes MCP-enabled products genuinely different from traditional integrations: the model drives the interaction, not a predetermined flow.

Why It Matters Now

Two things are happening simultaneously. AI clients are getting substantially better at multi-step tool use, and users are shifting from passive question-and-answer interactions to active delegation. "Book the cheapest flight under £300 leaving Tuesday" is no longer a search query — it is an agent task. The products that will capture that shift are the ones an agent can actually operate, not just describe.

MCP is not theoretical. As of mid-2025, Claude.ai, Cursor, Cline, Zed, and a growing list of developer tools are MCP clients by default. Shopify, Linear, GitHub, Stripe, and Cloudflare already have published MCP servers. The infrastructure is being built whether or not your product participates in it.

The distribution argument is also direct: if your product is available as an MCP server, it is available inside every AI development environment that supports the protocol. That is not a niche — it is the primary environment of a large and growing class of technical users who spend more time in Cursor or Claude than in a browser.

What a Production MCP Server Actually Requires

A working MCP server is not difficult to build. There are reference implementations in Python, TypeScript, and Go, and for simple tool surfaces you can have something running in a day. A production-safe MCP server is harder. It has four additional layers that most tutorials and quickstarts skip entirely.

OAuth-Scoped Authentication

Each client connection should be tied to a real user identity and the scopes they are permitted to invoke. An MCP server without user-level auth means every agent call runs with the same API key. That means one compromised integration touches every user's data. More practically, it means you cannot attribute actions to users, cannot revoke access selectively, and cannot answer the question "who did this and when?" when something goes wrong.

The correct pattern is OAuth 2.0 with per-user token scoping. The AI client handles the OAuth flow, the user approves the requested scopes, and the MCP server receives a token it can validate against your auth system. Actions taken by the agent are attributable to the user who authorised them, and revocation works at the individual user level.

Deliberate Tool Surface Design

The set of tools you expose, and how you describe them, directly controls how a model behaves with your product. Vague descriptions produce incorrect tool calls. Overly broad tools — a single execute_anything function, or a tool that accepts arbitrary SQL — give the model too much latitude and create both reliability and security risks.

Each tool should map to exactly one action, with a description precise enough that the model knows when not to call it, not just when to call it. The parameter schema should enforce types strictly. Tools that modify state should be separated from tools that read state, and the descriptions should make that distinction explicit so a model is not guessing whether a call is reversible.

Start with five to ten tools, get those right, and expand based on usage data. More tools increases the probability of the model calling the wrong one. A narrow, well-described surface outperforms a broad, ambiguous one.

Rate Limiting at the User Scope

AI agents are loops. A poorly designed agent prompt, a misbehaving client, or a user who triggers a broad autonomous task can issue hundreds of API calls in seconds. Without per-user rate limits at the MCP layer, a single agent session can exhaust your upstream API quota, trigger unexpected costs, or — if your API is downstream of a metered third-party service — generate charges that arrive before anyone has a chance to intervene.

Rate limiting at the API key level is not sufficient because multiple users share the same MCP server and the same upstream credentials. Limits need to be per-user, per-tool, and per-time-window, with circuit breakers that pause a session that is behaving abnormally rather than just throttling it uniformly.

Full Audit Logging

When an AI agent acts on a user's behalf, the user, and you, need to know what happened. A full audit trail of every tool call — who triggered it, what arguments were passed, what was returned, and when — is not optional for a production MCP server. It is what distinguishes a product users will trust from one they will avoid after the first unexpected action.

Practically, this means logging at the MCP layer, not just at the API layer, because the MCP layer carries the user identity and the agent context that the API layer may not see. Logs should be queryable by user and by time window so support and security investigations are tractable.

Common Mistakes in MCP Server Development

The most common mistake is building an MCP server too early in the stack — before auth is solid, before rate limiting exists, before the underlying API is stable. An MCP layer over a fragile API amplifies every API instability because agents retry automatically and can issue bursts of requests that a human user never would.

The second is exposing too many tools at launch. More tools increases the probability of a model calling the wrong one, and it increases the surface area you have to maintain and secure. Launch with the minimum set that provides clear value, measure what the model actually calls, and expand from there.

The third is treating tool descriptions as boilerplate. Tool descriptions are prompt engineering. They determine whether the model uses your tools correctly or not. A description that says "gets orders" is not sufficient. A description that says "retrieves a paginated list of the authenticated user's orders, sorted by date descending. Use this when the user asks about their purchase history or order status." is the kind that produces reliable behaviour.

The fourth is skipping the auth-and-audit layer on the reasoning that it can be added later. It is harder to retrofit than to build in. Adding it later means migrating user data to a new auth model, updating every tool call path, and running the old and new systems simultaneously during the migration. Build it in from the start.

When to Build One

If your product has an API and any of the following are true, MCP server development is worth prioritising now rather than waiting:

• You have users who are active in AI development tools — Cursor, Cline, Windsurf, Claude — and who would benefit from your product being available inside their existing workflow without a context switch.
• Your product holds data or can take actions that an agent would use on a user's behalf: booking, searching, creating, updating, retrieving. Products that only display information are less urgent candidates than products that do things.
• You are building in a space where competitors will have MCP servers within twelve months. In software tools, developer tooling, and productivity products, that window is closer to six.
• You are building a new product and your target users are developers or AI-forward teams. For that audience, MCP support is increasingly a purchasing criterion.

If none of those apply, the protocol is not going away but the urgency is proportional to how much of your product's value is in doing things rather than displaying information. Watch the client ecosystem and move when the fit is clear.

The Result

A production MCP server, built with the auth-and-audit layer in place from the start, turns your product into something an AI agent can operate safely on a user's behalf. Not describe, not approximate, but actually operate: taking actions, reading state, and returning results that the model can reason about and chain into longer workflows.

That is the delta between being MCP-enabled and being genuinely agent-ready. The protocol is the interface. The auth, the rate limiting, the audit trail, and the tool surface design are what make it production-grade.