Free lesson · Claude Certified Architect - Foundations (CCA-F)

What MCP Is and the Problem It Solves

Easy12 min readd2mcpprotocolintegrationarchitecture

The Problem Before MCP

Say you build an AI assistant. You want it to read from your company wiki, query your database, and check your ticketing system.

You write three integrations. Each one is custom code - connecting, authenticating, exposing the right operations, handling errors.

Now your colleague builds a different AI assistant. It needs the same three systems. They write three more integrations, from scratch, because yours were built into your application.

Then a third team does the same. And a fourth.

graph TD
    A1[Assistant A] --> B1[Wiki integration]
    A1 --> B2[Database integration]
    A1 --> B3[Tickets integration]
    A2[Assistant B] --> C1[Wiki integration]
    A2 --> C2[Database integration]
    A2 --> C3[Tickets integration]
    A3[Assistant C] --> D1[Wiki integration]
    A3 --> D2[Database integration]
    A3 --> D3[Tickets integration]

This diagram shows the integration problem before MCP. Three separate assistants each connect to a wiki, a database, and a ticketing system, and each one requires its own custom integration for each system. Nine integrations exist where three systems and three assistants are involved.

Three applications, three data sources, nine integrations. Add a fourth data source and you need three more. Add a fourth application and you need four more.

This multiplication is the problem MCP was built to remove.

What MCP Actually Is

MCP - the Model Context Protocol - is an open standard for connecting AI applications to external systems.

The idea is simple. Instead of every application writing its own integration for every system, each system exposes itself once through a standard protocol. Any application that speaks the protocol can then use it.

graph TD
    A1[Assistant A] --> M{MCP}
    A2[Assistant B] --> M
    A3[Assistant C] --> M
    M --> S1[Wiki MCP server]
    M --> S2[Database MCP server]
    M --> S3[Tickets MCP server]

This diagram shows the situation after MCP. Three assistants all speak the MCP protocol, which connects to three servers: a wiki server, a database server, and a ticketing server. Each system is exposed once rather than once per application.

Three applications, three data sources, three servers. Add a fourth application and it gets all three systems for free. Add a fourth system and every existing application can use it immediately.

Important: The value of MCP is not that it makes any single integration easier. It is that integrations become reusable. A server someone else wrote works with your application, and one you write works with theirs - including applications that did not exist when you wrote it.

The Standard Analogy

MCP is often compared to a universal port. Before a common standard, every device had its own connector, and every combination needed its own cable.

The analogy holds in the useful direction. A standard connector does not make any individual device better. It makes the ecosystem work, because anything with the port works with anything else with the port.

That is the right way to think about MCP's value. It is infrastructure, and its benefit is combinatorial rather than local.

The Three Roles

MCP has a specific architecture with three parts. The naming matters because the terms appear throughout the rest of this module.

A host runs one client per server it connects to. So a host connected to three servers has three clients, each maintaining its own connection.

The separation matters because it keeps servers simple. A server does not need to know anything about the host, the model, or the conversation. It exposes capabilities and answers requests. All the AI-specific work stays on the host side.

Tip: When reading about MCP, keep host and client distinct. People sometimes say "client" when they mean the whole application. In MCP terms the host is the application, and the client is the specific connection component inside it. Scenario questions occasionally depend on this distinction.

What MCP Is Not

Three clarifications that prevent common confusion.

It is not a replacement for tool use. The model still calls tools exactly as Module 05 described - name, description, schema, and a request your code executes. MCP is about where those tools come from. A tool exposed by an MCP server appears to the model as a tool.

It is not an AI protocol. There is nothing model-specific in it. It is a way for programs to expose capabilities to other programs, using JSON-RPC underneath. The AI part happens in the host.

It is not only for Claude. It is an open standard, and other applications implement it. A server you write works with any compliant host.

Warning: Because MCP tools become tools the model can select, everything from Module 05 applies to them. A poorly described MCP tool routes as badly as a poorly described local one. Adopting MCP does not exempt you from description and schema work - it changes where that work lives.

Why This Matters for Architecture

Beyond the integration maths, MCP changes how you think about system boundaries.

Capabilities become shareable. A team that builds a good server for an internal system has built it for the whole organisation, not just their own application.

The boundary is enforced. A server exposes exactly what it chooses to expose. The host cannot reach past that surface, which makes the server a genuine security boundary rather than a convention.

Servers can be third-party. This is powerful and it is a risk. A server someone else wrote runs with whatever access you grant it, and its tool descriptions enter your model's context. Module 07 covers the trust implications in depth.

Important: The security picture cuts both ways. A server is a clean boundary when you control it and a genuine attack surface when you do not. That distinction drives most of the production guidance in the next module.

The Server Is Reusable, Not the Integration Work

A nuance worth catching, because it affects how much MCP actually saves you.

MCP standardises the connection, not the underlying work. Writing a good server still means designing tools, writing descriptions, shaping schemas, and handling errors - everything from Module 05. That effort does not disappear.

What changes is that you do it once. The four applications from the earlier example do not each write that logic; they each connect to it.

graph TD
    A["Without MCP"] --> B["Integration logic<br/>written per application"]
    B --> C["Four teams solve<br/>the same problems<br/>four times"]
    D["With MCP"] --> E["Integration logic<br/>written once, in a server"]
    E --> F["Four teams connect<br/>Quality is shared"]

This diagram contrasts effort with and without MCP. Without MCP, integration logic is written per application, so four teams solve the same problems four times. With MCP, the integration logic is written once inside a server, and four teams connect to it, so the quality of that work is shared.

There is a quality consequence too. When four teams each write their own integration, they are four different qualities. When one server is shared, everybody gets whichever quality it has - which is an argument for building it carefully, since its weaknesses propagate as widely as its strengths.

When to Use MCP

Not every integration needs it.

The honest summary is that MCP earns its overhead when reuse is real. For a single tool used by a single application that nobody else will touch, writing a plain tool is simpler and there is nothing wrong with it.

Tip: Ask whether a second consumer is plausible. If yes, a server is worth it even before that consumer exists, because retrofitting is harder than starting there. If genuinely not, a direct tool is the simpler answer and the exam does not reward adopting a protocol for its own sake.

One further point about the standard itself: because MCP is open and not tied to any one vendor, a server written today keeps working with hosts that do not exist yet. That durability is part of the argument for building one even when only your own application needs it right now.

Interview: Scenario questions about MCP tend to test whether you understand it as an integration standard rather than a feature. Watch for scenarios describing several applications needing the same capability - that is the MCP case. Also watch for scenarios where a single simple integration is being over-engineered into a server, which is the over-engineering trap in this domain's costume.

Exercise: Starter. Explain the integration multiplication problem in your own words, using a specific count. Then name the three MCP roles and say which one runs the AI application.

Intermediate. List the external systems one of your applications connects to. For each, ask whether another team would benefit from the same connection. The ones where the answer is yes are your MCP candidates.

Advanced. Take an integration you have written and sketch what it would look like as a server - what capabilities it would expose, and what it would deliberately not expose. That second list is the security boundary, and deciding it explicitly is most of the design work.

Quiz: Quick check: A company has four AI applications that each need access to the same three internal systems. Currently each application has its own integration for each system. What does MCP change?

A) It makes each individual integration faster to write B) Each system is exposed once as a server, and all four applications connect to it - twelve integrations become three C) It removes the need for authentication between applications and systems D) It lets the model access the systems directly without any integration code

Answer: B - the benefit is combinatorial rather than local. Option D is wrong in an important way: the model never accesses anything directly, and a server is still ordinary code that your host calls through a client.

Back to Claude Certified Architect - Foundations (CCA-F)