Model Context Protocol Explained in 3 Levels of Difficulty

Every data platform team building agentic pipelines hits the same wall eventually.

Every data platform team building agentic pipelines hits the same wall eventually. You want Claude or CoCo to query Snowflake, trigger a dbt run, check an Airflow DAG, and post the result to Slack — one agent, four systems. The naive path is to write four custom connectors. Then someone adds Cursor as a second AI client, and now you need eight connectors. Add a third client and a fifth tool, and you’re maintaining fifteen bespoke integrations, each with its own auth, its own schema, its own failure mode. This is the M×N problem, and it’s the entire reason the Model Context Protocol exists.

MCP is an open standard — introduced by Anthropic in November 2024 and since handed to neutral, open governance — that turns M×N custom integrations into M+N standardized ones. Every AI client speaks one protocol; every tool exposes itself once through that protocol; any client can now reach any tool with zero custom glue. This article explains MCP the way you’d actually want to learn it: as a problem, then as an architecture, then as the production concerns that only show up once you’re running it for real.

A flowchart shows 5 steps of an MCP request process, illustrating how data query and response occur between a host, client, server, and back for checking if last night’s load is complete.

The same five-step shape whether the tool on the other end is Snowflake, dbt, Airflow, or Slack — that uniformity is the entire point of the protocol.

TL;DR

→ The problem: M AI clients × N tools = M×N custom integrations. Every new client needs a connector to every tool; every new tool needs a connector to every client. This is the wall every multi-tool agent project hits.

→ The architecture: MCP standardizes on three roles — the Host (the AI model reasoning about what to do), the MCP Client (the protocol handler maintaining the connection), and MCP Servers (the tools, exposing capabilities through one shared interface). One protocol, many tools, loosely coupled.

→ The flow: a request comes in → the client sends a tool request over MCP → the server executes the action → the response comes back over MCP → the model gets its result. Five steps, always the same shape, regardless of which tool is on the other end.

→ In production: transport is stdio for local servers or Streamable HTTP for remote ones (what most people still call “SSE,” though the spec has since folded plain SSE into the newer Streamable HTTP transport). Security means authentication, explicit user consent for tool access, audit logging, and guarding against supply-chain risk from untrusted servers.

→ Deployment splits into local servers (full control, data never leaves the machine) and cloud servers (containers or serverless, elastic and shared) — and the choice affects both your security posture and your Snowflake credit bill.

Level 1 — The problem: why M×N breaks down

Picture three AI clients your team already uses: a chat assistant, an IDE copilot, and an agent framework running scheduled pipeline checks. Each one can only see what’s inside its own context window — the system prompt, conversation history, and whatever data you’ve explicitly fed it. None of them can natively reach Snowflake, dbt, Airflow, or your internal APIs. To fix that, each client needs its own custom adapter to each tool.

That’s the M×N integration explosion. Three AI clients times five tools is fifteen custom connections, and every one of them is a maintenance burden: its own auth flow, its own error handling, its own schema mapping, its own breakage when the underlying API changes. Add a client and you add five more connections. Add a tool and you add three more. The graph of arrows gets tangled fast, and nobody owns the whole picture — which is exactly the kind of sprawl that turns into an unaudited security gap, the same failure mode we cover in governing agentic workflows.

The formula is worth internalizing because it’s the whole justification for a standard protocol: M clients × N tools = M×N integrations. Three AI applications times five tools is fifteen integrations built and maintained by hand. MCP’s entire value proposition is collapsing that multiplication into addition.

Level 2 — The architecture: Host, Client, Servers

MCP introduces a standard protocol to connect AI models to tools, built on three roles.

The Host is the AI model itself — Claude, CoCo, or whatever’s reasoning about the task. It understands the user’s request, decides when a tool is needed, and interprets the results that come back. The Host never talks to a tool directly.

The MCP Client is the protocol handler sitting between the Host and the outside world. It maintains the connection to MCP servers, handles the messaging and routing, and translates between what the model wants and what the tool’s interface expects.

The MCP Servers are the tools themselves, each exposing its capabilities through the same standardized interface — a Snowflake warehouse, a dbt project, an Airflow instance, a file system, a Slack channel. From the model’s perspective, querying Snowflake and posting to Slack look structurally identical: a tool request in, a tool response out.

