Model Context Protocol (MCP) Architecture

Learning outcomes

• Architect MCP client-server integrations using stdio and SSE transports
• Define typed MCP Tools, Resources, and Prompts using JSON Schema

Mental model

Before MCP, every AI application built custom, ad-hoc integrations for external tools (e.g., connecting a chat model to GitHub, PostgreSQL, or Slack). This created an $N \times M$ integration matrix where every new model client had to re-implement tool connectors from scratch.

The Model Context Protocol (MCP) establishes an open standard (analogous to the Language Server Protocol in IDEs):

• MCP Clients (e.g., Claude Desktop, Antigravity IDE, Custom Agent Hosts): Maintain model session state, manage user consent, and issue JSON-RPC requests.
• MCP Servers (e.g., Postgres MCP, GitHub MCP, Filesystem MCP): Expose typed Tools (executable functions), Resources (readable data streams), and Prompts (pre-configured templates).

Theory

MCP operates over standard transport layers (stdio for local processes, SSE / HTTP for remote microservices) using JSON-RPC 2.0:

Request:  {"jsonrpc": "2.0", "method": "tools/call", "params": {"name": "query_db", "arguments": {"sql": "SELECT..."}}, "id": 1}
Response: {"jsonrpc": "2.0", "result": {"content": [{"type": "text", "text": "Rows returned..."}]}, "id": 1}

Key Architecture Components:

• Tools: State-mutating executable actions exposed with JSON Schema parameter definitions.
• Resources: Read-only contextual URIs (postgres://database/table, file:///logs/app.log) streamed directly into prompt context.
• Prompts: Server-managed prompt primitives allowing tool providers to define standardized workflows.
• Security & Consent Gate: MCP clients MUST require explicit user authorization before executing tool calls with external side effects.

MCP Architecture = Client (User Control) + Transport (JSON-RPC) + Server (Tools/Resources)

Alternatives and trade-offs

MCP decouples model orchestrators from backend tool implementations, allowing developers to reuse thousands of off-the-shelf MCP servers across different agent frameworks. However, remote SSE MCP servers introduce network transport serialization overhead (~5ms–15ms) compared to direct in-process function imports.

Failure modes and misconceptions

• Bypassing Consent Gates: Automatically approving state-mutating MCP tool calls exposes local databases and filesystems to prompt injection risks.
• Schema Drift: Changing MCP server parameter names without updating client schemas causes JSON-RPC validation failures.
• Resource Leakage: Exposing unrestricted file URIs via Filesystem MCP servers allows malicious agents to read sensitive configuration files.

Knowledge check

Decision scenario

An enterprise software team needs to enable 15 internal AI agent tools (Jira, GitHub, Jenkins, Datadog) across 4 different AI assistant clients (Claude Desktop, internal CLI, IDE plugin, web dashboard).

Learning outcomes

• Architect MCP client-server integrations using stdio and SSE transport protocols.
• Define typed MCP Tools, Resources, and Prompts using JSON Schema.
• Enforce security boundaries and user consent gates on state-mutating tool calls.

Trade-offs

MCP standardizes tool and resource integrations across AI clients, but introduces transport serialization boundaries and requires strict client-side permission enforcement.

Primary sources

• Building Effective AI Agents — Anthropic, verified 2026-07-21
• Model Context Protocol Architecture and Tools Specification — Model Context Protocol, verified 2026-07-21