Model Context Protocol (MCP): From First Principles to Production

Version note. This article targets Model Context Protocol specification 2026-07-28, released on July 28, 2026. That revision made the protocol core stateless, removed the mandatory initialize/initialized handshake and protocol-level sessions, introduced optional server/discover, formalized extensions, moved Tasks into an extension, and deprecated Roots, Sampling, Logging, and legacy HTTP+SSE for new designs. Older hosts and SDKs may still use the 2025 lifecycle, so production systems must treat protocol compatibility as an explicit engineering decision rather than assume every MCP implementation behaves identically.

radio_button_uncheckedshort_text1. Introduction: Why AI Needed a Common Integration Language

The history of computing is full of moments when a shared interface mattered more than another isolated feature. Operating systems standardized how programs reach hardware. HTTP gave distributed applications a common language. The Language Server Protocol let editors reuse language intelligence instead of rebuilding it for every editor-and-language pair. By 2024, artificial intelligence had reached a similar point: language models could reason impressively, yet every useful connection to files, databases, source repositories, business applications, and internal APIs still looked like a custom integration project.

Anthropic introduced the open Model Context Protocol, usually shortened to MCP, on November 25, 2024. The proposal was deceptively simple: instead of teaching every AI application a proprietary way to connect to every external system, define a standard boundary through which an AI host can discover context and actions exposed by an MCP server. The launch included a specification, SDKs, local support, and example servers. Adoption then expanded across coding tools, agent platforms, cloud infrastructure, and enterprise products. In December 2025, MCP was contributed to the Agentic AI Foundation under the Linux Foundation, reinforcing the idea that an integration protocol becomes more valuable when it can evolve as neutral ecosystem infrastructure.

Why should that history matter to a developer, architect, or technology leader? Because the expensive part of an AI system is often not the model call. It is the glue around it: describing available operations, retrieving trustworthy context, enforcing identity and permissions, validating arguments, translating errors, recording what happened, and repeating that work for every new AI product. MCP does not remove those responsibilities, but it gives them a stable place to live. A capability can be implemented once behind an MCP server and then offered to multiple compatible hosts.

The social value follows from the same architectural change. A well-governed MCP ecosystem can make useful AI integrations cheaper to build, easier to audit, and more accessible to organizations that cannot maintain dozens of bespoke connectors. A public agency could expose approved information without giving an assistant unrestricted database access. A hospital could offer narrowly scoped scheduling operations while preserving clinical authorization rules. A small company could connect the same inventory service to several assistants without becoming locked into one model vendor. None of these benefits is automatic, but standardization makes responsible reuse possible.

This article builds MCP from first principles and then follows it into production. You will learn what the protocol solves, how hosts, clients, servers, tools, resources, prompts, transports, and extensions fit together, how a model selects a tool, how to build a small Python MCP server, and why security and operations matter more than a successful demo. Keep one question in mind as you read: if an AI agent can discover what your software can do, what is the safest and clearest interface you would want it to see?

radio_button_uncheckedshort_text2. First Principles: The Integration Problem MCP Solves

Imagine five AI applications that need access to ten enterprise systems. Without a shared contract, the conceptual surface can approach fifty relationships. One host expects provider-specific function definitions, another uses a plugin manifest, another has a connector SDK, and a fourth requires a custom orchestration loop. Each relationship may differ in discovery, schemas, authentication, lifecycle, error handling, packaging, and consent. Teams begin by writing one small adapter and eventually inherit an integration matrix.

WITHOUT A SHARED PROTOCOL

AI host A ── custom adapter ── CRM
AI host A ── custom adapter ── Git provider
AI host B ── another adapter ── CRM
AI host B ── another adapter ── Git provider

WITH MCP

AI hosts ── MCP ── CRM MCP server ── CRM API
        └── MCP ── Git MCP server ── Git API