The request flow is always the same five steps: ① a user request or conversation reaches the Host, which decides a tool is needed; ② the Client sends a tool request over MCP; ③ the server executes the action or accesses the data; ④ the tool response comes back over MCP; ⑤ the results return to the model, which continues reasoning with them. This is the same pattern our MCP in Snowflake CoCo Desktop guide walks through concretely with a live warehouse connection.

Three properties fall out of this design. One protocol, many tools — you write the integration once per tool, not once per client-tool pair. Loosely coupled and easy to extend — adding a sixth tool means standing up one more server, not touching any existing client. The model gets more context on demand — rather than stuffing every possible data source into the system prompt, the model requests exactly what it needs, when it needs it, which is the same context-discipline argument behind choosing tools over subagents for well-defined operations.

Level 3 — Production: transport, security, deployment

Understanding the architecture gets you a working demo. Running MCP in production surfaces three concerns the diagram doesn’t show.

Transport — how it connects. Local servers use stdio: the client spawns the server as a subprocess and exchanges JSON-RPC messages over standard input and output. It’s simple, fast, and the default recommendation whenever the server and client run on the same machine. Remote servers use Streamable HTTP — what most documentation still calls “SSE” from the protocol’s earlier revision, since the original Server-Sent Events transport has since been superseded by Streamable HTTP, which adds session management and resumability on top of the same idea: the client posts JSON-RPC to an endpoint and receives responses as a stream. Streamable HTTP is what scales — it’s how you’d expose a Snowflake MCP server to multiple teams without spinning up a subprocess per user.

Security — keeping it safe. MCP delegates enforcement to the host application, but the spec is explicit about the requirements. Authentication verifies both clients and servers before any tool call executes. User consent is required for tool access — a host must surface what’s about to happen and let a human approve it, not silently authorize an agent to act. Audit logs track every action and change, the same discipline behind our ETL audit logger approach applied to tool calls instead of pipeline tasks. And supply-chain risk is real: an MCP server is code you’re trusting to run with whatever privileges you grant it, so an untrusted or malicious server is a live attack surface — treat every third-party server the way you’d treat an unreviewed dependency, not a trusted extension of your own stack. Together these form what’s sometimes called the trusted tool boundary, and it’s the same boundary we cover in depth in giving agents safe access to pipeline metadata.

Deployment — where it runs. Local servers run on your own machine: full control, data never leaves your environment, and the simplest security story because there’s no network boundary to defend. Cloud servers run in containers or serverless platforms: elastic, shareable across a team, and necessary once more than one person needs the same MCP-exposed tool — but now you’re managing network security, multi-tenant credential scoping, and the cost of always-on compute rather than a subprocess that starts on demand. The choice isn’t purely technical; it’s a data-governance decision as much as an infrastructure one.

The gotchas nobody warns you about

“SSE” in most tutorials is already legacy language. The original SSE transport has been folded into Streamable HTTP in current spec revisions, but because so much existing documentation and so many existing servers still use the older terminology, you’ll see “SSE” used loosely to mean “the remote transport” long after the underlying mechanism has moved on. Check which transport a server actually implements before assuming compatibility.

Access to the server isn’t access to every tool on it. A host connecting to an MCP server doesn’t automatically get every tool that server exposes — tool-level permissions still need to be granted deliberately, the same principle behind the scoped-role pattern in our pipeline metadata security guide.

Consent fatigue is a real failure mode. If every single tool call pops a confirmation, users start reflexively approving everything, which defeats the purpose of the consent gate. Scope confirmation to genuinely consequential actions — reads can often be pre-approved by policy; writes and destructive actions should always interrupt.

A local-only mental model breaks the moment you scale. Teams that start with stdio and a single developer’s laptop often don’t plan for the jump to Streamable HTTP and shared cloud servers, and the security model changes meaningfully at that transition — credentials that were fine as environment variables on one machine need proper secrets management the moment the server is reachable over a network.

The one principle

MCP replaces M×N custom integrations with M+N standardized ones by giving every AI client and every tool a shared protocol to speak. The architecture — Host, Client, Servers — is simple by design; the real engineering is in Level 3: choosing the right transport, enforcing consent and audit at the trust boundary, and picking local versus cloud deployment deliberately rather than by default. Get the protocol right and adding your sixth tool costs you one server, not five more custom connectors.