📋 Executive Summary
Model Context Protocol is an open standard that lets AI applications discover and use external tools, resources, and prompts, and its July 28, 2026 revision has just removed protocol-level sessions to make those connections easier to scale. That combination is the sharpest answer to what is model context protocol: MCP is not another model or agent framework, but a shared interface between an AI host and the systems it needs to read or operate.
I see the importance in the integration problem it replaces. Before MCP, a team connecting an assistant to GitHub, a database, a document store, and an internal service usually wrote a separate adapter for each product and often another adapter for each AI client. MCP creates one discoverable contract. A server describes available capabilities, a client presents the relevant capabilities to a model, and the host controls permissions, identity, user experience, and the conversation loop.
The standard has moved quickly. Anthropic introduced it in November 2024, donated it to the Linux Foundation’s Agentic AI Foundation in December 2025, and reported more than 10,000 active public servers plus 97 million monthly downloads across the Python and TypeScript SDKs. Adoption now spans Claude, ChatGPT, Gemini, Microsoft Copilot, Visual Studio Code, Cursor, cloud platforms, and specialist enterprise products. Those figures describe momentum, not maturity. The newest specification still leaves implementation teams responsible for secure identity, timeouts, logging, data minimisation, approvals, and recovery.
This guide explains the protocol from the wire format to the business case. It maps the host-client-server architecture, the 2026 stateless change, core primitives, implementation steps, current commercial costs, performance bottlenecks, security threats, and the situations where a conventional REST integration remains the better engineering decision.
What Is Model Context Protocol?
MCP standardises the conversation between an AI application and an external capability provider. The AI application is the host. Inside that host, one or more MCP clients connect to MCP servers. A server can represent a local file system, a SaaS product, a database, a code repository, a search service, a newsroom archive, or an internal business workflow. The protocol tells both sides how to describe capabilities, exchange requests, return structured results, report errors, and negotiate optional features.
The easiest analogy is USB-C for AI, but the analogy has limits. USB-C specifies a physical and electrical interface. MCP is a software protocol built on JSON-RPC 2.0 and transported through standard input/output for local processes or Streamable HTTP for remote services. It does not guarantee that a tool is safe, that two vendors interpret a description identically, or that a model will select the right action. It standardises the connection surface, not the intelligence or governance around it.
This distinction matters when teams evaluate an AI agent and its operating loop. An agent decides or recommends what to do next. MCP supplies a consistent way to discover and invoke the external capabilities that make those decisions useful. An agent can exist without MCP by calling hard-coded functions. An MCP client can also exist inside a non-agentic chat application that only reads resources. The concepts overlap, but they are not interchangeable.
MCP is also not a replacement for an underlying API. A Salesforce, GitHub, PostgreSQL, or Reuters MCP server still calls product APIs, queries a database, or accesses licensed content behind the scenes. The server translates that existing interface into model-readable tools, resources, and prompts. The integration advantage appears when several compatible hosts can use the same server without each host learning the underlying product’s bespoke contract.
The 2026 specification defines an authoritative protocol version, capability metadata, request and result schemas, two standard transports, discovery, cache hints, authorisation requirements, and extensibility. It remains intentionally narrower than a complete agent platform. Memory, planning, model choice, user identity, business policy, audit retention, and workflow state still belong to the host or surrounding infrastructure.
Why MCP Became Shared Agent Infrastructure
MCP emerged because tool integration was becoming the least reusable part of AI application development. Models improved quickly, but every assistant still needed custom wrappers around calendars, repositories, databases, ticketing systems, and knowledge stores. Those wrappers duplicated authentication code, schemas, error handling, and documentation. Worse, they aged independently, so a vendor API change could break several agent products in different ways.
Anthropic’s December 2025 donation announcement reported more than 10,000 active public MCP servers, support across major AI products, over 75 MCP-powered Claude connectors, and 97 million monthly SDK downloads across Python and TypeScript. The Linux Foundation structure also reduced the strategic risk of one model vendor owning the interface. OpenAI and Block joined Anthropic as founding contributors to the Agentic AI Foundation, with Google, Microsoft, AWS, Cloudflare, and Bloomberg listed as supporters.
The protocol’s appeal is especially clear in coding. A developer assistant may need repository search, issue management, deployment logs, cloud consoles, documentation, and databases in the same session. GitHub described MCP as a way to equip Copilot agent mode with the wider engineering stack. The publication’s developer test of coding agents reaches the same practical conclusion: tool access matters only when selection, permissions, and failure recovery remain controlled.
Adoption is now extending beyond developer tools. Reuters launched an MCP server in July 2026 so licensed customers can let agents search, retrieve, and download subscribed journalism. Alphonse Hardel, Head of Reuters News Agency, said demand is shifting towards ‘AI-native ways’ to access content. The significance is not the quote alone. It shows MCP being used as a commercial distribution interface, not merely an open-source convenience for local experiments.
Still, adoption statistics can overstate interoperability. A public server may be experimental, abandoned, insecure, or tied to an older protocol revision. Client support varies by transport and feature. Some products support remote tools but not every client feature, while others expose MCP through a managed connector rather than a general client. A production team therefore needs a compatibility matrix, version pinning, provenance review, and regression tests. Open standards lower integration cost, but they do not remove integration work.
The Host, Client, and Server Architecture
The architecture separates responsibilities that custom agent code often mixes together. The host owns the user experience and model conversation. An MCP client handles protocol communication for one server connection. The MCP server publishes capabilities and performs the underlying work. This separation makes it possible to replace a model, server, or transport without rewriting the entire application, provided the surrounding implementation respects the same protocol version.
A desktop assistant can launch a local server as a child process and communicate through standard input/output. A cloud agent can connect to a remote server through Streamable HTTP. In both cases, the data layer uses JSON-RPC 2.0 messages. The 2026 revision carries protocol version, client identity, and relevant capabilities in each request’s metadata, rather than depending on a connection-level handshake.
When teams build an agent with Claude, the host is not simply Claude the model. The host includes the application, client implementation, model request loop, approval interface, credential store, and policy controls. The model sees tool definitions and decides which capability appears useful, but the host must decide whether the call is permitted, whether the user must approve it, and how much of the result should return to the model.
The table below shows the complete responsibility split for a basic deployment.
| Component | Primary Responsibility | What It Must Not Assume |
| Host | User interface, model loop, policy, consent, credentials, traces, and application state. | That a server or model is safe merely because it is compatible. |
| MCP Client | Discovery, transport, message exchange, protocol metadata, and result handling for one server. | That every server supports every optional feature or protocol revision. |
| MCP Server | Capability definitions, authentication checks, business validation, downstream access, and typed results. | That model-generated arguments are authorised, correct, or safe. |
| Model | Interprets the request, selects tools, supplies arguments, and synthesises a response. | That it owns credentials, permissions, transaction truth, or final approval. |
| Underlying System | Remains the source of record and enforces domain rules, data access, and transactions. | That MCP replaces its API, database controls, or audit obligations. |
Core Primitives: Tools, Resources, and Prompts
MCP’s three server primitives describe different kinds of context. Tools are callable operations. Resources are readable content identified by a URI. Prompts are reusable message templates or workflows that a user or client can select. Treating them as interchangeable usually produces poor interfaces.
A tool should represent an action or computation with a clearly typed input schema and, where possible, an output schema. Examples include searching a repository, creating an issue, calculating a forecast, or updating a customer record. The 2026 tool specification supports text, images, audio, resource links, embedded resources, and structured content in results. Tools may be model-controlled, but the specification says applications should show what tools are exposed, indicate when a tool is invoked, and preserve human denial or confirmation for consequential operations.
A resource is better for material the model may read without implying an action: a policy document, schema description, file, record, or generated report. Resources can support templates and change notifications. A prompt packages a repeatable interaction pattern, such as reviewing code against an organisation’s standards or preparing a customer escalation summary. Prompts improve discoverability and consistency, but they are not privileged instructions. A host must still decide how prompt content enters its instruction hierarchy.
The distinction becomes useful in practical prompt engineering workflows. A prompt can guide how the model approaches a task, a resource can supply the evidence, and a tool can perform the approved action. Combining all three into one broad tool may feel simpler initially, but it weakens permissions, observability, caching, and testing.
The 2026 specification also adds cache controls to list and read operations. Results include a freshness hint in milliseconds and a public or private cache scope. Deterministic ordering of tool lists is recommended because stable ordering improves client-side caching and model prompt-cache hit rates. This is a subtle but important design point: protocol metadata can directly affect token cost and latency even though MCP itself does not charge a fee.
| Primitive | Best Use | Typical Controls | Common Design Error |
| Tools | Actions, searches, calculations, and transactions. | Typed inputs, scopes, approvals, timeouts, and idempotency. | A broad tool with unrestricted read, write, and command access. |
| Resources | Documents, records, files, schemas, and reports. | URI rules, access checks, cache scope, limits, and redaction. | Returning a sensitive dataset when a bounded slice is enough. |
| Prompts | Reusable task patterns and guided interactions. | Versioning, ownership, instruction boundaries, and review. | Treating a server prompt as a privileged system instruction. |
| Extensions | Optional features such as Tasks and MCP Apps. | Negotiation, version tests, and graceful fallback. | Assuming support from a generic MCP compatibility claim. |
The July 2026 Stateless Shift
The most important technical change in the July 28, 2026 release is the move to a stateless protocol core. Earlier Streamable HTTP deployments established a session, received an MCP session identifier, and sent that identifier with later requests. That design complicated horizontal scaling because gateways often needed sticky routing or a shared session store. The new revision removes the initialise handshake and protocol-level session header.
Each request now carries the protocol version and relevant client metadata. Servers implement a mandatory server discovery method that advertises supported versions, identity, and capabilities. A remote request can be handled by any compatible server instance behind an ordinary round-robin load balancer. Applications may still maintain state, but they must represent it explicitly through server-minted handles or normal tool arguments rather than relying on hidden transport sessions.
David Soria Parra, MCP co-inventor and core maintainer, called the release ‘a robust foundation for MCP’s future’. The wording is restrained compared with the architectural impact. Statelessness improves routing and failure isolation, but it also relocates responsibility. Identity, authorisation context, trace metadata, idempotency, and application state must survive each request independently.
The new design introduces an MCP method header and name header for HTTP requests, allowing gateways to route or observe traffic without parsing the full JSON body. List and read results carry time-to-live and cache-scope metadata. OpenTelemetry trace context conventions can travel in request metadata. Together, these changes make MCP look more like conventional web infrastructure, which is exactly what enterprise operators wanted.
There are breaking changes. Protocol-level roots, sampling, and logging are deprecated, while long-running Tasks and MCP Apps live in the extensions framework. The old HTTP plus SSE transport had already been deprecated and should move to Streamable HTTP. Teams upgrading from the November 2025 specification should not assume a client library update is enough. They need contract tests for discovery, headers, result types, cache behaviour, authorisation, retries, and any workflow that previously depended on a persistent session.
How an MCP Request Works End to End
A production request has more stages than the simple diagram normally shows. Understanding those stages helps engineers place policy checks and diagnose failures.
First, the host resolves a configured server and decides whether it is local or remote. For a remote server, the client may call server discovery to confirm protocol versions and capabilities. It then authenticates using the server’s required method. Streamable HTTP supports familiar web credentials, and MCP recommends OAuth for obtaining tokens. The client must bind credentials to the correct issuer and validate authorisation responses rather than treating any bearer token as portable.
Second, the client lists permitted tools, resources, or prompts. A server may return a different tool set based on the caller’s scopes, but the set must not vary merely because a connection changed. The host filters this list again according to product policy. OpenAI’s Responses API, for example, can import remote MCP tools and supports tool filtering plus approval flows. It charges no separate MCP call fee, but imported definitions and tool-call content consume model tokens.
Third, the host places relevant definitions into the model context. The model selects a tool and produces structured arguments. The host validates the arguments, checks the action class, and requests user approval when required. This is the control point that a ChatGPT agent implementation guide should treat as a security boundary, not a cosmetic confirmation screen.
Fourth, the client sends the JSON-RPC request. The server validates identity, schema, business rules, and rate limits before calling its underlying API or data source. It returns structured content, a typed error, a completed result, or an input-required result for a multi-round-trip interaction. The host then decides how much of that result is safe and useful to include in the next model turn.
Finally, the system records the trace. A useful trace links the user request, model decision, tool version, input hash, approval, server identity, downstream API call, result classification, token usage, latency, and final answer. Without this chain, teams can see that an answer was wrong but not whether the fault came from the model, schema, server, credential scope, source data, or tool description.
Building a Minimal MCP Server
The official Python SDK uses FastMCP to generate protocol definitions from Python type hints and docstrings. The minimal server below exposes one read-only tool, returns a typed dictionary, runs through Streamable HTTP, and enables stateless JSON responses. It is deliberately narrow because a small, well-described tool surface is easier for a model to select and easier for a security team to review.
Install the official SDK with a pinned major version, then create the server. The SDK transition around the July 2026 specification makes version pinning especially important. Verify the current stable release before production deployment rather than copying an unbounded dependency from an old tutorial.
from mcp.server.fastmcp import FastMCP
from pydantic import BaseModel, Field
mcp = FastMCP(
“Policy Search”,
stateless_http=True,
json_response=True,
)
class PolicyHit(BaseModel):
title: str
section: str
summary: str = Field(max_length=600)
@mcp.tool()
def search_policy(query: str, limit: int = 5) -> list[PolicyHit]:
“””Search approved policy text. Read-only. Never returns secrets.”””
safe_limit = max(1, min(limit, 10))
return approved_index.search(query=query, limit=safe_limit)
if __name__ == “__main__”:
mcp.run(transport=”streamable-http”)
A production version needs more than the decorator. Add server-side input validation even though the SDK generates JSON Schema. Authenticate every remote request. Resolve the authenticated subject to explicit scopes. Enforce row-level or tenant-level access at the data layer. Bound response size. Remove secrets and internal instructions from errors. Emit structured logs and trace context. Add timeouts, circuit breakers, and idempotency for write operations.
The step-by-step workflow is: define one user outcome; classify each operation as read, write, destructive, or privileged; choose tools, resources, and prompts deliberately; model the smallest useful schemas; implement authentication and authorisation; add approval metadata; test through the MCP Inspector and real target clients; simulate malformed inputs and downstream failures; load-test discovery and tool calls; pin protocol and SDK versions; then publish through a governed registry or internal catalogue.
When teams build an agent with Perplexity, or any other research-oriented host, the same principle applies: keep source retrieval separate from consequential actions. A search tool may return evidence, while a publish or send tool should require a different permission and explicit confirmation. The protocol makes both tools discoverable, but only the host and server can enforce the difference.
One implementation constraint deserves emphasis. The server’s docstrings and tool descriptions are operational inputs to the model. They should be reviewed like code and system prompts. A vague description lowers selection accuracy. An overlong description increases context cost. An imperative or compromised description can redirect the model. Good MCP engineering therefore joins API design, prompt design, security review, and observability rather than treating them as separate disciplines.
What MCP Costs in Practice
MCP is an open standard with no protocol licence fee and no per-call charge from the specification project. The real cost sits in the layers around it: the model that reads tool definitions and results, the client product, the server runtime, the underlying SaaS or data API, authentication infrastructure, logs, security review, and human approval time.
OpenAI states that its Responses API adds no separate fee for an MCP tool call. Customers pay for tokens used to import tool definitions and perform model turns. Anthropic prices model input and output separately, with prompt caching rates that can materially change a tool-heavy workload. GitHub Copilot bundles agent use into subscription and credit systems. Those commercial models are not directly comparable because one is API consumption, one combines applications and API access, and one packages coding features with monthly AI credits.
The table captures publicly confirmed prices relevant to common MCP deployments as of July 29, 2026. It does not estimate server hosting or third-party API charges, because those depend on workload and provider.
| Layer or Product | Current Price | Confirmed Limit or Cap | MCP Cost Note |
| MCP Specification and SDKs | $0 licence fee | No protocol usage cap | Hosting, security, and downstream services remain chargeable. |
| Claude Free | $0 | Limited, dynamic usage | Useful for testing supported clients; exact message cap is not guaranteed. |
| Claude Pro | $20 monthly or $200 yearly | Standard capacity; five-hour session resets | Usage credits can continue work at API rates after included limits. |
| Claude Max 5x | $100 monthly | Five times Pro capacity per session | Additional usage credits may add variable spend. |
| Claude Max 20x | $200 monthly | Twenty times Pro capacity per session | Additional usage credits may add variable spend. |
| Claude API Sonnet 5 | $2 input and $10 output per million tokens through Aug 31, 2026 | Rate limits vary by account tier | Tool definitions and results are model input; standard price becomes $3 and $15. |
| Claude API Opus 5 | $5 input and $25 output per million tokens | Rate limits vary by account tier | Prompt cache reads are priced lower than uncached input. |
| OpenAI Responses API MCP | No extra MCP tool-call fee | Model and account rate limits apply | Definitions, tool inputs, results, and outputs consume billable tokens. |
| OpenAI GPT-5.6 Luna | $2 input, $0.20 cached input, $12 output per million tokens | Account rate limits apply | Representative current MCP-compatible model pricing, not an MCP bundle. |
| GitHub Copilot Free | $0 | 2,000 completions and 50 chat requests monthly | Agent and CLI access is limited. |
| GitHub Copilot Pro | $10 monthly | $15 total monthly AI credits | Chat, agent mode, reviews, CLI, and apps share the credit pool. |
| GitHub Copilot Pro+ | $39 monthly | $70 total monthly AI credits | Includes premium models and more agent usage. |
| GitHub Copilot Max | $100 monthly | $200 total monthly AI credits | Designed for sustained high-volume agent workflows. |
Two hidden limits matter more than headline subscription prices. First, Claude’s paid individual plans still use session limits that reset every five hours. Anthropic allows usage credits after included limits, billed at standard API rates, with a configurable monthly cap and a stated daily redemption limit of $2,000. Exact message counts are dynamic and not publicly guaranteed. Second, GitHub’s credit model covers chat, agent mode, code review, cloud agents, CLI, and apps, so an MCP-heavy coding workflow competes with other Copilot usage for the same pool.
Token overhead is the most overlooked MCP cost. Every visible tool name, description, and schema can enter the model context. A client connected to hundreds of verbose tools may spend substantial input tokens before addressing the user’s task. Anthropic documented a worked example in which code-based progressive disclosure reduced token use from 150,000 to 2,000, a 98.7% reduction. Cloudflare’s Kenton Varda, Sunil Pai, and Ketan Gupta reported that converting an MCP server into a typed TypeScript API ‘can cut token usage by 81%’. These are vendor examples, not universal benchmarks, but they reveal the same bottleneck.
A realistic cost model therefore multiplies requests by four quantities: definition tokens loaded, user and instruction tokens, tool-result tokens returned, and output tokens generated. Add server compute, downstream API charges, retry rates, and approval labour. The cheapest deployment is rarely the one with the lowest model price. It is the one that exposes fewer relevant tools, caches stable discovery results, filters large outputs before the model sees them, and stops failed workflows early.
Security Risks and Required Controls
MCP does not create prompt injection, over-privilege, or supply-chain risk, but it gives those risks a standard route into powerful agents. The main attack surface includes malicious servers, compromised maintainers, poisoned tool descriptions, indirect prompt injection in retrieved content, excessive scopes, confused-deputy behaviour, credential leakage, unsafe write actions, and silent changes to a previously approved tool.
Microsoft’s 2026 security analysis describes tool-description poisoning in a finance workflow. A server keeps the same visible name while adding hidden instructions to its description, causing an agent to retrieve unpaid invoices and include them in an outbound enrichment call. The individual API calls appear legitimate. The failure exists across trust boundaries. Microsoft therefore recommends treating tool descriptions as system prompts and every server as a production supply-chain dependency.
Swetha Kumar, a security assurance engineer in Microsoft’s CISO organisation, warned: ‘Even one misconfigured server can give the AI the keys to your data.’ That risk remains even when the protocol implementation is correct. OpenAI’s MCP documentation similarly warns that a trusted server does not make a cross-tool workflow safe, because malicious instructions can arrive through email, web content, files, or another connector and then trigger a sensitive read or write action.
A secure design starts with least agency, not only least privilege. Give the agent the minimum tools, minimum scopes, minimum data, and minimum autonomy needed for the task. Separate read and write servers or at least separate scopes. Require fresh human confirmation for irreversible actions. Validate tool inputs on the server. Keep secrets outside model-visible context. Bind credentials to issuers. Log tool metadata versions and alert on changes. Maintain an allowlist of publishers and servers. Re-run security review when schemas or descriptions change.
The Microsoft Copilot agent workflow is a useful adjacent example because enterprise controls must span identity, policy, user confirmation, and audit. MCP can centralise the connection pattern, but it cannot decide organisational risk tolerance. High-impact systems should add data-loss prevention, outbound destination controls, content inspection, non-human workload identities, conditional access, anomaly detection, and a kill switch that revokes a server or tool without redeploying every host.
Performance Bottlenecks and Failure Modes
MCP performance problems usually appear in five places: discovery payloads, model selection, server latency, oversized results, and serial tool loops. A server can be fast while the overall agent remains slow because the model spends time reading definitions, reasoning among similar tools, waiting for approvals, and copying large intermediate results through the context window.
Tool count is a context tax. GitHub reported in late 2025 that access to hundreds of MCP tools could make Copilot slower, and its engineering work focused on using fewer tools more intelligently. The July 2026 specification helps through deterministic ordering, cache hints, and a stateless request model, but the host must still filter the catalogue. Progressive discovery, tool search, domain gateways, and task-specific allowlists often outperform exposing the full enterprise estate.
Large results create a second tax. A two-hour transcript, a 10,000-row spreadsheet, or a repository-wide search can overwhelm the context window and invite copying errors. Filter and aggregate close to the data source. Return handles, summaries, counts, or typed slices instead of entire datasets. Where code execution is available, let a sandbox transform data before the model sees it. Never treat the model context as a transport bus for data that can move directly between systems.
Network and downstream failures need explicit semantics. Set separate timeouts for discovery, tool execution, and the overall workflow. Retry only operations known to be idempotent, and assign idempotency keys to writes. Use circuit breakers for failing dependencies. Return structured error classes that distinguish invalid input, unavailable service, permission denial, rate limit, conflict, and unknown failure. A generic error string forces the model to guess whether it should retry, ask the user, or stop.
Observability is another bottleneck because a stateless protocol removes convenient connection-level context. Propagate a trace identifier on every request. Record protocol version, server version, tool schema version, identity, scope, timing, result size, and model token usage. Austin Parker, Honeycomb’s Director of AI Strategy, reported in the MCP release announcement that nearly 20% of monthly interactive queries on Honeycomb were already made by agents. That volume turns tool traces into operational telemetry, not optional debugging data.
MCP Versus APIs, Function Calling, and A2A
MCP is one layer in a larger protocol stack. It complements rather than eliminates REST, function calling, webhooks, and agent-to-agent protocols. The right comparison asks which boundary needs standardisation.
A direct REST or GraphQL integration is often best when one application owns a stable workflow, latency is critical, and engineers need complete control over data movement. Function calling is a model-provider interface for describing callable functions inside a request. MCP can feed tool definitions into that function-calling mechanism, but it adds discovery, transport, resources, prompts, versioning, and a reusable server boundary.
Agent2Agent protocols address a different problem. Google’s Shubham Saboo and Kristopher Overholt describe MCP as a standard connection pattern in which servers advertise tools and agents discover them. Their same 2026 guide positions A2A as the mechanism for remote agents to discover and communicate with one another. MCP connects an agent to capabilities. A2A connects one agentic service to another. A complex system may use both.
The social-media agent buyer test illustrates the decision well: a stable REST API and webhooks can be enough when the workflow is narrow and the host owns every integration. MCP becomes more valuable when several hosts must use the same capability, tool definitions change frequently, or an organisation wants a governed catalogue independent of any one model vendor.
The comparison table summarises the trade-offs.
| Approach | Best Fit | Strength | Main Limitation |
| MCP | Reusable capabilities across several AI hosts. | Discovery, standard schemas, resources, prompts, transports, and vendor neutrality. | Adds governance, compatibility, and context-overhead responsibilities. |
| Direct REST or GraphQL | One application owns a stable workflow. | Low latency, explicit contracts, complete control. | Custom adapter work must be repeated for each host. |
| Native Function Calling | One model API needs a small set of functions. | Simple model integration and provider tooling. | Definitions are usually tied to one request format or provider surface. |
| Webhooks and Events | Systems must notify each other asynchronously. | Efficient event delivery without model polling. | Does not provide model-oriented discovery or tool invocation. |
| A2A | Independent agents need to discover and collaborate. | Agent identity, skills, remote messaging, and task exchange. | Does not replace tool and data access inside each agent. |
Confirmed Integrations and Ecosystem Boundaries
Confirmed MCP adoption spans major model and developer ecosystems. Anthropic supports MCP across Claude products and its API connector. OpenAI supports remote MCP servers and connectors in the Responses API, with approval and filtering controls. GitHub Copilot and Visual Studio Code support MCP tools for agent workflows. Google Agent Development Kit provides MCP toolsets, and Google has described MCP alongside A2A and interface protocols. Microsoft uses MCP across Copilot, Foundry, Visual Studio, Sentinel, and internal governance programmes. Cloudflare supports remote servers, portals, agents, and code-mode patterns. Reuters and Figma demonstrate specialised content and design integrations.
This is not a complete list of every server. No static article can supply one because the public registry and private enterprise catalogues change continuously, and many servers are not publicly discoverable. The responsible approach is to distinguish platform support from server quality. A client displaying an MCP logo does not mean it implements every feature of the July 2026 specification. A registry entry does not certify maintenance, provenance, security, or compatibility.
Enterprise buyers should ask seven questions for each integration: Which protocol versions are supported? Which transports work? Does the client support discovery, approvals, structured output, caching, and the extensions you need? Who operates the server? How are credentials stored and rotated? What data leaves the organisation? What happens when the server changes its schema or tool description?
The Perplexity agent implementation approach provides another useful boundary. A research product may use its own APIs, native search, or proprietary orchestration rather than general MCP for every capability. MCP is valuable where interoperability and governed reuse outweigh the simplicity of a first-party integration. It should not be adopted as a badge or default architecture.
One unique operational insight follows from the new stateless design: version drift can now surface request by request rather than connection by connection. That improves rollout flexibility, but it also means every gateway, client, and server must preserve version metadata consistently. Canary deployments should measure unsupported-version errors, schema failures, and tool-selection changes before a full migration.
Enterprise Deployment Checklist
A production deployment should begin with an inventory, not a server. List the user outcomes, data classifications, systems of record, actions, identities, and approval requirements. Then decide which capabilities deserve an MCP boundary. A tool that only one internal service calls may remain a conventional API. A capability used by several assistants, IDEs, and workflow engines is a stronger candidate.
Design the tool surface around business permissions. Prefer small, typed tools with explicit verbs and bounded arguments. Avoid generic execute-command tools, raw SQL, unrestricted file access, and broad API proxies unless they sit behind a secure sandbox and policy broker. Separate discovery from entitlement. A model may know a tool exists without being authorised to invoke it for the current user.
Build a compatibility suite that runs against each supported host. Test discovery, schema parsing, typed results, authentication, expired tokens, denied scopes, retries, cancellation, large payloads, timeouts, and malformed responses. Include prompt-injection scenarios in which an untrusted resource instructs the model to call another tool. Test tool-description changes as supply-chain events. Verify that approval screens show the actual action and destination, not a vague label.
Operational controls should include a server catalogue, named owner, version pin, software bill of materials, dependency scanning, secret rotation, audit retention, trace correlation, data-loss prevention, rate limits, spend caps, and a rapid revocation path. Monitor selection accuracy as well as uptime. A server that returns 200 responses but causes the model to choose the wrong tool is operationally unhealthy.
Finally, measure whether MCP reduces total integration cost. Track time to add a new host, time to update a tool schema, token overhead, tool success rate, approval abandonment, median and tail latency, retry rate, security findings, and incident recovery. The Claude agent build process and comparable guides are most useful when teams adapt them into measurable controls rather than copying a demo architecture unchanged.
A successful MCP programme produces boring infrastructure: predictable contracts, small blast radiuses, visible approvals, stable traces, and clear ownership. The protocol should disappear into the workflow. When users notice it, the reason should be that a useful new capability became available safely, not that another integration layer failed.
Our Editorial Verification Process
We treated this as a conceptual and technical explainer anchored to the Model Context Protocol specification released on July 28, 2026. We cross-referenced the authoritative specification, changelog, architecture documentation, tool schema, official Python SDK guidance, and release announcement. We checked implementation details against official documentation from OpenAI, Anthropic, GitHub, Google, Microsoft, Cloudflare, and Reuters, then separated protocol facts from vendor-specific product behaviour.
For commercial verification, we reviewed Claude application and API pricing, OpenAI API pricing and MCP billing guidance, and GitHub Copilot plan limits on July 29, 2026. Where vendors publish dynamic rather than fixed usage caps, the article states that limitation instead of inventing a message count. Performance figures are labelled as vendor examples and not presented as universal benchmarks. Security findings were checked against Microsoft threat research and OpenAI’s published MCP safety guidance.
This article was researched and drafted with AI assistance and reviewed by the Awais Khalid editorial desk at Perplexity AI Magazine. All data, citations, pricing figures, and named quotes have been independently verified against primary sources before publication.
Conclusion
Model Context Protocol has moved from an Anthropic integration proposal to shared agent infrastructure in less than two years. Its value is concrete: one server contract can make tools, resources, and prompts available across several compatible AI hosts. The July 2026 stateless revision strengthens the case for production use by fitting ordinary HTTP scaling, caching, routing, and tracing patterns.
The protocol does not make an agent reliable by itself. It can reduce duplicated adapter code while increasing the number of systems an agent can reach. That trade-off makes identity, authorisation, tool design, human approval, supply-chain review, and telemetry more important, not less. The most dangerous deployment is not necessarily a malicious server. It may be a trusted server with a changed description, an over-broad scope, or a result large enough to hide the instruction that redirects the next action.
MCP is therefore best understood as a standardised capability boundary. Use it when interoperability, reuse, and central governance justify that boundary. Keep direct integrations where one application needs the lowest latency and owns the entire contract. Open questions remain around certification, cross-client behavioural consistency, structured recovery, identity propagation, and the operational maturity of public servers. The standard is becoming more web-like, but the systems built on it still need disciplined engineering before they can be trusted to act.
FAQs
What Is Model Context Protocol Used For?
MCP gives AI applications a standard way to discover and use external tools, resources, and prompts. A compatible client can connect to a server without learning every underlying product API. The protocol defines messages, schemas, transports, discovery, capability metadata, results, and errors, while the host remains responsible for the model, user experience, permissions, approvals, and workflow logic.
Is MCP an API?
MCP is a protocol that often sits in front of APIs. An MCP server may call a REST API, query a database, read files, or access a SaaS platform. Unlike one product API, MCP standardises how AI clients discover and invoke many different capabilities. It does not replace the underlying system of record or guarantee that every server exposes identical behaviour.
Is Model Context Protocol Free?
The MCP specification and official open-source SDKs do not charge a protocol licence or per-call fee. Costs come from model tokens, client subscriptions, server hosting, downstream APIs, authentication, logs, security tooling, and human approvals. OpenAI states there is no extra MCP tool-call fee in the Responses API, but tool definitions and results still consume billable tokens.
What Is the Difference Between MCP and Function Calling?
Function calling is usually a model-provider feature that lets a model return structured arguments for declared functions. MCP adds a reusable client-server protocol around capability discovery, transport, resources, prompts, versioning, authorisation, and results. A host can use MCP to obtain tool definitions and then expose them to a model through its native function-calling interface.
Does MCP Replace REST APIs?
No. MCP often wraps REST, GraphQL, database, or proprietary interfaces so AI clients can use them through a common pattern. Direct APIs remain better for narrow, latency-sensitive workflows owned by one application. MCP is stronger when several AI hosts need the same changing capability or an organisation wants a governed integration catalogue.
Is MCP Secure?
MCP can be implemented securely, but it does not make connected tools safe automatically. Major risks include prompt injection, poisoned tool descriptions, excessive permissions, compromised servers, credential leakage, and unintended write actions. Secure deployments use trusted catalogues, issuer-bound authentication, least privilege, least agency, server-side validation, human confirmation, audit logs, and rapid revocation.
What Changed in the July 2026 MCP Specification?
The July 28, 2026 specification removed protocol-level sessions and the initialise handshake, made each request carry version and capability metadata, added mandatory server discovery, introduced cache controls, strengthened authorisation rules, and formalised extensions. It also deprecated older features and the legacy HTTP plus SSE transport, so upgrades require compatibility testing rather than a simple library replacement.
When Should a Business Use MCP?
Use MCP when multiple assistants, IDEs, or agent platforms need controlled access to the same tools and data. It is particularly useful when integrations change often or must remain vendor-neutral. Avoid adding it solely for fashion. A direct integration may be cheaper and faster when one stable application owns the workflow, identity, and downstream API.
References
Model Context Protocol. (2026). Model Context Protocol specification, version 2026-07-28.
Model Context Protocol. (2026, July 28). The 2026-07-28 specification.
OpenAI. (2026). MCP and connectors: Responses API developer guide.
Varda, K., Pai, S., & Gupta, K. (2026, March 24). Sandboxing AI agents, 100x faster. Cloudflare.