MCP changes the unit of reuse. Instead of primarily asking how AI product A integrates with system X, a team can ask how system X should expose safe, model-usable capabilities through an MCP server. Compatible hosts consume the same protocol surface. The server can continue to call REST APIs, query a database, execute domain services, or read local files underneath; MCP standardizes the AI-facing boundary rather than replacing the systems behind it.

At its core, Model Context Protocol is an open protocol through which AI applications can discover and interact with external capabilities. Those capabilities are not limited to executable functions. MCP distinguishes actions from addressable context and reusable workflows, which is why its three central server primitives are Tools, Resources, and Prompts. This distinction lets a host decide what enters model context, what requires an explicit action, and what should remain a user-selected workflow.

This boundary is powerful precisely because it is limited. MCP is not a model, an agent framework, a database, an API gateway, or an authorization policy. It does not guarantee that a model will select the correct tool, that a community server is trustworthy, or that two hosts expose identical user experiences. The “USB-C for AI” analogy captures reuse, but it can hide the hard part: software interoperability depends on versions, extensions, policy, semantic quality, and implementation discipline.

A productive mental model is therefore: APIs expose capabilities to deterministic software; MCP exposes selected capabilities in a standardized form that AI hosts can discover and mediate. The API often remains the system of record. The MCP server becomes an adapter with semantics designed for models, users, and host policy.

radio_button_uncheckedshort_text3. Architecture and Protocol Mechanics

Host, client, and server are different responsibilities

An MCP Host is the AI application the user experiences: an IDE agent, desktop assistant, support copilot, or custom agent platform. It owns model orchestration, the conversation, user consent, and the policy that decides which server capabilities become visible. An MCP Client is the protocol component inside that host. It establishes or uses a connection, lists capabilities, sends calls, and converts protocol results into something the host can use. One host may operate several client-to-server relationships at the same time.

An MCP Server is the capability provider. It may wrap a local filesystem, a command-line tool, a SaaS product, a database, or a domain service. The server describes what it exposes and enforces its own validation and authorization. It must never assume that the host will protect it perfectly. Hints can improve a host interface, but security-sensitive checks belong at the boundary that executes the operation.

The separation creates useful independence. The host does not need to know whether a contact search uses SQLite, PostgreSQL, or a CRM API. The server does not need to know which model planned the request. The model receives a curated semantic description instead of database credentials or arbitrary network access. That is the architectural leverage MCP offers.

JSON-RPC messages and the modern stateless core

MCP uses JSON-RPC 2.0 as its message envelope. JSON-RPC supplies requests, responses, identifiers, notifications, and error objects; MCP defines methods such as tools/list, tools/call, resources/list, resources/read, prompts/list, and prompts/get. A simplified tool call is small enough to read directly:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "search_contacts",
    "arguments": { "query": "Maria", "limit": 10 },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "support-assistant",
        "version": "1.4.0"
      }
    }
  }
}

The identifier connects the response to the request. The method says which protocol operation is being performed. Arguments are validated against the tool schema, while reserved metadata carries protocol and client information. An SDK normally creates and parses this envelope for you, but understanding it helps when a gateway rejects a header, a client and server disagree about a version, or a trace must be followed across systems.

The 2026-07-28 revision removed the mandatory initialize/initialized handshake and the Mcp-Session-Id protocol session. Each modern request is self-describing. A client may call server/discover to learn supported versions and capabilities in advance, but it can also attempt an operation and handle an unsupported-version response. This stateless core means ordinary requests can land on any server replica behind a round-robin load balancer.

Stateless protocol does not mean stateless business workflows. If a shopping tool must preserve a basket, it can return a basket_id and require that identifier on later calls. Explicit handles are visible, testable, and transferable between tools; hidden transport sessions are not. Long-running operations follow the same principle through the Tasks extension: a call may return a task handle that the client can inspect, update, or cancel.

radio_button_uncheckedshort_text4. Tools, Resources, Prompts, and Extensions

Tools: operations a model may request

