Skip to content
Lesson 1 of 5

Understanding MCP Architecture

3 min read

The Problem MCP Solves

Before MCP, every AI application had to build its own integration layer. Want Claude to read your database? Write custom code. Want GPT to access your API? Write different custom code. Every combination of model and tool required a unique implementation. This was the N x M problem — N models times M tools, each needing a bespoke connector.

The Model Context Protocol (MCP) solves this by providing a single, open standard for connecting AI models to external tools and data sources. Think of it as USB-C for AI: one universal interface that any model can use to talk to any tool.

The Client-Server Model

MCP follows a client-server architecture. The host is the application the user interacts with (Claude Desktop, an IDE, a custom app). Inside the host, an MCP client maintains a connection to one or more MCP servers. Each server exposes capabilities that the AI model can use.

User → Host (Claude Desktop) → MCP Client → MCP Server → External System

This separation means you build your MCP server once and it works with any MCP-compatible host. No vendor lock-in.

The Three Primitives

MCP defines three core primitives that servers can expose:

Tools are actions the model can execute — calling an API, running a query, creating a file. Tools are the most common primitive. They have a name, a description, and a typed input schema defined with JSON Schema (or Zod in TypeScript).

Resources provide data the model can read — files, database records, API responses. Unlike tools, resources are meant for read-only data access. They use URI-based addressing (file:///path or custom://identifier).

Prompts are reusable templates that help users interact with the server's capabilities. They define structured workflows — a prompt might combine specific tool calls with context to accomplish a common task.

Transport Layers

MCP supports multiple transport mechanisms:

  • stdio: Communication over standard input/output. Ideal for local servers running as child processes. The simplest and most common transport.
  • Streamable HTTP: Server-Sent Events over HTTP for remote servers. Enables cloud-hosted MCP servers accessible over the network.

The transport layer is abstracted away — your server logic stays the same regardless of how it's connected.

Why MCP Won

MCP was created by Anthropic and quickly gained universal adoption. The Linux Foundation now hosts the specification. Major players have adopted it: OpenAI, Google, Microsoft, Amazon, and the entire AI tooling ecosystem.

The reasons are clear: MCP is simple (three primitives cover most use cases), composable (servers can be combined freely), and secure (servers run in controlled environments with explicit capability exposure).

Compare this with raw function calling, where you embed tool definitions directly in your prompts. Function calling works for simple cases, but MCP gives you discoverability, stateful connections, proper error handling, and a standardized ecosystem of reusable servers.

What This Means for You

As a developer, MCP means you build your integration once as an MCP server, and every AI tool in the ecosystem can use it. As a team lead, it means you can create a shared toolkit of MCP servers that your entire team leverages — a topic we'll explore throughout this course.