MCP Explained: What It Connects, What It Does Not Do and Where It Fits

The Model Context Protocol (MCP) is an open protocol for connecting AI applications to external capabilities and information through standardized client-server contracts. An MCP server can expose tools, resources and prompts; an MCP-compatible host or client discovers and uses those capabilities on behalf of an AI application. MCP does not require the server to run its own language model, and it does not replace the agent runtime, business authorization, tenant isolation, application APIs or domain architecture behind the exposed capabilities.

What MCP really standardizes

Before MCP, every AI application could integrate external systems through its own tool schema, plugin format, authentication convention and connection code. The same service could need different adapters for a desktop AI client, an IDE agent and a custom application.

MCP creates a reusable protocol boundary. The external system exposes capabilities through an MCP server, while compatible AI hosts implement an MCP client. This reduces integration coupling between the AI application and the underlying tool or data provider.

The protocol does not standardize the entire application. It standardizes how capabilities are described, discovered and invoked across that boundary.

The simplest example

Suppose an AI coding application needs access to a local project directory. Without MCP, the application might implement its own filesystem integration directly.

With MCP, a filesystem server can expose capabilities such as listing directories, reading approved files or writing inside an allowed workspace. The AI host connects through an MCP client and presents those capabilities to the model or agent runtime.

The server does not need to understand the user's natural-language request. The host/model decides which capability is useful; the MCP server executes the structured request under its own security rules.

Where the simple example stops

MCP does not define how the host chooses a tool, how an agent plans, how a business workflow is modeled or how a domain object such as an invoice or deployment should behave.

A protocol can make the integration interoperable while the underlying application remains incorrect, insecure or badly designed. A perfectly valid MCP request can still call the wrong business capability.

The central boundary is: MCP standardizes integration semantics, not application truth or business correctness.

The MCP architecture: host, client and server

A host can connect to multiple MCP servers, and one MCP server can front one or several underlying systems. The host remains responsible for integrating MCP results into the broader AI application.

The server can be local to the host, run as a separate process or be remote over a network transport. Hosting topology and model location are independent decisions.

The three core server primitives

Tools: callable capabilities

Tools are structured operations an MCP server makes available to the host. A tool has a name, description and input schema; modern implementations can also provide structured output.

Examples include searching a repository, reading a customer record, creating a ticket, running a build or sending a message. Tools can be read-only or have side effects.

A good MCP tool surface should represent coherent user or agent goals rather than mechanically mirror every internal API endpoint. Operations with different permissions, confirmation requirements or blast radius should usually be separate tools.

Resources: readable context and data

Resources expose data or content that a client can list or read. They fit naturally when the semantic operation is “give me this artifact or information” rather than “perform this action.”

A resource URI is not an authorization grant. The server still owns access control and must verify which principal may read the underlying object.

The 2026-07-28 protocol revision adds cache semantics for list and resource-read responses, including freshness and cache scope, making caching behavior more explicit.

Prompts: reusable templates

MCP prompts let a server publish reusable prompt templates to compatible clients. This can keep domain-specific instructions close to the capability provider.

A prompt supplied by an MCP server does not automatically outrank the host's system or security instructions. The host decides how prompt material enters its context hierarchy.

Protocol-provided prompt content should therefore be treated as capability data with explicit trust semantics, not as unrestricted instruction authority.

Tool or resource?

Where is the AI model?

MCP does not require the model to run on the MCP server. The model can be cloud-hosted, locally hosted, embedded in the desktop application or reached through another provider.

The host normally owns the model interaction. The MCP server exposes external capability. A local MCP server can therefore be used by a host whose model runs in the cloud, and a remote MCP server can be used by a host whose model runs locally.

If the MCP server itself calls an LLM internally, that model is part of the server's implementation behind the protocol boundary; it is not required by MCP.

MCP does not replace APIs

An MCP server often wraps existing APIs or services. REST, GraphQL, SQL, SDK calls and internal service contracts can remain exactly where they are.

MCP adds an AI-facing interoperability layer. The underlying domain API can remain the authoritative application contract for ordinary deterministic clients.

The usual architecture is therefore API/service first, selected AI-facing capability second — not “replace every API with MCP.”

MCP vs function calling

OpenAI currently exposes remote MCP servers as one tool type alongside ordinary function calling, web search, shell and other tools. That implementation illustrates the architectural relationship: MCP connectivity and the model's own tool-call interface can be composed.

MCP does not create the agent loop