Tools are named operations with a description, an input schema, and a result. Examples include search_contacts, create_ticket, calculate_shipping_quote, or deploy_preview. A host can place selected tool definitions in model context, the model can propose a call, and the host can apply policy or ask for confirmation before the client sends tools/call. The server then validates the arguments and executes domain logic.

{
  "name": "search_contacts",
  "description": "Search contacts by partial name, email, phone, or company. Read-only. Returns at most 20 matches.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "minLength": 2 },
      "limit": { "type": "integer", "minimum": 1, "maximum": 20, "default": 10 }
    },
    "required": ["query"],
    "additionalProperties": false
  }
}

Notice how the description states behavior, side effects, and a limit. The schema constrains the request before business code sees it. This is not decorative metadata: names and descriptions influence tool selection, while bounded schemas reduce ambiguity and abuse. Modern MCP supports full JSON Schema 2020-12 for tool schemas, but complexity should be earned. A smaller predictable schema is usually easier for models, developers, and security reviewers to understand.

Resources and Prompts: context and reusable workflows

Resources are addressable pieces of context identified by URIs. A repository server might expose repo://handbook/deployments; a contact server might expose contacts://42; a reporting server might expose report://sales/2026-Q2. Resources are useful when content has identity and can be listed or read. The host remains responsible for deciding whether and when that content should enter the model context window.

Prompts are reusable, parameterized message templates. They are best understood as user-facing workflows rather than hidden system instructions. A prompt named prepare_incident_update might collect an incident identifier and audience, then return a structured set of messages that guides the host through reading evidence and drafting an update. Tools answer “what operation can be executed?” Resources answer “what context can be addressed?” Prompts answer “what repeatable interaction should the user start?”

Extensions are intentionally separate from the core. They have reverse-domain identifiers, independent versions, and explicit capability negotiation. This gives features such as Tasks, MCP Apps, and enterprise-managed authorization room to evolve without forcing every basic server to implement them. A production team should therefore document both its core protocol version and the extensions it depends on.

radio_button_uncheckedshort_text5. How Models Choose Tools—and How to Design Tools They Can Use

MCP does not make a model call a tool. The host decides which tool definitions are available, the model reasons over their names, descriptions, and schemas, and the host interprets the model output as a proposed action. Policy may allow the call, deny it, rewrite it, or pause for user approval. After execution, the tool result returns to the host, which decides how much of it becomes model context for the next reasoning step.

This loop explains why tool design is an interface-design discipline rather than a serialization exercise. A vague tool called manage_data forces the model to guess among hidden modes. Ten overlapping search tools make selection unstable. A tool that returns 50,000 raw rows can exhaust context even if the underlying query is fast. A destructive tool whose description does not mention deletion prevents the host and user from making an informed decision.

• Use explicit verb-and-object names such as search_contacts, get_contact, create_contact, and delete_contact.
• Give each tool one narrow responsibility and keep read operations separate from writes.
• Write descriptions as behavioral contracts: say what the tool does, what it changes, important limits, and when not to use it.
• Constrain strings, numbers, enums, arrays, and additional properties in the schema; validate the same rules again server-side.
• Return structured, size-limited results with stable identifiers so later calls can refer to exact entities.
• Prefer idempotent operations where possible and use idempotency keys when retries could create duplicates.
• Treat annotations such as read-only or destructive as UI and planning hints, never as authorization controls.

A useful test is to hide the implementation and read only the catalog. Could a new engineer predict which tool to call, what arguments are valid, what will change, and what will come back? If the answer is no, a model will struggle for the same reason. Evaluation should include realistic competing tools, malformed inputs, ambiguous user requests, and result sizes—not only the happy path in which one obvious tool is available.

Large catalogs introduce another production concern: tool overload. Sending hundreds of full schemas on every turn increases tokens, latency, and selection errors. Hosts can group servers by task, search a catalog before exposing a smaller working set, cache deterministic lists, and reveal high-risk tools only when the workflow needs them. The goal is not maximum tool count; it is the smallest trustworthy capability set that can complete the user’s task.

