MCP Architecture

Most AI integrations today are custom builds. Your Claude instance needs access to your database? You write a connector. Your IDE needs the same data? You write another connector. Your SaaS tool needs it? That's a third custom build.

Model Context Protocol (MCP) stops this duplication by establishing a standard interface between AI applications (hosts) and data sources (servers).

The Architecture

MCP uses a client-server model:

The Host is your AI application—Claude Desktop, your IDE, whatever. It manages connections and the LLM.

The Client is an intermediary created by the host for each server connection. It handles protocol communication.

The Server is the data source—a database, file system, API, SaaS tool, anything providing context or execution capabilities.

They communicate via JSON-RPC 2.0 for messaging and stdio or HTTP for transport. Stdio handles local processes quickly. HTTP works for remote services with standard authentication.

What Servers Expose (Server-Side Primitives)

Tools — Executable functions the AI calls. Query a database. Send an email. Create a report. The AI decides when and how to use them based on the context.

Resources — Static or semi-static data sources the AI reads. File contents. Documentation. API responses. Logs. The AI can request specific resources by URI.

Prompts — Reusable templates that guide AI behavior. Few-shot examples. System instructions for specialized contexts. Task templates. Think of these as pre-built reasoning guides.

What Servers Can Request (Client-Side Primitives)

Servers aren't just passive data providers. They can request capabilities from the host:

Sampling — The server asks the host's LLM to generate text. This keeps the server model-agnostic—it works with any AI, not just Claude.

Elicitation — The server asks the user for input or confirmation. The host manages the UI and user interaction.

Logging — The server sends debug information to the host for visibility and troubleshooting.

Communication Flow

1. Initialization: Both sides announce protocol versions, capabilities, and metadata.

2. Discovery: The client queries what tools, resources, and prompts the server offers.

3. Execution: The client calls tools or requests resources during AI reasoning.

4. Notifications: The server can alert the client to changes—new tools available, schema updates, resource state changes—without waiting to be asked.

Why It Matters

With a standard protocol, you build one server and connect it to any host. Your database team maintains one connector, not one per AI platform. Your SaaS integrations work across tools without duplication.

Capabilities are dynamic. Changes propagate through notifications, keeping the AI in sync without polling or manual refresh.

The separation is clean: MCP handles the protocol layer. The host handles the LLM and application logic. Servers handle their domain. Each improves independently.