An AI agent needs a runtime that can decide, invoke tools, observe results, update state and continue or stop. MCP can supply some of the tools and data used by that loop.

The MCP server does not automatically become the planner, memory system or orchestrator. Those responsibilities normally remain in the host or agent runtime.

A non-agentic application can also use MCP. One deterministic MCP tool call does not require an autonomous multi-step agent.

MCP vs A2A

MCP primarily connects an AI host or agent to capabilities such as tools, resources and data. A2A targets collaboration between independent agent systems.

A remote agent can internally use MCP to reach databases and tools while exposing an A2A interface to other agents. The protocols can therefore be layered rather than substituted.

The existing protocol-stack article owns the broader MCP/A2A/UCP/AP2/A2UI comparison; G02 remains the canonical MCP definition.

Local and remote MCP use different transport realities

MCP can connect to local and remote servers. Local desktop integrations commonly use process-level transports such as stdio; remote servers use HTTP-oriented transport.

The 2026-07-28 revision makes the protocol core stateless. Requests carry the information needed for protocol handling instead of depending on the earlier protocol-level session model.

The current revision also places method and capability names in HTTP headers so gateways, WAFs, rate limiters and load balancers can route and meter MCP traffic more naturally.

Why MCP version awareness matters

SDK version and protocol version are also different things. The current TypeScript v2 SDK is the stable line for the 2026-07-28 revision, while older v1.x remains a maintenance line for 2025-era behavior.

Architecture documentation should record both the SDK/library version and the protocol revision where interoperability behavior depends on them.

What changed in MCP 2026-07-28

Roots, sampling and logging are no longer the direction for new implementations

The 2026-07-28 release marks roots, sampling and logging as deprecated protocol capabilities with a defined compatibility window.

Older tutorials may still show these features as central primitives. New implementation work should follow the current specification rather than copy older lifecycle diagrams blindly.

Deprecation does not mean immediate removal. It means new systems should avoid unnecessary new dependencies on capabilities the protocol is moving away from.

Long-running work is not the same as ordinary MCP tool invocation

Long-running operations need lifecycle semantics beyond a simple immediate tool result. In the current ecosystem, Tasks moved into a dedicated MCP extension.

This reinforces a useful design principle: the base protocol does not need to absorb every agent-runtime concern.

An application can also keep long-running workflow ownership entirely in its own runtime and use ordinary MCP tools as underlying operations.

MCP Apps extend UI capability without redefining the core protocol

MCP Apps associate richer interactive UI experiences with MCP tools through the extension model.

The host still controls how that UI is embedded, sandboxed and secured.

Core capability exchange and UI rendering should therefore remain separate architecture responsibilities.

MCP authorization is not your complete authorization model

Remote MCP needs protocol-level authentication and authorization mechanisms so clients and servers can establish trusted access. The current specification continues to harden OAuth/OIDC-related behavior.

That layer answers whether a client is allowed to connect or request protocol scopes. It does not automatically answer whether Alice may refund order 123, whether an agent may write production configuration or whether Tenant A may read Tenant B data.

Those domain decisions belong in the server/application authorization model and must be enforced before invoking the underlying operation.

Identity can cross several boundaries

An MCP request may involve the MCP client application, the signed-in human, an agent/session identity and a downstream service account.

The server needs an explicit policy for which principal the operation is performed on behalf of. Otherwise a powerful service credential can become a confused-deputy path.

For enterprise use, correlation between user identity, agent identity, MCP connection and downstream authorization is as important as protocol compatibility.

Tenant isolation remains outside MCP capability discovery

A multi-tenant MCP server must apply tenant scope when it reads or changes tenant-owned resources. Returning a tool named search_documents does not define which tenant's documents are eligible.

Tenant scope should be derived from trusted identity or membership and carried into databases, caches, vector search, object storage and downstream APIs.

Retrieving cross-tenant content and asking the model not to use it is already an isolation failure.

MCP does not define Source of Truth

An MCP server can expose a database, document repository, web search service or AI-generated summary. The protocol does not declare which source is authoritative for a claim.

Source-of-Truth rules belong to application/domain architecture. The host or server can encode authority through tool design, metadata, access policy or validation, but MCP itself does not make one capability “true.”

A tool can therefore be perfectly callable through MCP and still return stale, secondary or non-authoritative information.

MCP and context engineering

MCP can increase the capabilities and information available to an AI application, but context engineering still determines what reaches the model.