radio_button_uncheckedshort_text6. MCP Compared with REST APIs, Function Calling, and Plugins

MCP is frequently presented as a replacement for technologies that actually sit beside it. REST and GraphQL APIs remain excellent interfaces for deterministic software clients. Model-provider function calling remains a mechanism through which a host asks a particular model to produce structured arguments. Plugins and product connectors remain packaging, distribution, permission, and user-experience systems. MCP can connect these layers, but it does not erase them.

Suppose a CRM already has a secure REST API. Rewriting the CRM around MCP would be wasteful. A better architecture places a thin MCP server in front of approved API operations. It translates model-friendly tools into deterministic API calls, narrows schemas, preserves the CRM authorization model, and shapes results for context. Other software continues to use the REST API directly.

This layered view also limits lock-in. Business logic belongs in domain services, not inside protocol decorators. If the company later needs a REST endpoint, a batch job, or a message consumer, those interfaces can call the same service. MCP is then one deliberate adapter, not the architecture’s center of gravity.

radio_button_uncheckedshort_text7. Practical Example: A Contact Directory MCP Server in Python

A small contact directory is enough to make the protocol concrete without letting code bury the idea. The business requirement is simple: an assistant should be able to search contacts, retrieve one record, create a record, read an addressable contact resource, and offer a reusable follow-up workflow. The same domain service could already power a web application; MCP only exposes selected operations to compatible AI hosts.

A complete but intentionally small server

The current official Python SDK exposes MCPServer. Type annotations and docstrings become part of the advertised contract, while decorators register tools, resources, and prompts. In a real application, DirectoryService would call a database or API and enforce domain rules. The in-memory implementation below keeps attention on the MCP boundary.

from __future__ import annotations

import json
from mcp.server.mcpserver import MCPServer


class DirectoryService:
    def __init__(self) -> None:
        self.contacts = {
            1: {"id": 1, "name": "John Smith", "email": "john@example.com"}
        }

    def search(self, query: str, limit: int) -> list[dict]:
        needle = query.casefold()
        matches = [
            contact for contact in self.contacts.values()
            if needle in contact["name"].casefold()
            or needle in contact.get("email", "").casefold()
        ]
        return matches[:limit]

    def get(self, contact_id: int) -> dict:
        if contact_id not in self.contacts:
            raise ValueError(f"contact {contact_id} not found")
        return self.contacts[contact_id]

    def create(self, name: str, email: str | None) -> dict:
        contact_id = max(self.contacts, default=0) + 1
        contact = {"id": contact_id, "name": name.strip(), "email": email}
        self.contacts[contact_id] = contact
        return contact


service = DirectoryService()
mcp = MCPServer(
    "Contact Directory",
    instructions="Use search before creating a contact to avoid duplicates.",
)


@mcp.tool()
def search_contacts(query: str, limit: int = 10) -> list[dict]:
    """Search contacts by name or email. Read-only. Returns at most 20 matches."""
    if len(query.strip()) < 2:
        raise ValueError("query must contain at least two characters")
    return service.search(query, min(max(limit, 1), 20))


@mcp.tool()
def create_contact(name: str, email: str | None = None) -> dict:
    """Create one contact. Writes data; check for duplicates before calling."""
    if not name.strip():
        raise ValueError("name is required")
    return service.create(name, email)


@mcp.resource("contacts://{contact_id}")
def contact_resource(contact_id: int) -> str:
    """Return one contact as JSON using its numeric identifier."""
    return json.dumps(service.get(contact_id), ensure_ascii=False)


@mcp.prompt()
def prepare_follow_up(contact_id: int, purpose: str = "general follow-up") -> str:
    """Create a grounded workflow for preparing a contact follow-up."""
    return (
        f"Read contacts://{contact_id}. Draft a concise follow-up for {purpose}. "
        "Use only facts in the resource and mark missing details as unknown."
    )


if __name__ == "__main__":
    mcp.run()

