Should Your Product Have an MCP Server? What the Spec Actually Requires

If your product has an API, someone is going to ask this year whether it has an MCP server. The Model Context Protocol is the standard that lets an AI application reach an external system without a bespoke integration per assistant, and the practical effect for a software business is that one server makes a product reachable from ChatGPT, Claude, Visual Studio Code and Cursor at once. Everything below is quoted from the protocol documentation as it stood on 25 September 2026, at protocol version 2026-07-28, and linked so you can check it.

What MCP is, in the specification’s own words

The introduction to MCP, read on 25 September 2026, describes it as "an open-source standard for connecting AI applications to external systems", and uses a hardware analogy that is worth keeping: "Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems."

The commercial argument follows directly from that. The documentation notes that MCP is supported across Claude, ChatGPT, Visual Studio Code, Cursor and others, "making it easy to build once and integrate everywhere". Before MCP, a vendor wanting to be usable from three assistants wrote three integrations and maintained three. That is the cost the standard removes, and it is the reason the question is being asked at board level rather than in a backlog.

“MCP focuses solely on the protocol for context exchange - it does not dictate how AI applications use LLMs or manage the provided context.”

That scope note matters when someone asks whether adopting MCP locks the company into a model vendor. It does not. MCP is a wire protocol for context and actions, not a model API.

The architecture: host, client, server, and one connection each

The architecture overview names three participants. The MCP host is the AI application that coordinates everything. The MCP client is "a component that maintains a connection to an MCP server". The MCP server is "a program that provides context to MCP clients". The host creates one client per server, and each client keeps a dedicated connection.

The protocol splits into two layers. The data layer is a JSON-RPC 2.0 exchange that carries discovery, capabilities and the primitives. The transport layer handles the channel and the authorization. Keeping those separate in your own head is useful, because almost every decision that costs money later is a transport or an authorization decision, and almost every decision that affects how useful the server feels is a data layer decision.

One more architectural fact is easy to miss and changes how you design state. MCP is described as a stateless protocol: "Every request contains all the information needed to process it, so servers infer nothing from previous requests". Anything spanning requests, such as a cart or a workflow, is an explicit handle you mint and receive back as an ordinary tool argument. That has a security consequence covered further down.

Three primitives, and the one that decides whether the server is useful

A server can expose three things. Tools are "executable functions that AI applications can invoke to perform actions". Resources are "data sources that provide contextual information". Prompts are "reusable templates that help structure interactions with language models". Clients discover each through a list method and, for tools, execute through tools/call.

The documentation gives a clean worked example: a server providing context about a database "can expose tools for querying the database, a resource that contains the schema of the database, and a prompt that includes few-shot examples for interacting with the tools". Most teams build the tools, skip the resource and skip the prompt, and then wonder why the assistant guesses at column names.

Tool design is where the quality of the server is decided, and the spec is unusually prescriptive about naming. Each tool carries a name that "should follow a clear naming pattern (e.g., calculator_arithmetic rather than just calculate)", a human-readable title, a description explaining what it does and when to use it, and an inputSchema in JSON Schema. The description is not documentation for humans. It is the text a language model reads when it decides whether to call your tool at all.

• Namespace the names. A client may federate dozens of servers. invoices_create survives that; create does not.
• Write the description for the caller, not the reader. Say when to use the tool and when not to. Ambiguity between two similar tools produces wrong calls.
• Constrain the input schema. Enums, required fields and defaults are cheaper than validating a hallucinated string on the server.
• Expose the schema as a resource. If the tools query your data, the shape of that data belongs in a resource so the model does not guess.
• Keep results small and structured. Tool responses come back as a content array that lands in the conversation, and a 4,000-row dump is a cost line as well as a usability problem.

Two things changed at protocol version 2026-07-28 that are worth knowing before you copy an older tutorial. Elicitation is the supported way for a server to ask the user for more information or confirm an action, using elicitation/create. Sampling and logging are deprecated as of that version; the documentation advises that new implementations "integrate directly with LLM provider APIs" and log to stderr or OpenTelemetry instead.

The security rules that say MUST

The MCP security best practices document is the part to read before you write the server, not after. Three of its rules are absolute, and each of them is a mistake a competent team makes by accident.

The first is token passthrough, which the document calls an anti-pattern: accepting a token from a client "without validating that the tokens were properly issued to the MCP server" and forwarding it downstream. The rule is stated without qualification.

“MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.”

The second is the confused deputy problem, which arises when a server proxies a third-party API using a static client ID while letting clients register dynamically. Because the third-party authorization server has already set a consent cookie, a later malicious request can skip the consent screen entirely. The mitigation is per-client consent held by your server: proxy servers "MUST implement per-client consent", maintain a registry of approved client IDs per user, and check it before forwarding to the third-party flow. Redirect URIs must be validated by exact string match, never by pattern or wildcard.

The third follows from statelessness. Because a state handle is passed as an ordinary argument, anyone who guesses one can present it. The document is direct: servers that implement authorization "MUST verify all inbound requests" and "MUST NOT treat possession of a state handle as authentication". The recommended pattern is to bind handles server-side to the authenticated user, keying stored state as user ID plus handle, where the user ID comes from the verified token rather than from the client.

There is more in that document worth an afternoon: SSRF protections for clients that fetch OAuth metadata URLs, a requirement that clients reject javascript:, data: and file: authorization URLs, and a scope minimization section arguing against publishing an omnibus scope. If you have read our notes on securing a Node application in production, this is the same discipline applied to a new surface, and the same review we would run as part of a SOC 2 readiness exercise.

When a product should build one, and when it should not

An MCP server is worth building when a customer would plausibly want to ask an assistant about your data or have it act in your product, and when the actions are well bounded. It is not worth building as a marketing exercise, and it is a poor substitute for an API that does not exist yet.

Scope the first release narrowly: three to six tools, all read-only or reversible, one resource describing the data shape, and real authorization from day one. Ship it, watch which tools actually get called and which get called wrongly, and let that decide the second release. It is the same sequencing we argue for in choosing an AI agent development company, and the reason is the same: the expensive part of an AI integration is never the first working demo.

If you already run a retrieval system, note that MCP does not replace it. A RAG knowledge base answers questions from documents you control; an MCP server exposes live operations and live data to somebody else’s assistant. Plenty of products need both, and they fail for different reasons.

What a first build actually involves

For a team that already has an API and an identity provider, the engineering is measured in days rather than months. The work that takes the time is the part nobody demos.

• Pick the transport and mean it. Streamable HTTP for a hosted product, stdio only if the server genuinely belongs on the user’s machine.
• Implement server/discover. The architecture overview calls it mandatory, and it is how clients learn your version and capabilities.
• Model authorization before tools. Every tool call runs as somebody. Decide who, from a verified token, and enforce it per call.
• Write the tool descriptions twice. Once as you think of them, once after watching a model choose wrongly between two of them.
• Test with the MCP Inspector from the reference tooling, then against at least two real clients, because host behaviour differs.
• Decide the deprecation story. Tool lists are cached with a TTL and change notifications are best effort, so removing a tool is a breaking change with a delay built in.

The operational shape is an ordinary authenticated HTTP service, which means the deployment questions are the familiar ones rather than new ones: process management, TLS termination, logging and rollback. Our notes on deploying a Node application with PM2, Nginx and SSL and on running Node in Docker in production apply unchanged.

If you want a second pair of eyes on the tool surface before you commit to it, or a server built and handed over with the authorization model documented, talk to us about the build.