> ## Content Index > Fetch the complete content index at: https://www.cognativ.com/llms.txt > Use this file to discover other available public pages before exploring further. # Understanding the Model Context Protocol (MCP): How It Works - URL: https://www.cognativ.com/blog/how-model-context-protocol-works/ - Published: 2026-10-30T19:01:33.000Z - Updated: 2026-10-31T10:02:32.000Z - Description: MCP lets AI apps reach tools and data through one open standard. See what changed in the stateless 2026 revision and how to connect servers without new risks. - Author: Kevin Anderson - Tags: AI The Model Context Protocol (MCP) is an open standard that defines how large language model (LLM) applications connect to external data sources, tools and services. Instead of writing a custom integration for every pair of AI application and external system, developers implement one protocol on each side, and any compliant client can talk to any compliant server. The official documentation compares MCP to a USB-C port for AI applications: one standard connector in place of a drawer of adapters. This guide explains how MCP works from the inside: the host, client and server roles, the tools, resources and prompts that servers expose, the message format and transports, the authorization flow for remote servers, and the security risks of giving a model access to real systems. **Spec version used:** this guide follows the current official specification at [modelcontextprotocol.io](https://modelcontextprotocol.io/specification/latest?ref=cognativ.com), protocol revision **2026-07-28**, released on July 28, 2026\. That revision changed the protocol substantially, most notably by removing sessions and the initialization handshake, so tutorials written against the 2024 and 2025 revisions may no longer match the spec. Where behavior changed, this guide says so. ## Key Takeaways - MCP standardizes how AI applications (hosts) reach external capabilities through clients that each connect to exactly one server, using JSON-RPC 2.0 messages. - Servers expose three primitives: **tools** the model calls, **resources** the application reads as context and **prompts** the user selects. - Since revision 2026-07-28 the core protocol is stateless: every request carries its own protocol version and client capabilities. - The standard transports are stdio for local servers and Streamable HTTP for remote ones; the older HTTP+SSE transport is deprecated. - Remote servers use OAuth 2.1-based authorization with audience-bound tokens, and tools are treated as arbitrary code execution that requires user consent. ## What Is the Model Context Protocol and Why It Matters The specification describes MCP as an open protocol that provides a standardized way for applications to share contextual information with language models, expose tools and capabilities to AI systems, and build composable integrations and workflows. On its own, an LLM knows only its training data and whatever text sits in its context window. To answer questions about today's tickets, query a database or open a pull request, it needs a controlled way to reach those systems. Before MCP, every AI application solved that with its own plugin format and glue code, so an integration built for one assistant rarely worked in another. ### The integration problem MCP solves When Anthropic introduced MCP on [November 25, 2024](https://www.anthropic.com/news/model-context-protocol?ref=cognativ.com), it named the problem directly: every new data source required its own custom implementation. With M applications and N systems, point-to-point integration means up to M × N connectors. A shared protocol turns that into M clients plus N servers. The design borrows from the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/?ref=cognativ.com), which did the same for programming-language support in editors. ### Where MCP came from and who governs it Anthropic released MCP with a specification, SDKs, local server support in Claude Desktop and a repository of reference servers. On [December 9, 2025](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation?ref=cognativ.com), it donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. At that point Anthropic reported more than 10,000 active public MCP servers and more than 97 million monthly SDK downloads across Python and TypeScript; those are its December 2025 figures, not current measurements. Revisions are named by date, and the project's [release-candidate post](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/?ref=cognativ.com) called 2026-07-28 the largest revision since launch. ### Key Features of MCP - **Client-host-server architecture:** hosts coordinate many clients, and each client connects to one server. - **JSON-RPC 2.0 messaging:** requests, results, errors and notifications share one format. - **Three server primitives:** tools, resources and prompts, each with a different control model. - **Multiple transports:** stdio, Streamable HTTP and room for custom bindings. - **Per-request capability negotiation** plus a discovery call for server capabilities. - **Authorization and consent:** OAuth 2.1 for HTTP servers and explicit consent principles. - **Opt-in extensions** such as Tasks and MCP Apps. ## MCP Architecture and Core Components MCP follows a client-host-server architecture in which each host can run multiple client instances. The [architecture page](https://modelcontextprotocol.io/specification/2026-07-28/architecture?ref=cognativ.com) says this design lets users integrate AI capabilities across applications while keeping clear security boundaries. ### The Client-Server Model | Component | What it is | Main responsibilities | | ---------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | MCP host | The LLM application the user works in, such as a chat app, IDE assistant or agent runtime | Creates and manages clients, enforces security policies and consent, coordinates the LLM and aggregates context | | MCP client | A connector inside the host, one per server | Talks to exactly one server, attaches protocol version and capabilities to every request, manages subscriptions and keeps servers isolated | | MCP server | A local process or remote service | Exposes tools, resources and prompts, requests extra input when needed and respects security constraints | The host is the coordinator. It decides which servers to connect, creates one client per server and is the only component that sees the full conversation. A host connected to a file server, a database server and a ticketing server therefore runs three clients side by side. ### Design principles behind the architecture The specification lists four principles: servers should be extremely easy to build, highly composable, unable to read the whole conversation or "see into" other servers, and able to add features progressively. The isolation principle matters most for security. A careless server should not be able to read your chat history or call another server's tools, and that boundary is enforced by the host, which is why host quality matters as much as server quality. ![An MCP host contains Client A and Client B; Client A connects only to a file server and Client B connects only to an API server.](https://storage.ghost.io/c/cc/dc/ccdca949-0fe4-4119-8990-70a44ad75060/content/images/2026/10/how-model-context-protocol-works-1.png) The host coordinates the conversation and creates one client per server, so each server stays isolated from the others. ## Tools, Resources and Prompts: What MCP Servers Expose Servers offer capabilities through three primitives. The difference between them is who decides when each is used: the model, the application or the user. ### Tools: model-controlled actions [Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools?ref=cognativ.com) are functions the model can discover and invoke, such as querying a database or calling an API. A client lists them with `tools/list` and calls one with `tools/call`. Each tool has a unique name, a description, an `inputSchema` in JSON Schema and an optional `outputSchema` for structured results. Protocol problems, such as an unknown tool, return a JSON-RPC error; execution problems, such as an invalid date, return a normal result with `isError: true` so the model can correct itself and retry. ### Resources: application-driven context [Resources](https://modelcontextprotocol.io/specification/2026-07-28/server/resources?ref=cognativ.com) are data that give the model context: files, database schemas or documents. Each is identified by a URI and read with `resources/read`; templates expose parameterized resources, and clients can subscribe to updates. The host decides how to include them, for example through a picker or automatic selection. This is the primitive for internal documents, and the governance questions are the same ones covered in our guide to [using an LLM with private data](https://www.cognativ.com/blog/how-to-use-llm-with-private-data/). ### Prompts: user-controlled templates [Prompts](https://modelcontextprotocol.io/specification/2026-07-28/server/prompts?ref=cognativ.com) are reusable message templates that a user selects explicitly, often as slash commands. A client discovers them with `prompts/list` and retrieves one, with arguments, through `prompts/get`. The server defines the content; the user decides when to use it. ### What clients offer servers: elicitation The active client feature in 2026-07-28 is [elicitation](https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation?ref=cognativ.com): a server asks the user for more information mid-request. Form mode collects simple structured data; URL mode sends the user to an external page so sensitive data never passes through the client or the model. Servers must not use form mode for passwords, API keys, tokens or payment credentials. Sampling and roots still work but were deprecated in this revision, along with protocol-level logging. ![Three parallel columns: tools are controlled by the model, resources by the application, and prompts by the user.](https://storage.ghost.io/c/cc/dc/ccdca949-0fe4-4119-8990-70a44ad75060/content/images/2026/10/how-model-context-protocol-works-2.png) Tools, resources and prompts differ mainly in who decides when they are used. ## Transport Layer and Communication Protocols MCP separates what messages mean from how they travel. A transport is a binding that defines framing, delivery and cancellation; the message patterns are identical on every transport. ### JSON-RPC messages and the stateless core All messages use [JSON-RPC 2.0](https://www.jsonrpc.org/specification?ref=cognativ.com). Clients send requests and notifications; servers send results, errors and notifications, and no longer initiate requests of their own. Earlier revisions opened each connection with an `initialize` handshake and kept a session. Now every request carries its protocol version and client capabilities in `_meta`, servers must implement `server/discover` to advertise supported versions and capabilities, and an unsupported version returns an `UnsupportedProtocolVersionError`. Servers that need state across calls return an explicit handle and accept it as a tool argument later. ### Standard input/output (stdio) With [stdio](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports?ref=cognativ.com), the client launches the server as a subprocess and exchanges newline-delimited JSON-RPC over standard input and output. It is the simplest option for local servers: no network port and access limited to the parent process. ### Streamable HTTP For remote servers, [Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http?ref=cognativ.com) exposes one endpoint, such as `https://example.com/mcp`. Each message is its own HTTP POST, and the server answers with a JSON object or a Server-Sent Events stream scoped to that request. Required headers such as `MCP-Protocol-Version` and `Mcp-Method` let gateways route traffic without parsing the body, and closing the stream cancels the request. Without sessions, remote servers can run on ordinary stateless HTTP infrastructure. ### What happened to HTTP + SSE Many early MCP articles, including the first version of this one, describe remote connections as "HTTP with Server-Sent Events." That was the 2024-11-05 transport. Streamable HTTP replaced it in revision 2025-03-26, and 2026-07-28 formally classifies HTTP+SSE as deprecated. ## How MCP Works: From User Request to AI Response Here is what happens when a user asks an MCP-enabled assistant something that needs outside data or action. ### Workflow Overview 1. **Discovery:** each client learns its server's capabilities and lists its tools, resources and prompts. 2. **User request:** the host sends the question to the LLM along with tool definitions and any chosen resources. 3. **Tool selection:** the model proposes a tool call; a well-built host shows it and lets the user approve or deny it. 4. **Server invocation:** the client sends `tools/call`; the server validates the input, does the work and returns a result. 5. **Response generation:** the host adds the result to the model's context, and the model answers or calls another tool. ### Multi round-trip requests If a server needs more input, such as a user confirmation, it no longer sends its own request to the client. It returns an `InputRequiredResult` describing what it needs, and the client retries the original request with the answers attached. This keeps the protocol stateless while still allowing interactive workflows. ### Function Calling and Tool Usage MCP builds on function calling, the mechanism by which a model asks to run a named function with arguments. Function calling expresses intent; MCP standardizes how tools are described, discovered, invoked, authorized and returned. The host translates MCP tool definitions into its model provider's format, so the same server works with different models. Vendor agent platforms add orchestration on top, a trade-off we examine in our evaluation of the [OpenAI Agents API, Agents SDK and Responses API](https://www.cognativ.com/blog/openai-agents-api-for-ai-development/). ![A user question goes to the model, the model proposes a tool call, the user approves it, the MCP server runs it, and the result returns as the answer.](https://storage.ghost.io/c/cc/dc/ccdca949-0fe4-4119-8990-70a44ad75060/content/images/2026/10/how-model-context-protocol-works-3.png) A tool call passes through user approval before the server acts, and the result goes back into the model's context. ## MCP Servers and Clients: Integration and Ecosystem ### MCP Servers: Gateways to External Data and Tools An MCP server wraps a system, such as a database, SaaS API, file system, repository, CRM or ERP, and exposes it as tools, resources and prompts. It can run locally or as a remote service, and teams can adopt existing servers or build their own with the official SDKs. The spec requires servers to validate tool inputs, implement access controls, rate-limit invocations and sanitize outputs. Deciding which systems to expose, with which scopes and owners, is usually the harder part, and it is what our [AI integration services](https://www.cognativ.com/ai/integration/) team scopes before a server is built. ### MCP Clients: Facilitating AI Interaction Clients live inside hosts. In the current revision they discover server capabilities, attach version and capability metadata to every request, translate model tool calls into MCP requests, handle input requests, subscriptions and cancellation, and carry the right token for each server. Hosts include desktop chat apps, AI coding assistants and agent frameworks, and local agent stacks can use the same protocol with an on-device model, as described in our guide to [local AI agents](https://www.cognativ.com/blog/local-ai-agents-guide/). ### Extensions beyond the core Revision 2026-07-28 moved specialized features into opt-in [extensions](https://modelcontextprotocol.io/extensions/overview?ref=cognativ.com). Tasks handles long-running operations with polling and durable handles, and MCP Apps lets servers render interactive UI such as forms and charts inside the conversation. ## How MCP Authorization Works The [authorization specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization?ref=cognativ.com) is optional, but HTTP-based servers that use authorization should follow it; stdio servers take credentials from their environment instead. It is based on OAuth 2.1: the MCP server is a resource server, the client is an OAuth client acting for the user, and an authorization server issues tokens. 1. The client calls the server without a token and receives HTTP 401 pointing to the server's Protected Resource Metadata ([RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728?ref=cognativ.com)). 2. The client discovers the authorization server through its metadata ([RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414?ref=cognativ.com)) or OpenID Connect Discovery. 3. The client identifies itself, preferably with a Client ID Metadata Document; Dynamic Client Registration is now deprecated. 4. The user signs in through the browser with PKCE and a `resource` parameter naming the exact server ([RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html?ref=cognativ.com)). 5. The client exchanges the code for an access token and sends it as a Bearer token on every request. Two rules carry most of the weight: servers must validate that each token was issued for them, and they must not accept or pass through tokens issued for anything else. Scopes should start minimal; when an operation needs more, the server returns HTTP 403 with an `insufficient_scope` challenge and the client steps up. ![The client receives a 401 challenge, discovers the authorization server, the user signs in and consents, and the client calls the server with an audience-bound token.](https://storage.ghost.io/c/cc/dc/ccdca949-0fe4-4119-8990-70a44ad75060/content/images/2026/10/how-model-context-protocol-works-4.png) Remote MCP servers point clients to their authorization server, and tokens are issued for that one server only. ## Security Considerations and Best Practices The specification is direct: tools represent arbitrary code execution, hosts must obtain explicit user consent before invoking any tool, and tool annotations should be treated as untrusted unless they come from a trusted server. The protocol cannot enforce these principles itself; implementations must. ### Prompt injection through tools and data Tool descriptions, tool results and resource contents are text the model reads. A malicious server, or a legitimate one returning attacker-controlled content such as an email, can embed instructions that try to redirect the model. OWASP lists this as [LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/?ref=cognativ.com), including the indirect form. Defenses include least privilege per server, human approval for high-impact actions and connecting only trusted servers. ### Token passthrough and the confused deputy The [security best practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security%5Fbest%5Fpractices?ref=cognativ.com) call token passthrough an anti-pattern because it bypasses rate limits and audit trails. MCP servers that proxy third-party APIs also face a confused deputy attack, mitigated by per-client consent, exact redirect URI matching and single-use `state` values. ### SSRF, DNS rebinding and local server compromise A malicious server can feed OAuth discovery URLs that point at internal networks or cloud metadata endpoints, so clients should require HTTPS and block private address ranges. Local HTTP servers must validate the `Origin` header and should bind to localhost. One-click installation of a local server must show the full command and get explicit approval, ideally running it sandboxed. ### A practical security checklist - Inventory every connected server, its owner, transport and reach. - Prefer stdio for single-user local tools; require authorization for HTTP servers. - Grant minimal scopes and require confirmation for writes, payments and outbound messages. - Log tool calls, set timeouts and bind any state handle to the authenticated user. ## Advantages and Limitations of MCP ### Advantages of MCP - **Fewer custom integrations:** one server works across many hosts. - **Access to current data:** models can work with live systems, not only training data. - **Grounded answers:** responses built from retrieved records can be checked against their source, although MCP does not by itself prevent hallucination. - **Vendor neutrality:** open governance under the Linux Foundation reduces lock-in to one model provider. ### Limitations to plan for MCP standardizes the connection, not the judgment. It does not decide which tools a model should have or guarantee that a third-party server is safe, and every tool definition passed to the model takes up context. The protocol is also still evolving: 2026-07-28 introduced breaking changes, so treat the spec version as a dependency you track. ### MCP vs APIs and RAG MCP does not replace REST or GraphQL APIs; most servers call them underneath. Nor does it replace retrieval-augmented generation, which an MCP resource or search tool can implement. If you are planning agents that act across several systems, our [AI agent development](https://www.cognativ.com/ai/agent-development/) practice designs the tool boundaries, permissions and evaluation around protocols like MCP. ## Frequently Asked Questions What is the Model Context Protocol in simple terms? MCP is an open standard that lets AI applications connect to external tools and data through one common interface. A server exposes capabilities once, and any MCP-compatible application can use them. Who created MCP and who maintains it now? Anthropic introduced MCP in November 2024\. In December 2025 it was donated to the Agentic AI Foundation under the Linux Foundation, and its maintainers continue to develop it through a public proposal process. What is the current MCP specification version? As of October 30, 2026, the current revision on modelcontextprotocol.io is 2026-07-28\. It made the core protocol stateless, removed sessions and the initialize handshake, and deprecated sampling, roots, logging and the HTTP+SSE transport. What is the difference between MCP and function calling? Function calling is how a model asks to run a named function. MCP standardizes how those functions are described, discovered, invoked, authorized and returned across applications and servers. Is MCP secure? MCP defines consent principles, OAuth 2.1-based authorization and detailed security guidance, but security depends on implementation. Connect only trusted servers, grant minimal scopes and require approval for sensitive actions. Does MCP replace RAG or APIs? No. MCP servers usually call existing APIs, and retrieval-augmented generation can run through MCP resources or search tools. MCP is the connection layer, not the retrieval strategy. ## Conclusion: How the Model Context Protocol Works The Model Context Protocol gives AI applications a common way to reach the outside world. Hosts coordinate clients, each client talks to one server, and servers expose tools for the model, resources for the application and prompts for the user. Messages travel as JSON-RPC over stdio or Streamable HTTP, remote access is protected by audience-bound OAuth tokens, and since the 2026-07-28 revision every request stands on its own. That standardization removes much of the integration work that used to stall AI projects, but it also widens what a model can touch. Teams that benefit most treat MCP servers as production integrations with owners, scopes, approvals and audit logs. If you are deciding which systems to expose to your AI applications through MCP, and how to govern them, [talk to Cognativ about your AI integration project](https://www.cognativ.com/contact/).