SXF TECHNICAL REFERENCE / AI AGENTS
What Is MCP?
How Model Context Protocol Connects AI Agents to Tools & Data
Model Context Protocol gives AI applications a common way to discover and use external capabilities. Instead of writing a bespoke integration for every model, agent, database, SaaS API or local tool, developers can expose a consistent MCP interface. This research-first guide explains the architecture, the July 28, 2026 specification, transports, authorization, security boundaries, production design and where MCP fits relative to APIs, function calling, RAG, plugins and agent-to-agent protocols.
MCP is a standard interface for connecting AI applications to tools and data.
Model Context Protocol (MCP) is an open protocol for communication between an AI host and external services that provide context or capabilities. MCP uses JSON-RPC messages and defines three core server features: tools the model can execute, resources that expose context or data, and prompts that package reusable message templates or workflows. The host owns the user experience and policy boundary; an MCP client inside that host communicates with an MCP server. The current final specification, 2026-07-28, makes the core stateless and self-contained per request.
DEFINITION
What is Model Context Protocol?
Model Context Protocol is an open protocol that standardizes how LLM applications connect to external data sources and tools. The official specification describes hosts as the LLM applications that initiate connections, clients as connectors inside those hosts, and servers as services that provide context and capabilities. Communication uses JSON-RPC 2.0.
The easiest analogy is the Language Server Protocol. Before LSP, every code editor needed custom integration logic for every programming language. LSP introduced a shared contract between editors and language servers. MCP applies a similar idea to AI: a host can speak one protocol to many capability providers, and a server can expose one MCP interface to multiple compatible hosts.
That does not mean MCP is “the USB-C of AI” in every technical sense, and it does not make integrations interchangeable without policy. The useful part of the analogy is standardization: a common envelope for discovery, structured calls, context, capability metadata and authorization.
It does not make a model reason better. It gives an AI application a consistent way to reach capabilities outside the model.
WHY MCP EXISTS
The integration problem MCP is trying to solve
AI agents become useful when they can act on real systems: search a knowledge base, query a database, read a repository, create a ticket, inspect logs, send a message, edit a design or run a deployment check. Without a shared protocol, every host-to-service combination needs bespoke glue.
Imagine five AI hosts and twenty internal services. A direct-integration approach can turn into dozens of separate adapters, each with its own schemas, authentication assumptions, error handling and discovery mechanism. MCP changes the topology. Services expose an MCP server or gateway; hosts implement MCP clients. The application still needs product-specific policy and each service still needs domain logic, but the connection contract is standardized.
Each AI application must learn how every data source or action API works, including discovery, schemas, errors and credentials.
The host can discover tools, resources and prompts and invoke them using a shared message model.
MCP usually sits in front of existing APIs, databases, files, SaaS products or internal services.
A standard protocol cannot decide whether a particular user should be allowed to delete production data.
This matters most in agentic systems, where the set of useful capabilities is broader and changes faster than in a conventional chatbot. See What Is Agentic AI? for the wider execution-loop architecture.
ARCHITECTURE
MCP Host vs Client vs Server
MCP terminology is simple once the responsibilities are separated.
The AI application
The host is the user-facing LLM application: an IDE, assistant, desktop app, agent runtime or custom product. It owns the conversation, model access, trust policy, consent UX and lifecycle of MCP connections.
The per-server connector
An MCP client lives inside the host and communicates with one MCP server. It handles protocol messages, transport details, capability metadata and—in remote deployments—authorization flow mechanics.
The capability provider
An MCP server exposes tools, resources or prompts. It can be a local subprocess, a remote service, a wrapper around an API, a database gateway or an enterprise integration layer.
The real system of record
The MCP server usually talks to something underneath it: GitHub, Salesforce, PostgreSQL, a filesystem, a proprietary API or another internal service.
A host can maintain many MCP clients simultaneously. The key boundary is that each client-server relationship can have its own trust, credentials and capability set. That makes it possible to connect a coding agent to a repository server, an issue tracker server and an observability server without pretending those systems share one security domain.
SERVER FEATURES
Tools vs Resources vs Prompts
The official specification separates three server-side concepts because “context” and “action” are not the same thing.
| Capability | What it represents | Typical control | Example |
|---|---|---|---|
| Tools | Callable functions and actions | Usually model-selected, bounded by host policy | create_issue, search_logs, run_query |
| Resources | Readable context or data | Application/user/model consumption depending on host design | A file, schema, document, repository tree or database record |
| Prompts | Reusable templated messages or workflows | Typically surfaced as user- or host-invoked workflows | “Review this pull request” with structured arguments |
Tools deserve the most caution because they can create side effects. The specification explicitly warns that tools can represent arbitrary code execution paths and that tool descriptions should be treated as untrusted unless they come from a trusted server. A friendly description is not an authorization control.
Resources are useful for context that can be named and read. They can reduce the temptation to turn every data lookup into an action-like tool. Prompts are useful for packaging repeatable interaction patterns without hard-coding them into every host.
REQUEST LIFECYCLE
How an MCP call works, step by step
Under the 2026-07-28 specification, the core protocol is stateless. Every request carries the information required to interpret it, rather than relying on a hidden protocol session.
Configure or discover the server
The host knows an MCP endpoint or launches a local server. A client may optionally call server/discover to learn capabilities before doing other work.
Authorize if required
For protected remote HTTP servers, the client obtains a token for the MCP server as the intended resource. Local stdio servers normally receive credentials from their environment instead.
List capabilities
The client can request tool, resource or prompt catalogs. In the current spec, list responses can include cache hints so the client does not repeatedly fetch unchanged catalogs.
The model or host selects an operation
The model may decide to call a tool, while the application can also read a resource or surface a prompt. Host policy can block, filter or require approval.
Send a JSON-RPC request
The request identifies the protocol version and client capabilities. With Streamable HTTP, method and tool names are also carried in routing-friendly headers.
The server executes domain logic
The server validates arguments, checks authorization, calls its backend and returns structured content or an error.
The host feeds the result back into the agent loop
The model observes the result and can continue, retry, choose another tool, ask for missing information or stop.
Some operations need additional information in the middle of a call. The 2026-07-28 release introduced Multi Round-Trip Requests (MRTR) so a server can indicate that input is required and the client can retry the original operation with the answers attached—without requiring a continuously open bidirectional protocol session.
TRANSPORTS
stdio vs Streamable HTTP
The protocol semantics are the same across transports; the transport only determines how MCP messages are framed and delivered.
The host launches a subprocess and exchanges newline-delimited JSON-RPC messages over standard input and output. It is simple for local developer tools and can inherit credentials or environment configuration from the launching process.
Each message is an HTTP POST to a single MCP endpoint. The response is either a JSON object or a request-scoped SSE stream. Standard web infrastructure can front the service.
Streamable HTTP is the modern remote transport. The legacy HTTP+SSE transport is deprecated in the July 2026 release with a migration window. For new remote deployments, build against the current Streamable HTTP binding rather than designing around the older stateful transport.
The practical choice is architectural: if the capability is a local process tightly coupled to the host, stdio is usually easier. If many users, hosts or workers need to reach the same capability service, HTTP is usually the production path.
CURRENT SPECIFICATION
What changed in MCP 2026-07-28?
As of October 5, 2026, 2026-07-28 is the current final MCP specification. It is a major architectural revision, not a cosmetic version bump.
The previous initialize/initialized exchange and Mcp-Session-Id are retired for this revision. Each request is self-describing.
server/discoverOptional capability discovery.A client can learn server capabilities up front, but it is not required before making ordinary requests.
Multi Round-Trip Requests let a server return an input-required state and let the client retry with responses attached.
Streamable HTTP uses Mcp-Method and Mcp-Name headers so routers, WAFs and rate limiters do not need to parse the JSON body.
Tool, prompt and resource list/read responses carry cache hints and deterministic ordering, reducing refetches and stabilizing prompt caches.
The revision adds stronger OAuth guidance, moves toward Client ID Metadata Documents and formally deprecates Dynamic Client Registration for the future.
Tasks, MCP Apps and enterprise-oriented extensions can evolve without bloating the base protocol.
The project formalized a minimum deprecation window; Roots, Sampling and Logging are deprecated in this revision for new implementations.
The stateless change is especially important for production. A request can land on any compatible server instance behind an ordinary load balancer without shared protocol-session state. Applications can still be stateful when the workflow requires it; the state becomes explicit application data or a durable handle instead of invisible transport state.
POSITIONING
MCP vs API, function calling, RAG, plugins and A2A
MCP is easiest to understand by separating layers rather than treating every integration technology as a competitor.
| Technology | Primary job | How it relates to MCP |
|---|---|---|
| API | Expose application or service operations/data | An MCP server often wraps one or more APIs. MCP standardizes the AI-facing integration contract; the API remains the backend contract. |
| Function calling | Let a model select structured functions defined by the host | MCP can supply externally discovered tools that the host then exposes through its model tool/function-calling mechanism. |
| RAG | Retrieve relevant knowledge and place it into model context | RAG is a retrieval pattern. MCP resources or tools can provide the retrieval interface, but MCP does not define ranking, embeddings or retrieval quality. |
| Connectors / plugins | Product-specific integrations | A connector can be implemented on top of MCP, and a host can present MCP servers as connectors. “Plugin” is a packaging/product concept; MCP is a protocol. |
| A2A | Agent-to-agent communication and task collaboration | A2A addresses interactions between agents; MCP addresses an application's access to tools and context. A multi-agent system can use both. |
MCP vs API
An API is usually the canonical interface for a service. MCP should not force you to throw that away. A production MCP server often becomes an adapter over existing domain APIs, adding AI-oriented capability metadata, structured tool schemas and MCP-compatible authorization behavior.
MCP vs function calling
Function calling answers: “How does this model ask the application to invoke a structured function?” MCP answers: “How does the application discover and communicate with an external capability provider?” They fit together. The host can discover tools from MCP servers, apply policy and expose approved tools to the model.
MCP vs RAG
RAG is about retrieval. MCP is about interoperability. A RAG system can use MCP to reach document stores, search services or database tools, but MCP does not decide which chunks are relevant or whether retrieved content is trustworthy. Prompt injection remains a separate security problem; see Prompt Injection in AI.
MCP vs connectors and plugins
Connectors and plugins are product surfaces. They may use proprietary interfaces, MCP, or both. MCP's value is portability: the same server can potentially serve more than one compatible host, subject to authentication and host policy.
MCP vs A2A
Agent-to-Agent protocols target peer communication, delegation and task coordination between agents. MCP targets capabilities available to an AI application. A supervisor agent might use A2A to delegate to another agent while both agents separately use MCP servers to access databases and tools.
SECURITY
MCP security: where the real risks are
MCP standardizes communication, not trust. A malicious server can advertise deceptive tools, return hostile content or abuse credentials. A legitimate server can still have ordinary API vulnerabilities. A safe architecture assumes every external boundary can fail.
Prompt injection
An MCP tool or resource can return text that contains instructions aimed at the model. Those instructions are data from a lower-trust source, even if they are syntactically valid MCP content. The host should preserve provenance, limit what returned content can authorize, and avoid giving one model both broad untrusted context and broad irreversible authority. For the full threat model, see Prompt Injection in AI.
Confused deputy
A confused-deputy failure happens when a more privileged component is tricked into using its authority for someone else's purpose. In MCP deployments, this can appear when a client or proxy holds credentials and an attacker causes it to send those credentials to the wrong service or perform an operation outside the user's intended resource. OAuth resource binding, issuer validation, redirect validation and exact server identity checks exist to reduce this class of error.
Token passthrough
A dangerous shortcut is accepting a token from a client and passing it directly to an upstream API even when the token was not issued for that MCP server. The current authorization specification explicitly requires MCP servers to accept only tokens valid for their own resources and not to accept or transit other tokens. Use proper token exchange or backend-specific credentials when the server must call another protected system.
SSRF
Remote servers often call URLs, webhooks, storage endpoints or APIs. If a tool accepts arbitrary URLs, an attacker may try to make the server reach internal metadata services, private networks or loopback endpoints. Treat outbound network access as a permission: validate destinations, block private address ranges where appropriate, use egress proxies or allowlists, and resolve DNS safely.
Malicious MCP servers
Installing an MCP server is equivalent to expanding an agent's supply chain. A local stdio server may execute code with the user's OS permissions. A remote server may receive sensitive query content and OAuth-granted access. Server names, README files and tool descriptions are not trust proofs. Pin packages where possible, review publishers, verify source, inspect permissions, and make server enablement an explicit administrative decision in enterprise environments.
Tool descriptions are not policy
The protocol itself warns hosts to consider tool descriptions untrusted unless the server is trusted. A description that says “read-only” is metadata, not enforcement. The server should implement read-only behavior, the backend credential should lack write permission, and the host should independently classify risky actions when feasible.
These controls sit inside the wider discipline of AI Agent Security: identity, least privilege, sandboxing, approval gates, monitoring, provenance and revocation all matter once a model can act.
ARCHITECTURE DECISION
When should you use MCP—and when should you not?
Many AI hosts need the same capability
A standardized server is valuable when multiple assistants, IDEs or agent runtimes should reuse one integration.
Your capability catalog changes over time
Discovery lets clients learn tools or resources instead of hard-coding every integration at build time.
You want a clean policy boundary
An MCP gateway can centralize schemas, authorization, rate limits, logging and domain-specific validation around existing backend APIs.
You need local developer tooling
stdio makes it straightforward to expose local repositories, CLIs or files to a compatible desktop or IDE host.
One application calls one stable API
If the integration is tiny, private and unlikely to be reused, a direct typed client may be simpler and easier to operate.
The workflow is fully deterministic
If every step is known and no model needs to choose capabilities, a normal service or job queue may be the better abstraction.
You cannot define a safe tool boundary
Do not expose a high-privilege general shell or database credential merely because MCP makes it easy to call.
Protocol support adds more complexity than value
MCP is not a requirement for “being agentic.” Use it when interoperability pays for the extra operational surface.
BUILDING FOR PRODUCTION
How to build a production-grade MCP server
A production MCP server should look like a mature API service with additional agent-facing constraints—not a thin script that blindly executes whatever the model asks.
1. Design narrow tools around outcomes
Prefer create_invoice_draft over run_arbitrary_sql. Narrow tools reduce ambiguity, constrain parameters and make authorization understandable. If an operation has materially different risk levels, split it into separate tools so the host can apply different approval policies.
2. Validate inputs twice
Use schema validation at the MCP boundary and domain validation inside the service. Check IDs, enums, lengths, ranges, ownership and business preconditions. Never assume that “the model generated it” makes an argument safe.
3. Make side effects idempotent
Agents retry. Networks fail after a server commits but before the client receives the response. Destructive or financial tools should accept idempotency keys or otherwise make duplicate execution safe.
4. Keep secrets out of model context
The server—not the model—should hold API keys and service credentials. Return the minimum result needed for the task. Do not echo authorization headers, refresh tokens or internal connection strings into tool output.
5. Separate identity from authority
Knowing which user initiated a request is not enough. Evaluate what that identity may do to the specific resource. Enforce scopes, tenancy and object-level permissions server-side.
6. Control outbound network access
If tools can fetch URLs or call third-party systems, use an egress policy. Block internal address ranges where appropriate and avoid unrestricted redirects. SSRF prevention belongs at the network and application layers.
7. Emit operational telemetry
Log request IDs, authenticated subject, tool name, policy decision, latency, backend status and a redacted summary of arguments/results. Keep sensitive payloads out of logs unless retention is explicitly justified.
8. Rate-limit by capability
Not all tools cost the same. Apply stricter limits to expensive searches, write operations, deployments and bulk exports. With current Streamable HTTP, method/name headers give gateways a convenient routing and metering signal.
9. Design explicit error contracts
Agents need to know whether to retry, repair input, request permission or stop. Return structured, stable errors instead of vague prose. Distinguish authorization failures, validation errors, transient backend failures and permanent domain conflicts.
10. Test adversarially
Include malformed schemas, prompt-injected resource content, hostile tool output, repeated calls, stale tokens, insufficient scopes, cross-tenant identifiers, large payloads and partial backend failures in your test suite. The security boundary is the whole server, not only the JSON parser.
FAILURE MODES
Common MCP deployment failures
Hundreds of overlapping tools make model selection unreliable and inflate context. Curate capabilities and use clear names and schemas.
A generic shell, SQL executor or HTTP client gives the model more authority than the business task requires.
Servers that secretly depend on one instance's memory fight the stateless architecture and fail unpredictably behind load balancers.
Tokens are reused across resources or forwarded upstream without audience validation.
Retries create duplicate tickets, payments, deployments or messages.
The host assumes a tool is read-only because its metadata says so rather than enforcing policy elsewhere.
Tool responses leak secrets, internal metadata or entire records when the agent only needed one field.
Long-running backend work keeps consuming resources after the user or client has abandoned the request.
Workflow state is hidden inside transport sessions instead of represented explicitly with durable IDs or task handles.
A server upgrades spec behavior without testing older hosts or following the protocol's version/deprecation rules.
ECOSYSTEM SUPPORT
OpenAI MCP support and GitHub Copilot MCP support
OpenAI
OpenAI's API documentation supports remote MCP servers as a tool integration path. Developers can configure MCP servers so models can discover and call exposed tools through OpenAI's tool framework. OpenAI also distinguishes first-party connectors from arbitrary remote MCP servers and advises developers to review what data is shared and what actions a server can perform.
The architectural point is important: MCP does not bypass OpenAI's tool policy layer. The application still decides which server is connected, which tools are approved and when user confirmation is required.
GitHub Copilot
GitHub documents MCP support for extending Copilot Chat with external tools and context. In supported IDE configurations, users or administrators can configure MCP servers and expose their capabilities to Copilot. That makes MCP directly relevant to developer workflows: repository tools, issue systems, documentation servers, databases and internal engineering services can be made available through one standardized interface.
Because developer environments often contain source code and credentials, local MCP configuration deserves the same supply-chain discipline as editor extensions and CLI packages.
EXTENSIONS
MCP Tasks and MCP Apps
The July 2026 specification formalized an extensions framework so optional capabilities can evolve without complicating the core protocol.
Tasks provide durable handles for work that cannot finish inside one normal request. The extension includes polling through tasks/get and update behavior, making it suitable for jobs such as large imports, code analysis or lengthy generation.
MCP Apps let servers supply interactive UI elements such as forms, charts or media experiences, moving beyond plain text tool results while keeping the integration attached to the MCP capability model.
These are extensions, not requirements for every MCP deployment. A simple database lookup server should stay simple. Use Tasks when the job lifecycle is genuinely asynchronous and Apps when interaction materially improves the workflow.
GOVERNANCE & FUTURE
MCP, the Agentic AI Foundation and the future of agent infrastructure
Anthropic originally introduced MCP in November 2024 as an open standard for connecting AI assistants to data systems. Its governance has since broadened. The Linux Foundation announced the Agentic AI Foundation (AAIF) with MCP as one of its anchor project contributions alongside other agent infrastructure projects.
That governance shift matters because interoperability standards become more useful when no single application vendor controls their evolution. It also does not guarantee universal adoption. Enterprises will continue to use direct APIs, proprietary connectors and internal gateways where those abstractions fit better.
The direction is clearer than the final shape: agent systems need standardized capability discovery, identity, authorization, long-running work, UI surfaces and policy enforcement. MCP is becoming one of the core protocols in that stack. Its 2026 move toward stateless, cacheable, routable HTTP infrastructure shows the project optimizing for real production deployment rather than only local demos.
DEPLOYMENT CHECKLIST
Production MCP server checklist
Narrow capability boundary
Expose task-shaped tools, not generic root access.
Least privilege
Use minimal scopes and backend credentials.
Strict validation
Validate schemas, tenancy and domain rules.
Secret isolation
Keep credentials out of model context and responses.
Egress controls
Protect against SSRF and uncontrolled third-party calls.
Idempotency
Make retries safe for side-effecting operations.
Audit trail
Record identity, capability, policy result and outcome.
Rate limits
Meter expensive and destructive capabilities separately.
Adversarial testing
Test injected content, malicious servers and cross-tenant access.
Version discipline
Track spec versions, SDK updates and deprecations.
If the server can affect production systems, combine these controls with the broader practices in AI Agent Security. If you are assembling several agents and tools into one control plane, see How to Build an AI Super Agent.
FAQ
Model Context Protocol FAQ
What is MCP in AI?
MCP is an open protocol that standardizes how AI applications connect to external tools, data sources and reusable prompts.
Who created MCP?
Anthropic introduced Model Context Protocol in November 2024. The project later moved into broader open governance and became an anchor contribution to the Linux Foundation's Agentic AI Foundation.
Is MCP an API?
Not exactly. MCP is a protocol for AI-facing capability integration. An MCP server frequently wraps ordinary APIs, databases or files.
What is the difference between an MCP host, client and server?
The host is the AI application. A client is the connector inside that host that communicates with one server. The server exposes tools, resources or prompts.
What is the latest MCP specification?
As of October 5, 2026, the current final specification is 2026-07-28.
Is MCP stateful?
The current protocol core is stateless. Applications can still maintain explicit workflow state through their own databases, task handles or tool-returned identifiers.
Does MCP require OAuth?
No. Authorization is optional. HTTP deployments that use authorization should follow the MCP OAuth-based authorization specification. stdio servers normally receive credentials from their environment.
Is MCP secure?
MCP provides security-oriented protocol rules, but it cannot make a server or tool trustworthy. Secure deployment requires consent, authorization, token validation, least privilege, input validation, egress controls, logging and supply-chain review.
What is MCP vs function calling?
Function calling is a model interaction mechanism. MCP is an integration protocol between the host application and external capability providers. Hosts often connect the two.
What are MCP Tasks?
Tasks are an optional extension for long-running asynchronous operations with durable handles and polling.
What are MCP Apps?
MCP Apps are an optional extension for interactive UI elements rendered inside compatible hosts.
GLOSSARY
MCP glossary
Owns the model experience, policies, consent and client connections.
Communicates with one MCP server using the negotiated transport and protocol version.
Exposes tools, resources or prompts backed by local or remote systems.
Usually presented to the model as an action it may select.
A named information object such as a file, document or structured record.
Packages a repeatable interaction pattern or workflow.
Newline-delimited JSON-RPC over a subprocess's standard streams.
POST requests to one endpoint with JSON or request-scoped SSE responses.
A pattern for gathering additional input during an operation without a permanent bidirectional stream.
Identifies the MCP server for which an access token is being requested.
PRIMARY SOURCES
Primary sources and further reading
This guide prioritizes protocol maintainers and primary vendor documentation. Product support can change faster than the protocol specification, so implementation teams should verify host-specific documentation before deployment.
Continue with architecture, security and prompt-injection threat modeling.