The code is short because the SDK handles protocol plumbing, not because production concerns disappeared. search_contacts performs read-only retrieval and bounds its result. create_contact states that it writes and asks callers to search first, but the service would still need a durable uniqueness rule and authorization. The resource gives a contact a stable URI. The prompt composes a workflow without secretly executing anything. Each primitive is used for the job it communicates best.

Run the file with its default stdio transport during local development. An MCP Inspector or compatible host launches the process, lists its capabilities, and sends JSON-RPC messages over standard input and output. Because stdout carries protocol traffic, diagnostic logs must go to stderr. For a deployed endpoint, the same server can run with mcp.run(transport="streamable-http", port=3001), after which clients connect to the /mcp endpoint. Authentication and production hosting still need to be added before that URL is exposed beyond a trusted environment.

What happens when a user asks a natural-language question

User: “Find John Smith and prepare a renewal follow-up.”

1. Host exposes search_contacts and the follow-up prompt.
2. Model proposes search_contacts({"query": "John Smith"}).
3. Host applies policy and sends tools/call through its MCP client.
4. Server validates the input and returns [{"id": 1, ...}].
5. Host adds the bounded result to model context.
6. The selected prompt reads contacts://1 and drafts from verified fields.
7. User reviews the draft; no message is sent automatically.

The sequence contains three separate trust decisions: which catalog the model can see, whether a proposed call may execute, and which result may enter context. MCP transports the request and result; the host and server own those decisions. If the user instead asks to create a contact, a mature host can request confirmation because the operation writes data, and the server can reject the request if the authenticated principal lacks permission.

The example also shows why tiny demonstrations can be misleading. A successful tool call proves protocol connectivity, not production readiness. The next sections cover the work that turns this adapter into dependable infrastructure.

radio_button_uncheckedshort_text8. Transports, Clients, and Deployment

Transport answers a narrow question: how do MCP messages move between client and server? stdio is the natural choice for a local server. The host launches a subprocess and communicates through stdin and stdout. There is no listening port, network authentication, or public endpoint. This model is excellent for developer tools and local data, but the launched process inherits a meaningful security boundary: its executable, arguments, environment variables, and filesystem permissions all require review.

Streamable HTTP is the modern remote transport. It fits shared services, cloud deployments, gateways, and enterprise identity. Under specification 2026-07-28, requests are stateless and carry routing-friendly protocol headers. A gateway can meter tools/call differently from resources/read, enforce body limits, attach trace context, and route replicas without parsing every JSON body or maintaining sticky sessions. The legacy HTTP+SSE transport exists for compatibility but should not be the basis of a new system.

Connecting a server to a real AI product is product-specific even when protocol messages are standard. A desktop application may accept a command and environment variables for stdio. A coding agent may provide a CLI registration command. A remote host may require an HTTPS URL, OAuth metadata, administrator approval, or a marketplace package. Support for prompts, resources, Tasks, MCP Apps, and interactive confirmation also varies. Test the exact host-and-version combinations you intend to support.

A remote production service needs the same fundamentals as any other web service: TLS, restrictive CORS where browsers are involved, request-size limits, timeouts, rate limiting, health checks, graceful shutdown, dependency isolation, and secrets supplied by a managed secret store. The SDK implements MCP; it is not your load balancer, process supervisor, WAF, database migration tool, or incident response plan.

Statelessness simplifies horizontal scaling, but shared application state still needs deliberate storage. Use databases for durable entities, object storage for artifacts, and explicit handles for multi-step workflows. If subscriptions or notifications must cross replicas, use a real pub/sub system rather than an in-memory bus. Cache tools/list and other eligible results according to ttlMs and cacheScope, and keep catalog ordering deterministic so upstream prompt caches remain effective.

radio_button_uncheckedshort_text9. Security and Authorization: Treat Every Tool as an Attack Surface