Tool catalogs consume model-visible context in many hosts. Tool results can be large. Resources can be numerous. A host needs selection, filtering, dynamic loading and compaction rather than exposing everything on every turn.

Capability availability and model-visible context should therefore be treated as separate layers.

Design MCP tools around outcomes and risk boundaries

Approvals belong in the execution architecture

A host can require user approval before invoking selected MCP tools. OpenAI's current MCP integration supports automatic or explicit-approval execution patterns.

Host approval is useful but should not be the server's only protection because another compatible MCP client may use a different approval model.

For destructive or financially consequential actions, use defense in depth: clear tool contract, runtime approval where appropriate, server-side authorization, business validation and audit.

MCP observability should connect protocol calls to domain actions

An MCP trace is most useful when it can be correlated with the underlying application call, database change or business transaction.

The 2026-07-28 ecosystem standardizes W3C Trace Context propagation conventions, making it easier to follow a request across host, client, server and downstream services.

Protocol logs alone are not enough for consequential operations. Audit evidence should also record relevant principal, tenant, target resource, approval and resulting state change.

What MCP cannot fix

Original implementation evidence: Aaasaasa AI Client

The application can run an authenticated Streamable HTTP MCP endpoint on loopback. The endpoint exposes only directories selected through the central workspace permission broker.

The local endpoint and remote route are separate concerns: the local connector can bind only to loopback, while a Secure MCP Tunnel can make the approved MCP service reachable to a permitted external AI client without exposing the whole local machine.

The central permission model distinguishes chat-only, read-only, project-write and custom-directory profiles. Direct Chat has no filesystem or shell access; tool-capable agent runtimes use the selected permission profile.

This is a direct implementation of the G02 boundary: MCP provides the standardized capability connection, while the application-owned permission broker decides which directories the server may expose.

When MCP is a good fit

When you do not need MCP

Do not add MCP merely because the application uses AI. If your backend already calls one internal API and no independent MCP client needs that capability, an ordinary function or service call may be clearer.

MCP adds value at an interoperability boundary. Without that boundary, the protocol can become an unnecessary adapter layer.

The architectural question is not “Does this project have AI?” but “Do independently evolving AI hosts and capability providers benefit from a standard contract?”

MCP security checklist

Common misconceptions

A practical MCP design sequence

MCP architecture checklist

Edge cases and limitations

A local stdio MCP server can have little network exposure while still be dangerous if the process itself has excessive filesystem or shell permissions.

A remote MCP server may expose only public documentation or highly sensitive enterprise actions. “Remote MCP” says little about risk without the capability and authorization context.

Some servers may use only tools and ignore resources/prompts. MCP compatibility does not require every optional primitive to be equally important.

A host can translate between its own internal tool model and MCP. Users may never see the protocol boundary directly, which is acceptable if security and attribution remain clear.

MCP continues to evolve rapidly. Extensions, authorization patterns, SDK APIs and ecosystem conventions can change faster than the core architectural distinction.

What would change this answer?

Future MCP revisions can change lifecycle, transports, authorization and extension mechanisms. The July 2026 revision already demonstrates why implementation-specific claims must be dated.

The canonical boundary would change only if MCP expanded from an interoperability protocol into an end-to-end application/agent architecture standard. That is not what the current protocol defines.

For implementation work, always check the current specification and exact SDK line instead of copying version-sensitive examples from older tutorials.

Related canonical knowledge

MCP belongs downstream of Agentic AI: first understand the agent/runtime/tool boundary, then use MCP when external capabilities need a portable protocol contract.

MCP also depends on RBAC and tenant isolation because protocol-level capability exposure does not determine application authorization.

The broader protocol-stack article explains where MCP sits beside A2A, UCP, AP2 and A2UI. G02 remains the canonical source for MCP itself.

Frequently asked questions

Glossary

Conclusion

MCP is easiest to understand when its boundary stays narrow: it connects AI applications to external capabilities through a standard protocol.

The model does not have to live on the MCP server. The server does not become the agent runtime. A listed tool does not become an authorized business action. And MCP does not replace the underlying API, Source of Truth, tenant isolation or domain architecture.

That narrowness is the protocol's strength. MCP can standardize how AI systems reach tools and data while leaving application ownership, security, business semantics and model choice in the layers that actually own them.

Primary sources and current documentation

MCP is evolving quickly, so version-sensitive claims in this article are tied to the 8 October 2026 state. The Aaasaasa AI Client section is original implementation evidence and is explicitly limited to the verified MCP connector and permission-broker scope.