Model Context Protocol (MCP): Architecture, Tools & Python

Reviewed by Ethan Hayes – AI Tools Editor

Model Context Protocol (MCP) is an open protocol for connecting AI applications to external tools, data, and reusable prompt workflows through a consistent client-server interface. For new deployments, the important implementation choice is no longer “MCP or custom API?” but which MCP primitive belongs to the job, which transport fits the deployment, and where hard security controls must sit outside the model.

MCP began at Anthropic, but it is no longer best described as a vendor-specific Claude integration. The project was donated to the Agentic AI Foundation under the Linux Foundation, while protocol development continues through the MCP maintainer and SEP process. That matters when you are deciding whether an integration layer is durable enough to sit between an AI host and internal systems.

What MCP standardizes – and what it does not

MCP standardizes how an AI host discovers and invokes capabilities exposed by a server. It does not replace your database, business API, authorization server, network policy, approval workflow, or application-specific rules. A well-designed MCP server is an adapter layer: it presents the right capabilities to an AI application while keeping the real system of record and enforcement mechanisms behind it.

If the larger question is how this differs from an autonomous workflow, the useful distinction is that MCP is an interoperability protocol, not an agent architecture. The surrounding host may be a chat application, an IDE, an agentic AI system, or a conventional app that happens to use a model.

Host, client, and server architecture

The mental model is straightforward: the host is the user-facing AI application; the client is the protocol-speaking component that connects to one MCP server; the server exposes a bounded set of capabilities. The connection still uses JSON-RPC 2.0 messages, but the modern 2026-07-28 revision changed the lifecycle substantially: each modern request carries the information needed to process that request instead of depending on a protocol-level session.

The optional server/discover call lets a modern client learn server capabilities up front. The Python SDK also supports automatic fallback to older handshake-era servers, so a client can probe the current protocol and fall back when it encounters a pre-2026 implementation.

The three MCP primitives: Tools, Resources, and Prompts

These primitives are easy to confuse because all three can eventually influence what a model sees or does. The control boundary is the useful way to separate them.

• Tools – model-controlled actions: callable functions the model may invoke. A tool can read, compute, create, update, send, delete, or call another system, so the input schema and side effects matter.
• Resources – application-controlled context: URI-addressable data the application reads and can place into model context. A resource is the better fit when the job is “give the host this data,” not “let the model perform an operation.”
• Prompts – user-controlled templates: reusable prompt definitions the application can present for a person to select and parameterize. They are useful for standardized workflows without pretending the template itself is an executable business action.

A common design error is exposing every read as a tool because tool calling is familiar. If a client simply needs a document, configuration record, schema, or catalog as context, a resource usually expresses that job more cleanly. Conversely, do not hide a state-changing operation behind a resource-shaped abstraction; the host needs a clear action boundary to apply approvals and risk controls.

Choose the transport from the deployment model

The source article’s old “stdio or SSE” rule is now outdated. The current Python SDK documentation recommends stdio for local subprocess servers and Streamable HTTP for deployed servers; the legacy HTTP+SSE transport remains for compatibility but is deprecated for new implementations.

One subtle point: “stateless protocol” does not mean your application can never keep state. It means modern MCP no longer hides essential protocol state in a transport session. If a workflow needs application state across calls, make that state explicit – for example, by returning an application handle that can be passed back on a later request.

What changed in MCP 2026-07-28

The July 2026 revision is the architectural break that older MCP explainers often miss. It removed the modern requirement for an initialize/initialized handshake and the Mcp-Session-Id header, added header-based routing fields for HTTP requests, introduced cache hints for list/read results, and changed server-to-client interaction patterns around a stateless request model.

• No protocol-level sessions on the modern path: modern requests carry their protocol version and request metadata with the request.
• Optional discovery: server/discover can return the server’s capabilities without opening a session.
• Header-based routing: Streamable HTTP requests expose method/name routing information so gateways do not need to inspect JSON bodies just to classify operations.
• Multi Round-Trip Requests (MRTR): when a server needs user/client input during a request, it can return an input-required result and let the client retry with the answers.
• Cache hints: list and resource-read results can tell clients how long the information is fresh and whether it is private or publicly cacheable.
• Extensions: capabilities such as long-running Tasks can evolve outside the core protocol.

This shift matters operationally. A deployed MCP service can fit ordinary load-balanced HTTP infrastructure more naturally because a modern request can be routed to an available server instance without relying on hidden protocol session state. For teams already thinking about single-agent vs multi-agent systems, that makes the protocol layer easier to scale independently of whatever orchestration model sits above it.

Before you build: choose the MCP shape

The fastest way to avoid architecture drift is to decide the primitive, transport, and trust boundary before writing decorators. Use the interactive studio below to map a use case to the smallest sensible MCP shape; it does not generate a safety “score” or pretend a complex authorization decision can be reduced to one number.

