Before MCP existed, every team building an AI application that needed to check a database, send an email, or search the web wrote a custom integration for that specific combination of model and tool. Ten tools times five AI platforms meant fifty separate integration builds — each one brittle, each one requiring maintenance when either side changed. Anthropic released Model Context Protocol as an open standard in November 2024 specifically to eliminate that multiplication problem. Eighteen months later, MCP governs how the majority of production AI agent systems connect to the outside world, and understanding its actual mechanics — not just the marketing analogy — has become essential knowledge for anyone building, evaluating, or working alongside AI systems in 2026.
I write extensively about AI search infrastructure and increasingly field client questions about MCP as businesses evaluate AI agent tooling for their own operations — everything from customer service automation to internal knowledge retrieval. Understanding MCP's actual architecture, not just its "USB-C for AI" tagline, matters because the protocol's design decisions directly shape what's possible, what's secure, and what's still genuinely difficult in agentic AI systems. This article walks through exactly how MCP works — the architecture, the message flow, the three core primitives, and the practical mechanics of a real tool call from start to finish.
The Problem MCP Actually Solves
Model Context Protocol cuts the AI tool integration problem from N×M custom connections down to N+M by standardizing how AI models connect to external tools and data. Before this standard existed, every AI application developer built one-off connectors: a Slack integration written specifically for GPT-4, a database connector written specifically for Claude, a calendar tool written specifically for a proprietary internal model. None of that work transferred. Swap the underlying model and every integration needed rebuilding.
MCP addresses this by having both sides — the AI application and the external tool — implement one protocol once. A tool that exposes itself as an MCP server automatically works with any MCP-compliant AI application, regardless of which underlying model powers it. An AI application that implements the MCP client side automatically gains access to any MCP server without custom integration work. This is the mechanism behind the industry's favourite analogy: MCP functions like USB-C for AI — before USB-C, every device required its own connector; now any compliant device works with any compliant port.
The Three-Role Architecture — Host, Client, and Server
MCP follows a client-server architecture with three distinct roles, and understanding the precise responsibility of each role clarifies most of the confusion practitioners have about how the protocol actually operates.
| Role | What It Is | Real Examples | Responsibility |
|---|---|---|---|
| Host | The AI-facing application the user directly interacts with | Claude Desktop, Claude Code, Cursor, a custom-built AI application | Manages the overall user experience and creates MCP client sessions |
| Client | A component inside the host that maintains one connection to one specific server | An isolated session object created and managed by the host application | Maintains a stateful, one-to-one JSON-RPC channel with a single MCP server |
| Server | A lightweight program that exposes capabilities to AI applications | A GitHub MCP server, a database MCP server, a Slack MCP server | Exposes tools, resources, and prompts that clients can discover and invoke |
A single host application can create multiple isolated MCP client sessions simultaneously — each one maintaining its own stateful connection to a different server. This means Claude Desktop, functioning as a host, might run one client session connected to a GitHub server, another connected to a database server, and a third connected to a Slack server, all at the same time, each session completely isolated from the others.
The Transport Layer — How Messages Actually Move
All MCP communication happens through JSON-RPC 2.0, a lightweight, well-established remote procedure call protocol that predates MCP by nearly two decades. MCP didn't invent a new message format — it standardised how AI-specific concepts (tools, resources, prompts) get expressed using this existing, proven format.
The Three Core Primitives — What a Server Can Actually Expose
Every MCP server exposes its capabilities to the connecting client through exactly three primitive types. Understanding the precise distinction between these three — a distinction most casual explanations blur together — is the single most important conceptual foundation for working with MCP correctly.
- 🔴 Functions the AI model can invoke to take an action
- 🔴 Examples: query a database, send an email, create a GitHub issue, call a weather API
- 🔴 The AI model decides when and how to call them based on the user's request and the tool's description
- 🔴 Represents the "doing" capability — tools change state or retrieve computed results
- 🟢 Data the model can read — file contents, database records, API responses, configuration data
- 🟢 Identified by URIs, similar in concept to a web address for a specific piece of data
- 🟢 The host application or user typically determines when to include them in context, not the model autonomously
- 🟢 Represents the "reading" capability — resources provide information without taking action
The third primitive, Prompts, sits alongside these two: reusable prompt templates exposed by the server, allowing server developers to define structured interaction patterns — a multi-step workflow for a common task, a standardised way of framing a specific type of request. Where tools represent actions and resources represent data, prompts represent pre-built conversational scaffolding that a server author has designed to guide effective use of their tools and resources.
// Simplified example: an MCP server exposing a "search_orders" tool { "name": "search_orders", "description": "Search customer orders by date range or status", "inputSchema": { "type": "object", "properties": { "status": { "type": "string", "enum": ["pending","shipped","delivered"] }, "date_from": { "type": "string", "format": "date" } } } }
How a Tool Call Actually Flows — Step by Step
Understanding MCP mechanics in the abstract is useful, but tracing exactly what happens during a single tool invocation makes the architecture concrete.
Discovery — The Client Asks the Server What It Can Do
When a client first connects to a server, it sends a request asking the server to list its available tools, resources, and prompts. The server responds with structured descriptions of each capability — including, for tools specifically, the exact input schema the model needs to provide when calling it. This discovery step is what allows any MCP-compliant AI application to work with any MCP server without prior knowledge of that specific server's capabilities.
Context Assembly — The Host Presents Available Tools to the Model
The host application takes the discovered tool descriptions and includes them in the context provided to the underlying AI model, alongside the user's actual request. The model now has visibility into what actions it can take, described in natural language plus a structured schema for the required inputs.
Model Decision — The AI Model Decides a Tool Call Is Needed
Based on the user's request and its understanding of the available tools, the model determines that fulfilling this specific request requires invoking a tool — for example, recognising that "show me pending orders from last week" requires calling the search_orders tool with specific parameter values extracted from the natural language request.
Tool Call Emission — The Model Emits a Structured Request
When the model decides it needs a tool, it emits a tool-call request — a structured message specifying which tool to call and with what parameter values, formatted according to the input schema the server originally provided during discovery.
Execution — The Client Routes the Call to the Server
The client executes the tool call by sending it through the MCP connection to the appropriate server. The server receives the structured request, performs the actual underlying action — querying the real database, calling the real external API — and returns a structured result.
Result Integration — The Response Returns to the Model's Context
The client returns the tool's result to the host, which incorporates it back into the model's context. The model then uses this newly retrieved information to formulate its actual response to the user — often synthesising the tool result into natural language, or chaining into an additional tool call if the task requires multiple steps.
"What strikes me most about MCP's design, coming from an SEO and content strategy background rather than pure engineering, is how directly it mirrors the standardisation problems our own industry has wrestled with for years — schema.org solved a similar N×M problem for structured data, letting any website mark up content once and have any search engine or AI system understand it consistently. MCP does the same thing for AI tool access. When I evaluate AI tooling for client recommendations now, whether MCP support exists has become one of my first questions — not because the underlying capability changes, but because MCP support signals the vendor built for genuine interoperability rather than a walled garden that locks you into one specific AI platform."
Beyond the Basics — Sampling, Elicitation, and Human-in-the-Loop Design
Production MCP implementations increasingly use two more advanced mechanisms that extend beyond the basic tool-call flow, enabling more sophisticated agentic behaviour while keeping humans meaningfully in control of consequential actions.
| Mechanism | Function | Example Use Case |
|---|---|---|
| Sampling | Lets a server request that the connected LLM generate a completion — effectively, the server asking the model for help with reasoning or analysis mid-workflow | A database migration server detects a schema change and uses Sampling to ask the model for an impact analysis before proceeding |
| Elicitation | Lets a server request additional input or explicit confirmation from the human user before proceeding with a high-stakes action | If the schema-change impact analysis is deemed high-risk, the server uses Elicitation to get final human approval before executing |
Together, these two mechanisms implement what the MCP community describes as Human-in-the-Loop design — a deliberate architectural pattern for balancing AI agent autonomy against meaningful human control. A well-designed MCP server doesn't simply execute every tool call the model requests without friction; for genuinely consequential actions, it can pause, request analysis, and require explicit human confirmation before proceeding.
Security and Governance — What Enterprise Adoption Requires
As MCP has moved from developer tooling into enterprise production systems, security and governance considerations have become central to responsible adoption. A practical checklist for enterprise MCP deployment organises around three areas:
Security: Authentication between clients and servers, scoped permissions limiting what each tool can actually access, and careful handling of any credentials a server needs to perform its function. Governance: Clear policy on which servers an organisation permits, review processes for new server connections, and audit trails of tool calls made. Monitoring: Logging of tool invocations, anomaly detection for unusual call patterns, and alerting when Elicitation-gated actions require human review. MCP's OAuth-based authentication has matured significantly since the protocol's early releases, addressing what was initially one of the more significant gaps in enterprise readiness.
Frequently Asked Questions
The Bottom Line
Model Context Protocol solves a specific, well-defined problem: eliminating the N×M custom integration burden that made connecting AI models to external tools brittle and expensive to maintain. Its three-role architecture — host, client, server — combined with JSON-RPC 2.0 messaging over stdio or Streamable HTTP transports, and three clean primitives — Tools, Resources, Prompts — gives any AI application a standardised way to discover and use external capabilities. Understanding the actual tool-call flow, from discovery through execution to result integration, demystifies what's happening beneath the "USB-C for AI" analogy. As MCP adoption scales into enterprise production systems, the Sampling and Elicitation mechanisms for human-in-the-loop control, alongside maturing OAuth-based security, represent the protocol's evolution from developer convenience into genuine production infrastructure — now governed as an open, vendor-neutral standard under the Linux Foundation rather than any single company's roadmap.
.webp)
Driven by advanced SEO expertise, deep marketing analytics, high-impact content strategy
With 5+ years of hands-on experience, I specialize in holistic search strategies that don’t just rank—they drive real, measurable business growth. I’ve worked across industries including healthcare, hospitality, legal, e-commerce, and professional services, helping brands dominate their target markets. My approach bridges the gap between raw data and creative execution. Every strategy I build is rooted in rigorous market analysis, structured SEO frameworks, and tailored content ecosystems—no templates, no shortcuts. Whether you’re a single-location brand or scaling across multiple cities, I create data-driven marketing systems designed to compound results and grow with you.
Want Your Business Ready for AI Integrations?
Get a free AI SEO audit from DigitalArka. We'll help optimize your website for AI platforms with structured data, technical SEO, entity optimization, and modern AI integration best practices to improve visibility across ChatGPT, Claude, Gemini, and Brave Search.
Get Your Free AI SEO Audit →