What the Model Context Protocol means for product teams in 2026

Most of the AI work I do is connecting a model to systems that already exist. I built an LLM-powered SEO platform that publishes into WordPress, Shopify and custom CMSs, and chat and voice agents that call tools against live business data. Integrations like these are usually written for one application: tool definitions in one model provider's format, authentication handled in-house, and nothing another AI client can reuse.

The Model Context Protocol (MCP) exists to fix that. Here is where it stands in late 2026, from a product team's point of view.

What MCP is

MCP is an open protocol for connecting AI applications to external tools and data. Anthropic introduced it in late 2024, and in December 2025 it was donated to the Agentic AI Foundation, a fund under the Linux Foundation whose platinum members include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI (Linux Foundation announcement). The current specification is the 2026-07-28 revision.

Messages are JSON-RPC 2.0, and the idea mirrors the Language Server Protocol: build a server once, and every MCP-capable client can use it.

Hosts, clients and servers

Host: the AI application the user works in, such as a chat assistant, an IDE or your own product.
Client: a connector the host creates for each server. Each client talks to exactly one server.
Server: a program that exposes capabilities, such as a wrapper around your CRM or ticketing system.

The host owns the conversation with the model, handles user consent, and controls what reaches each server. By design, servers don't see the whole conversation or into other servers.

Tools, resources and prompts

Servers offer three kinds of capability, which differ in who decides when they are used:

Primitive	Controlled by	What it is	Example
Tools	The model	Functions the model calls to act or fetch information	Look up an order
Resources	The application	Data the host attaches as context	A file or record
Prompts	The user	Templates the user picks explicitly	A slash command

A tool is a name, a description and a JSON Schema for its input, which is what a model needs to decide when and how to call it:

{
  "name": "get_order_status",
  "description": "Look up the status of a customer order.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_number": { "type": "string" }
    },
    "required": ["order_number"]
  }
}

Clients can offer features back to servers, mainly elicitation: a server asking the user for missing information partway through a request. The 2026-07-28 changelog deprecates the older roots, sampling and logging features. Optional extensions add long-running tasks and MCP Apps, which render interactive UI inside a conversation.

Transports

MCP defines two standard transports:

stdio: the client launches the server as a local subprocess and they exchange JSON-RPC over standard input and output.
Streamable HTTP: each message is an HTTP POST to a single endpoint, answered with JSON or a server-sent event stream for that request. This is the transport for remote servers your product hosts.

The older HTTP+SSE transport is deprecated.

The biggest change in the 2026-07-28 revision is that MCP is now stateless. The initialize handshake and the Mcp-Session-Id header are gone; every request carries its own protocol version and capabilities, and servers describe themselves through a new server/discover method. A server that needs state across calls returns an explicit handle, such as a cart ID, and receives it back as an ordinary tool argument. A remote MCP server now scales like a normal HTTP API: with that state in shared storage, any instance behind a load balancer can answer any request.

How MCP fits with function calling and agents

Function calling and MCP are not alternatives. Function calling is a model capability: you give the model tool schemas, and it can emit a structured call for your code to run. MCP standardizes where those tool definitions come from and how a call reaches the system that executes it. A typical turn:

The host's clients ask each server for its tools (tools/list).
The host passes them to the model through the provider's function-calling interface.
The model picks a tool and produces arguments.
The client sends tools/call to the right server, ideally after showing the user what will run.
The result goes back into the model's context, and the loop continues.

An agent is that loop running over many steps toward a goal. MCP doesn't make something an agent; it is the plumbing that lets an agent reach your systems without custom glue for every host.

Who supports it

When MCP moved to the Linux Foundation, the announcement listed Claude, Cursor, Microsoft Copilot, Gemini, VS Code and ChatGPT among the AI products that had adopted it, alongside more than 10,000 published MCP servers. For a product team, that means one server reaches the assistants and coding tools customers already use.

Support isn't uniform: clients differ in which transports, primitives and extensions they implement, so check each one's documentation before promising anything.

Security

The spec treats tools as arbitrary code execution and says hosts must get explicit user consent before invoking them.

Tool permissions. Give each server the least access that does the job. Separate read tools from write tools, so an assistant can search orders without being able to refund them, and keep destructive operations behind a confirmation that shows the actual arguments. The security best practices recommend starting with minimal OAuth scopes and requesting more only when a privileged operation is first attempted. Clients should treat tool descriptions and annotations as untrusted unless the server is trusted.

Prompt injection through tool output. Whatever a tool returns lands in the model's context: a web page, an email, a support ticket, a CMS entry. If that content contains instructions, the model may follow them, and with tools available it can act on them, for example by reading private data with one tool and sending it out with another. The spec requires servers to sanitize tool outputs and tells clients to validate results before passing them to the model, but no filter catches everything. Structural defenses matter more: don't give one agent both untrusted content and an unconfirmed way to send data out, keep high-impact actions behind user confirmation, and log every tool call.

Authentication. For remote servers, MCP authorization is built on OAuth 2.1. Your server acts as an OAuth resource server, publishes Protected Resource Metadata (RFC 9728) pointing at its authorization server, and must check that every token was issued for it. Token passthrough, accepting a token meant for another service and forwarding it downstream, is forbidden; if your server calls a third-party API, it needs its own credentials. Local stdio servers skip OAuth and read credentials from their environment, so keep those secrets out of shared configs.

Local servers. A local server runs with the user's privileges, so installing one is installing software. Check its source, pin versions, and prefer clients that show the exact command before running it, which the spec requires for one-click installs.

Should you build an MCP server or a plain API?

An MCP server isn't a replacement for an API; in most products it is a thin layer over one. The question is whether you need that layer.

Build an MCP server when customers want to use your product from AI assistants you don't build, when several internal AI tools need the same systems and you would rather integrate once, and when the useful operations fit a small set of task-shaped tools ("find unpaid invoices for a customer") rather than one tool per REST endpoint.

A plain API, with function calling inside your own app, is enough when the AI feature lives in one application you control and no outside AI client needs to reach it.

The SEO platform I built fits the second case: the model and the publishing integrations into WordPress, Shopify and custom CMSs live inside one product, with no outside AI client to serve. An MCP server would make sense if customers wanted to trigger that publishing from their own assistant.

If you do build one, design tools for the model, not for your database schema: clear names, descriptions that say when to use each tool, narrow inputs, and errors the model can act on (the spec returns these as results with isError: true).

Conclusion

MCP is now the common way to connect AI applications to tools and data. If your product should be reachable from assistants you don't build, an MCP server over your existing API is the expected path. If the AI lives entirely inside your own app, function calling against your own API is still simpler. Either way, the work that matters is the same: narrow tools, real authorization, and treating everything a tool returns as untrusted input.