Python implementation with the current MCP SDK

The source version used FastMCP, which was the v1 high-level class. In the stable v2 Python SDK, that class was renamed to MCPServer. The decorator pattern remains familiar: register a tool, a resource, and a prompt, then choose the transport when starting the server.

from mcp.server import MCPServer

mcp = MCPServer("Customer Operations")


@mcp.resource("policy://customer-status")
def customer_status_policy() -> dict[str, object]:
    """Application-readable policy context."""
    return {
        "allowed_fields": ["status", "tier"],
        "write_access": False,
        "environment": "production",
    }


@mcp.tool()
def lookup_customer_status(customer_id: str) -> dict[str, str]:
    """Return a limited customer status record."""
    if not customer_id.startswith("CUST-"):
        raise ValueError("customer_id must start with CUST-")

    # Replace this example with a real downstream service call.
    return {
        "customer_id": customer_id,
        "status": "active",
        "tier": "enterprise",
    }


@mcp.prompt()
def investigate_customer(customer_id: str) -> str:
    """Reusable, user-selected investigation template."""
    return (
        f"Review customer {customer_id}. "
        "Use only approved status fields and explain uncertainty."
    )


if __name__ == "__main__":
    mcp.run(transport="streamable-http", json_response=True)

For a local server launched by the host, the final line can simply be mcp.run(), which uses stdio by default. For a deployed service, the SDK’s Streamable HTTP path is the normal starting point. The official MCP Python SDK documentation should be treated as the implementation reference because the protocol and SDK have changed quickly enough that many 2024-2025 tutorials now mix eras.

Security: treat MCP as an integration boundary, not a trust shortcut

MCP can make integrations consistent without making them safe automatically. The server may expose actions with real side effects, and tool output may contain untrusted content from email, the public web, documents, tickets, or third-party APIs. The host should separate “the model can see this capability” from “the user has authorized this effect.”

• Use least-privilege credentials: the MCP server should hold only the permissions required for its narrow capability.
• Keep destructive actions explicit: deletions, sends, payments, publishes, permission changes, and other hard-to-reverse operations deserve a deliberate approval path.
• Validate authentication and audience: a remote server should accept credentials intended for that server and follow the current MCP authorization requirements rather than passing upstream tokens through indiscriminately.
• Treat external content as untrusted: data returned by an open-world tool can carry hostile instructions even when the tool itself is legitimate.
• Use infrastructure controls for guarantees: sandboxing, network policy, authorization, allowlists, transaction rules, and audit systems are stronger controls than natural-language instructions.

MCP tool annotations can help a host reason about whether a tool is read-only, destructive, idempotent, or open-world, but the specification treats those annotations as hints. A trusted interface can use them to improve confirmation UX; it should not treat a server’s self-description as a substitute for authorization or network enforcement.

MCP vs a traditional REST API

A REST API exposes application endpoints. MCP exposes a model-oriented capability surface with standardized discovery, schemas, resources, prompts, and tool invocation behavior. The two are not competitors in the usual sense: an MCP server frequently wraps one or more ordinary APIs, databases, queues, or services and presents only the subset an AI host should access.

When MCP is a good fit

MCP earns its complexity when several AI hosts or agent workflows need the same governed capability surface, or when you want to separate model-facing integration logic from the host itself. It is especially useful when you want one bounded server to expose a consistent set of tools/resources/prompts to more than one compliant client.

It is less compelling when one application makes one internal function call and there is no realistic need for protocol portability, capability discovery, or client interoperability. In that case, a direct function or ordinary API call may remain simpler. That is the same architectural discipline behind the broader AI agent vs automation decision: use the extra abstraction only when the job benefits from it.

Implementation checklist

• Define the smallest domain the server should own.
• Classify each capability as a Tool, Resource, Prompt, or extension rather than exposing everything as a tool.
• Choose stdio for host-launched local processes or Streamable HTTP for deployed servers.
• Target the current 2026-07-28 behavior unless compatibility requirements force an older protocol path.
• Design authorization, confirmation, network restrictions, and audit outside the language model.
• Test failure modes: invalid input, denied permission, downstream timeout, partial output, cancellation, and retry behavior.
• Version your server behavior and monitor the MCP changelog because extensions and deprecations are still evolving.

If your next step is workflow automation rather than protocol design, compare how orchestration products model actions and control flow in n8n vs Make AI nodes. MCP can become one of the integration surfaces those higher-level workflows call, but it does not replace the workflow logic itself.

Frequently Asked Questions

Sources and implementation references

For protocol behavior, use the official MCP 2026-07-28 specification and its release summary. For Python code, use the current Python SDK documentation. For governance history, see the MCP project’s Agentic AI Foundation announcement.