---
title: "15 — Model Context Protocol: A Standard Plug for Tools and Data"
uid: ai-engineer-model-context-protocol
tags: ["model-context-protocol", "tools", "mcp", "agents", "standardization", "roadmap:ai-engineer", "protocol"]
excerpt: "MCP is the USB-C of AI tooling: a standard client-server protocol that lets any AI app talk to any tool or data source through one plug."
date: 2026-08-13T03:28:36+0000
source: https://www.aveshina.my.id/en/blog/ai-engineer-model-context-protocol
---

"Just another agent thing" was how I initially filed the Model Context Protocol, and I almost skipped the part that matters. The comparison that made it click: **MCP is a standard client-server protocol that lets any AI app talk to any tool or data source through one plug — the way USB-C did for cables.** [1][2] Before MCP, every agent framework had its own way of defining tools and connecting to data, so a tool written for one framework didn't work in another. MCP fixes that by defining a common protocol, so a tool or data source exposed as an MCP server can be used by any MCP-compatible client.

The framing that finally landed is the USB-C analogy, and it's worth taking literally. Before a standard plug, every device shipped with its own charger and its own connector; nothing interchanged. After the standard, one cable works across devices. MCP does the same for AI: the MCP server is the socket a tool or data source exposes; the MCP client is the plug an AI app (a host) uses to draw from it; the protocol is the shape they share. Once a data source speaks MCP, any MCP-compatible agent can use it without custom integration.

```figure
<svg viewBox="0 0 740 280" xmlns="http://www.w3.org/2000/svg" class="my-6 w-full max-w-2xl" role="img" aria-label="MCP as a standard plug. Left: an AI app (MCP host + client) with a single MCP plug. Right: several MCP servers — database, file system, API, search — each exposing the same socket shape. The one plug can connect to any of them.">
  <defs>
    <marker id="mcparrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto">
      <path d="M0,0 L10,5 L0,10 z" fill="#64748b"/>
    </marker>
  </defs>
  <g font-family="ui-sans-serif, system-ui, sans-serif" text-rendering="geometricPrecision">

    <!-- host + client -->
    <text x="120" y="28" font-size="12" font-weight="700" fill="#1e1b4b" text-anchor="middle">AI app (host)</text>
    <rect x="40" y="44" width="160" height="80" rx="10" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.5"/>
    <text x="120" y="68" font-size="11" font-weight="700" fill="#1e1b4b" text-anchor="middle">host</text>
    <text x="120" y="84" font-size="9.5" fill="#475569" text-anchor="middle">manages the agent</text>
    <rect x="64" y="94" width="112" height="22" rx="4" fill="#c7d2fe" stroke="#4f46e5"/>
    <text x="120" y="109" font-size="10" font-weight="700" fill="#1e1b4b" text-anchor="middle">MCP client</text>

    <!-- the plug -->
    <rect x="200" y="76" width="60" height="28" rx="4" fill="#1e1b4b" stroke="#4f46e5" stroke-width="1.5"/>
    <text x="230" y="94" font-size="9.5" font-weight="700" fill="#e0e7ff" text-anchor="middle">MCP plug</text>

    <!-- servers -->
    <text x="540" y="28" font-size="12" font-weight="700" fill="#052e16" text-anchor="middle">MCP servers (tools + data)</text>
    <g font-size="10" fill="#052e16" text-anchor="middle">
      <rect x="420" y="44" width="100" height="34" rx="6" fill="#dcfce7" stroke="#16a34a"/>
      <text x="470" y="60">database</text>
      <text x="470" y="73" font-size="9" font-style="italic">same socket</text>

      <rect x="540" y="44" width="100" height="34" rx="6" fill="#dcfce7" stroke="#16a34a"/>
      <text x="590" y="60">file system</text>
      <text x="590" y="73" font-size="9" font-style="italic">same socket</text>

      <rect x="660" y="44" width="60" height="34" rx="6" fill="#dcfce7" stroke="#16a34a"/>
      <text x="690" y="60">API</text>

      <rect x="420" y="100" width="100" height="34" rx="6" fill="#dcfce7" stroke="#16a34a"/>
      <text x="470" y="116">search</text>
      <text x="470" y="129" font-size="9" font-style="italic">same socket</text>

      <rect x="540" y="100" width="100" height="34" rx="6" fill="#dcfce7" stroke="#16a34a"/>
      <text x="590" y="116">Slack</text>
      <text x="590" y="129" font-size="9" font-style="italic">same socket</text>

      <rect x="660" y="100" width="60" height="34" rx="6" fill="#dcfce7" stroke="#16a34a"/>
      <text x="690" y="116">git</text>
    </g>

    <!-- protocol label -->
    <rect x="290" y="160" width="160" height="40" rx="8" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.5"/>
    <text x="370" y="178" font-size="11" font-weight="700" fill="#422006" text-anchor="middle">the MCP protocol</text>
    <text x="370" y="192" font-size="9.5" fill="#422006" text-anchor="middle">one shared contract</text>

    <!-- connecting lines -->
    <line x1="260" y1="90" x2="418" y2="60" stroke="#64748b" stroke-width="1.3" marker-end="url(#mcparrow)"/>
    <line x1="260" y1="90" x2="418" y2="116" stroke="#64748b" stroke-width="1.3" marker-end="url(#mcparrow)"/>
    <line x1="370" y1="160" x2="370" y2="140" stroke="#ca8a04" stroke-width="1" stroke-dasharray="3 2"/>
    <text x="370" y="240" font-size="10" font-style="italic" fill="#475569" text-anchor="middle">one plug shape → any tool or data source works with any compatible host</text>
  </g>
</svg>
```