MCP connects probabilistic model behavior to deterministic systems. That bridge creates leverage and risk at the same time. A malicious document may contain indirect prompt injection telling an agent to exfiltrate secrets. A compromised server may advertise a poisoned description. A legitimate server with broad credentials may become a confused deputy. A harmless-looking search tool with unrestricted URLs may enable server-side request forgery. The protocol transports capabilities; it does not make them trustworthy.

For remote Streamable HTTP, the MCP server behaves as an OAuth-protected resource server. It validates bearer tokens issued by an authorization server and enforces that a token was intended for this resource. Protected Resource Metadata helps clients discover authorization information. Resource indicators reduce token misuse across services. Issuer validation prevents authorization-server mix-up attacks. The modern direction favors Client ID Metadata Documents over Dynamic Client Registration, although compatibility requirements may keep both paths alive during migration.

Authentication answers who is calling. Authorization answers what that principal may do to this specific object under current business rules. A token with contacts:write does not automatically mean the caller may edit every contact. The server must still enforce tenant boundaries, ownership, field-level rules, legal holds, and approval requirements. Authorization belongs close to domain logic because protocol metadata cannot know those rules.

Local stdio servers need a different but equally serious review. Installing a server grants an executable whatever operating-system access the host process has. Inspect source and dependencies, pin versions and hashes, pass the smallest possible environment, restrict filesystem and network access, and never treat a public server registry as proof of safety. An MCP server is executable software, not a passive prompt file.

• Default to read-only capability sets; unlock writes only for workflows that need them.
• Require clear user confirmation for deletion, payment, publication, permission changes, and irreversible actions.
• Validate every argument and every downstream response, regardless of the schema the model saw.
• Keep secrets outside model-visible context and redact sensitive fields from errors, traces, and audit views.
• Bound response size, schema depth, execution time, retries, and outbound destinations.
• Record who requested an action, which tool ran, the policy decision, the target identifiers, and the outcome—without recording unnecessary sensitive content.

Human approval is valuable, but it is not a universal safety mechanism. Users habituate to prompts, and a deceptive model summary can make a dangerous action appear routine. The best design combines understandable confirmation with hard server-side limits, least privilege, reversible operations, and auditability. Safety should not depend on one dialog being read carefully every time.

radio_button_uncheckedshort_text10. Production Engineering: Testing, Observability, Performance, and Compatibility

Test the contract, the model behavior, and the failure path

Protocol conformance is the first layer, not the last. Unit tests should exercise domain services without MCP. Contract tests should verify tool schemas, resource URIs, structured outputs, errors, and protocol-version behavior. Integration tests should run the server through its real transport and intended hosts. Security tests should attempt cross-tenant access, oversized payloads, malformed schemas, duplicate writes, poisoned content, and unauthorized operations.

Model-in-the-loop evaluations answer a different question: does the model choose and use the capability well? Create a dataset of realistic requests, including ambiguous phrasing, missing information, similar tool names, and requests that should not execute. Measure tool-selection accuracy, argument validity, unnecessary calls, confirmation behavior, task completion, and groundedness of the final answer. Re-run the evaluation when descriptions, schemas, host prompts, models, or tool catalogs change.

Observe an MCP call as part of a distributed system

Production telemetry should answer which server and tool were called, how long discovery and execution took, whether the operation succeeded, how large the result was, which downstream dependency failed, and whether the host or user denied the action. W3C Trace Context can connect a host request to the MCP server and onward to APIs or databases. Metrics should include latency percentiles, error categories, timeouts, rate-limit responses, task duration, catalog size, result size, and calls per user or tenant.

Logs must remain useful without becoming a second data leak. Record stable tool names, request and trace identifiers, policy outcomes, and safe entity identifiers. Avoid raw prompts, access tokens, contact details, document contents, and unrestricted tool results unless a narrowly governed diagnostic process requires them. For stdio, keep protocol bytes on stdout and diagnostic logs on stderr.

Manage latency and the model context budget

An agent loop may list tools, call several services, read resources, and return results to the model. Every step adds network latency, model tokens, and failure probability. Keep descriptions informative but concise, cache catalogs within their declared scope, paginate large resources, return summaries with stable identifiers, and fetch full detail only when needed. Parallelize independent reads, but serialize actions whose order or side effects matter.