## The architecture: host, client, server

MCP defines three roles, and naming them precisely cleared up most of my confusion [1][3].

The **MCP host** is the AI application itself — the editor, the agent framework, the chatbot. It's where the user's request lands and where the model runs. The host manages one or more MCP clients.

The **MCP client** is the component inside the host that talks the protocol. It handles the communication, serialization, and deserialization of data exchanged with servers, so the host's agent logic doesn't have to know any protocol detail — it just asks its client for tools and data [4].

The **MCP server** is the thing that actually exposes the tools or data. A server might wrap a database, a file system, an external API, or a search index. It receives requests from clients, retrieves the relevant data or runs the requested tool, and returns results in the standardized format [5].

The split that matters: the host and its client are on the AI-app side; the server is on the data-or-tool side. The protocol is the contract between them. Because the contract is standard, a server written once can serve any compatible client.

## The layers: transport and data

Inside MCP, two layers do the actual work [6]. The **transport layer** is responsible for reliably moving messages between client and server — how they're packaged, addressed, and transmitted, whether across a network or within a single machine. The **data layer** manages the actual data the agent reasons over — storage, retrieval, caching, transformation, making sure the right information is available in the right format. These mirror the classic separation of concerns in any protocol stack, and the reason to name them is that each can be chosen independently: I can run MCP over a local stdio transport for development or a remote HTTP/SSE transport for production, with the same data layer on top.

## Local versus remote: where the server lives

An MCP server can run in two places, and the choice has real tradeoffs [7][8].

**Local** deployment runs the server directly on my own computer. It listens on a local address (something like 127.0.0.1:8000) accessible only from the same machine. This is great for development, personal tools, and private experiments — full control, no cloud costs, no network dependency. The limit is my hardware, and sharing with others requires tunneling.

**Remote** (cloud) deployment puts the server on a cloud provider, packaged as a container, given a public HTTPS address, fronted by a load balancer, and secured with TLS and API keys. This is what production needs — many users, elastic scaling, no local hardware limits — at the cost of cloud bills, ops burden, and data-protection responsibilities.

The protocol is the same in both cases. That's the point: I can develop against a local MCP server and ship a remote one without changing the client code, because the contract is identical.

## Building servers and clients

The MCP ecosystem provides first-party tooling for both sides [9][10]. Building a server means defining the tools and data it exposes and speaking the protocol; the official docs walk through it, and community lists like "Awesome MCP Servers" collect pre-built servers for common data sources (databases, file systems, SaaS APIs) that I can use without writing my own. Building a client means implementing the client side of the protocol so my AI app can talk to any server — and again, the official docs cover this, with framework integrations meaning I often don't have to write a client from scratch at all.

The practical upshot: the common case is writing a _server_, because that's where my private data and custom tools live, and using an existing client that my host already provides. The rare case is writing a _client_, which I'd only do if I were building a new host application from scratch.

## Why this matters: the integration explosion

The problem MCP solves is worth naming directly. Before a standard protocol, connecting an AI app to N tools meant writing N custom integrations, one per tool, in the framework the app used. Connecting M AI apps to N tools meant M×N integrations. With MCP, each tool exposes one server, each app includes one client, and the protocol handles the rest — the integration count drops to M+N [1]. For a field where new tools and new agents appear weekly, that reduction is what makes the ecosystem tractable rather than a combinatorial explosion of one-off connectors.

## How I use this

I treat MCP as the default way to expose tools and private data to AI apps, and I reach for it whenever I'm connecting an agent to anything beyond a trivial built-in function. For private data sources — a database, an internal API, a file store — I build a small MCP server that wraps them, which means any MCP-compatible host can use them without further integration. I develop locally against a stdio transport and move to a remote server for production, with the same server code. And before writing a server, I check the community registries, because someone has often already written one for the common data source I need. The discipline is to stop writing per-framework tool integrations and instead write one MCP server per data source — the standard plug is cheaper than the bespoke cable, every time.

## References

[1] Model Context Protocol, "Model Context Protocol," 2025. [Online]. Available: [https://modelcontextprotocol.io/](https://modelcontextprotocol.io/)

[2] Hugging Face, "Model Context Protocol (MCP) Course," 2025. [Online]. Available: [https://huggingface.co/learn/mcp-course/en/unit0/introduction](https://huggingface.co/learn/mcp-course/en/unit0/introduction)

[3] Model Context Protocol, "Concepts of MCP," 2025. [Online]. Available: [https://modelcontextprotocol.io/docs/learn/architecture#concepts-of-mcp](https://modelcontextprotocol.io/docs/learn/architecture#concepts-of-mcp)

[4] Model Context Protocol, "Understanding MCP clients," 2025. [Online]. Available: [https://modelcontextprotocol.io/docs/learn/client-concepts#understanding-mcp-clients](https://modelcontextprotocol.io/docs/learn/client-concepts#understanding-mcp-clients)

[5] Model Context Protocol, "Understanding MCP Servers," 2025. [Online]. Available: [https://modelcontextprotocol.io/docs/learn/server-concepts#understanding-mcp-servers](https://modelcontextprotocol.io/docs/learn/server-concepts#understanding-mcp-servers)

[6] Model Context Protocol, "Layers," 2025. [Online]. Available: [https://modelcontextprotocol.io/docs/learn/architecture#layers](https://modelcontextprotocol.io/docs/learn/architecture#layers)

[7] Model Context Protocol, "Connect to local MCP servers," 2025. [Online]. Available: [https://modelcontextprotocol.io/docs/develop/connect-local-servers](https://modelcontextprotocol.io/docs/develop/connect-local-servers)

[8] Model Context Protocol, "Connect to remote MCP Servers," 2025. [Online]. Available: [https://modelcontextprotocol.io/docs/develop/connect-remote-servers](https://modelcontextprotocol.io/docs/develop/connect-remote-servers)

[9] Model Context Protocol, "Build an MCP server," 2025. [Online]. Available: [https://modelcontextprotocol.io/docs/develop/build-server#build-an-mcp-server](https://modelcontextprotocol.io/docs/develop/build-server#build-an-mcp-server)

[10] Model Context Protocol, "Build an MCP client," 2025. [Online]. Available: [https://modelcontextprotocol.io/docs/develop/build-client](https://modelcontextprotocol.io/docs/develop/build-client)

```quiz
Q: MCP is best described as…
- a new kind of AI model
- a standard client-server protocol so any AI app can talk to any tool or data source through one shared contract
correct: 1
explain: MCP standardizes the plug. Before it, every framework had its own tool format; with it, a tool written as an MCP server works with any compatible client.

Q: The three MCP roles are…
- model, prompt, and context
- host (the AI app), client (the protocol component inside the host), and server (the thing exposing tools/data)
correct: 1
explain: The host manages the agent and one or more clients. Each client speaks the protocol to a server that wraps tools or data.

Q: Why does MCP reduce integration count from M×N to M+N?
- because it removes the need for tools entirely
- because each tool exposes one standard server and each app includes one standard client, instead of bespoke per-pair connectors
correct: 1
explain: Standardizing both sides means M apps and N tools need only M clients and N servers, not M×N custom integrations.

Q: Local versus remote MCP server deployment differs mainly in…
- the protocol they speak
- where the server runs (your machine vs a cloud provider) and the operational tradeoffs (control vs scale)
correct: 1
explain: The protocol is identical in both cases. Local suits development and private tools; remote suits production with many users.

Q: The common case in practice is to…
- write a new MCP client for every project
- write a small MCP server for your private data/tools, and reuse an existing client provided by your host
correct: 1
explain: Private data and custom tools live on the server side. Hosts already ship clients, so you usually write servers, not clients.
```