Retries deserve special attention because models and infrastructure both retry. A read can usually retry safely within a deadline. A create_payment or create_contact call may duplicate work unless it accepts an idempotency key or the server recognizes an earlier attempt. Timeouts should not automatically imply that nothing happened. Return durable operation or task identifiers when a result may outlive the request.

Compatibility must be observable too. Pin and document the protocol revisions and SDK versions you support. Test modern stateless requests and any legacy handshake path you promise. Treat optional extensions as negotiated capabilities rather than assumptions. Watch deprecation windows, changelogs, and conformance-suite results. MCP evolved rapidly in its first two years; production teams should version their mental model as carefully as they version the wire contract.

• Protocol: supported revisions, fallback behavior, required extensions, and conformance tests are documented.
• Tool design: names are explicit, schemas bounded, results structured, and read/write capabilities separable.
• Security: identity, tenant authorization, confirmation, secret handling, and third-party review are enforced.
• Reliability: timeouts, retries, idempotency, rate limits, cancellation, and long-running task behavior are defined.
• Operations: traces, metrics, safe logs, audit events, health checks, and incident ownership exist before launch.

radio_button_uncheckedshort_text11. Enterprise Architecture and Social Value

In an enterprise, the difficult question is rarely “Can we run an MCP server?” It is “Which servers may represent the organization, which identities reach them, which tools may each host expose, and how do we prove what happened?” A mature platform may include an approved server registry, package and dependency scanning, centralized identity, gateway policy, per-tenant authorization, data classification, observability, and an owner for every capability.

API gateways remain relevant. Streamable HTTP is still HTTP, and the current protocol’s method and name headers make gateway controls more practical. A gateway can authenticate callers, validate tokens, route by operation, enforce quotas, restrict request size, attach trace context, and block known-bad clients. It should not, however, become the only authorization layer: domain-specific permissions still belong in the service that understands the resource.

Standardization can also improve organizational learning. When every integration is bespoke, safety and observability improvements must be rediscovered in each adapter. With a governed MCP platform, teams can share secure server templates, validation libraries, test suites, approval patterns, and deployment controls. That raises the baseline for smaller teams and makes review less dependent on individual memory.

The societal contribution is conditional but real. Open protocols can reduce vendor lock-in, help public-interest organizations reuse integrations, and make it easier to inspect the boundary between an AI system and the world it can affect. Clear capability descriptions and audit trails can support accountability. Narrow tools can expose useful services without revealing an entire database or internal network.

The same standard can amplify harm if organizations publish powerful tools without equivalent governance. Easier connectivity lowers the cost of both useful automation and abuse. Responsible adoption therefore means pairing interoperability with accessibility, privacy, worker and user consent, transparent ownership, and meaningful limits on automated action. A protocol can make safe design reusable; it cannot decide society’s acceptable uses for us.

radio_button_uncheckedshort_text12. When MCP Is the Right Choice—and When It Is Not

MCP is compelling when a capability should be reused across multiple AI hosts, when discovery matters, when an organization wants an agent-facing facade over existing APIs, or when local tools and context must be exposed through a standard interface. It is especially useful at ecosystem boundaries: developer platforms, business applications, knowledge systems, and enterprise services that expect several AI consumers over time.

It may be unnecessary when one application has two internal functions and no reuse requirement. A direct function call can be simpler, easier to debug, and safer to operate. MCP is also a poor shortcut around a missing domain API: if business rules are tangled inside a UI or database, adding protocol decorators will expose the confusion rather than solve it. Stabilize the service boundary first.

A useful proof of concept starts with one read-only workflow, one intended host, and measurable success criteria. Build the domain operation, expose a narrow MCP tool, test selection and grounding, add authorization and telemetry, then decide whether reuse justifies expansion. Starting with fifty tools and several hosts makes it difficult to learn which layer is failing.

The decision should be reversible. Keep domain logic independent, use stable internal interfaces, and avoid leaking host-specific assumptions into the server. Then MCP can remain one adapter among several rather than a permanent bet that every future integration must look the same.

radio_button_uncheckedshort_text13. The Future of MCP

MCP’s trajectory points from simple tool connectivity toward a broader substrate for agentic systems. A stateless core makes remote servers easier to scale. Cache hints and routing headers make traffic friendlier to ordinary infrastructure. The extensions framework allows long-running Tasks, interactive MCP Apps, and enterprise authorization patterns to mature without turning the base protocol into a mandatory collection of every possible feature.

The most important future work may be less visible than a new primitive. Better conformance tests, trustworthy distribution, server identity, dependency transparency, permission UX, model evaluations, and cross-host compatibility determine whether an ecosystem is dependable. A protocol wins long-term not because its first demo is easy, but because failures can be understood and implementations can evolve without surprising users.

Tool discovery will also become more selective. As organizations expose thousands of capabilities, hosts cannot place every schema into every prompt. Search, semantic routing, policy-aware catalogs, and progressive disclosure will decide which small subset a model sees. This turns metadata quality and governance into runtime concerns, not documentation chores.

Interoperability will remain uneven. Products will support different extensions, consent flows, transport options, and administration models. That is normal for a growing standard. The practical response is not to abandon portability or pretend it is complete; it is to test the compatibility set that matters, publish limitations, and keep business logic independent of any single host.

radio_button_uncheckedshort_text14. Conclusion: A Standard Boundary, Not a Substitute for Engineering

We began with an integration matrix: many AI applications, many systems, and a custom bridge for nearly every relationship. MCP changes that architecture by giving hosts and capability providers a reusable protocol boundary. A host owns the AI experience and policy, a client speaks MCP, and a server exposes carefully selected capabilities over the services that already run the business.

The theoretical pieces now form one coherent model. JSON-RPC supplies the message envelope. Tools represent actions, Resources provide addressable context, and Prompts package reusable workflows. stdio serves local subprocesses; Streamable HTTP serves remote systems. The current stateless core improves routing and scaling, while extensions carry optional concerns such as Tasks and MCP Apps.

The practical contact-directory example showed how little protocol code is needed when the domain boundary is clear. It also showed why code alone is not an article—or a production system. Tool names, schemas, validation, authorization, consent, result shaping, tests, telemetry, retries, compatibility, and ownership determine whether the integration is useful after the first successful call.

My view is that MCP is important not because it makes agents omnipotent, but because it gives us a place to make their reach explicit. A server catalog can be reviewed. A narrow tool can be tested. A resource can be identified. A call can be authorized and audited. Those properties do not eliminate probabilistic behavior, but they are better foundations than invisible prompt glue and unrestricted credentials.

The protocol’s promise and its warning are therefore the same: integration becomes easier. Used well, that can spread useful, portable, and governable AI capabilities. Used carelessly, it can connect uncertain decisions to sensitive systems faster than organizations can understand the consequences. The next step for a reader is not to expose everything. It is to choose one valuable read-only workflow, design the smallest honest capability surface, and learn what the host, server, and user each need to trust it.

radio_button_uncheckedshort_textOfficial Sources and Further Reading

MCP changes quickly. The sources below are maintained by the protocol project, its official SDKs, Anthropic, or the Linux Foundation. Check the current specification and the compatibility status of your target hosts before making a production decision.

1. Anthropic — Introducing the Model Context Protocol (November 25, 2024)
2. Model Context Protocol Blog — The 2026-07-28 Specification
3. Model Context Protocol — Current specification and documentation
4. Official MCP Python SDK — Server quickstart example
5. Official MCP Python SDK — Running and deploying servers
6. Official MCP Python SDK — Authorization for Streamable HTTP
7. Anthropic — Donating MCP and establishing the Agentic AI Foundation
8. Linux Foundation — Agentic AI Foundation