Model Context Protocol (MCP)#

Executive Summary#

Model Context Protocol (MCP) is an open protocol, introduced by Anthropic in November 2024, that standardizes how AI applications expose tools, resources, and prompts to language models. MCP solves the M×N integration problem: without a standard protocol, every AI application must build custom integrations with every data source and tool system — a combinatorial complexity that does not scale. With MCP, each data source or tool system exposes a standard MCP server; any MCP-compatible AI application connects to it once. This chapter covers MCP's architecture, server design patterns, client integration, and enterprise deployment considerations. AI architects evaluating integration strategies and engineers building MCP servers for enterprise tool ecosystems should read this chapter.

Learning Objectives#

• Explain MCP's role in solving the M×N integration problem
• Describe MCP's three primitive types: Tools, Resources, and Prompts
• Implement an MCP server exposing clinical data tools using the Python SDK
• Configure an MCP client connection in a Claude-powered application
• Identify the security and authorization considerations for MCP in enterprise environments

Business Problem#

A Reference Healthcare Organization's AI platform integrates with eight backend systems: Epic EHR via FHIR R4, a formulary database, a clinical guidelines library, a laboratory results system, a radiology reporting system, a scheduling system, a billing system, and a compliance audit log. Without a standardized protocol, each integration requires custom code: custom authentication handling, custom serialization, custom error handling, and custom schema definition — multiplied by the number of AI applications consuming these integrations.

MCP replaces this multiplication with addition: each backend system exposes one MCP server; each AI application connects to the servers it needs through one standard client interface. When a new backend system is added, it requires only one new MCP server. When a new AI application is added, it connects to existing servers immediately.

Why This Technology Exists#

The pre-MCP landscape for AI tool integration mirrors the pre-REST landscape for web APIs: every system had its own integration pattern, every consumer needed system-specific knowledge, and integration complexity scaled with the number of systems and consumers.

REST (and later OpenAPI) standardized HTTP-based API design, dramatically reducing integration overhead. MCP applies the same standardization logic to the tool-and-context interface between AI applications and the systems they access.

MCP builds on the Language Server Protocol (LSP) design precedent from developer tooling, where a standard protocol between editors and language servers allowed any editor to support any language without bilateral integration work.

Conceptual Explanation#

MCP Primitives#

MCP defines three primitives:

Tools: Functions the AI model can call with arguments to perform actions or retrieve data. Tools are the MCP equivalent of LLM function/tool calls — they have a name, description, and input schema. Tool execution has side effects and produces results. Example: get<em>patient</em>summary(patient<em>id), check</em>drug<em>interaction(drug</em>a, drug_b).

Resources: Read-only data sources the AI model can reference. Resources are identified by URIs and provide content (text, binary) that the model can include in its context. Example: clinical://guidelines/sepsis-management, patient://P-12345/current-medications.

Prompts: Reusable prompt templates the server exposes. Prompts can be parameterized and composed. Example: a discharge summary prompt template that the server provides with configurable patient context fields.

MCP Transport#

MCP supports two transports:

• stdio: Server runs as a subprocess; client communicates via stdin/stdout. Simple; appropriate for local tool access.
• HTTP with SSE (Server-Sent Events): Server runs as a service; client connects via HTTP. Required for multi-user, remotely hosted MCP servers.

Connection Lifecycle#

Implementation code omitted in the Playbook edition. For complete code examples, production patterns, and advanced implementation details, see the Enterprise AI Technical Reference.

Core Architecture#

Enterprise Considerations#

Authorization model. MCP servers accept tool calls from any authenticated client. In enterprise deployments, the server must enforce authorization at the tool level: which clients (AI applications) are permitted to call which tools, and for which data scope. A clinical data MCP server used by both a general-purpose assistant and a specialized prior authorization agent should not grant both the same tool access.

Multi-tenant server design. A single MCP server can serve multiple AI applications. Design the server to accept a client identity token (from the MCP connection or request metadata) and enforce per-client authorization policies. Do not rely on the AI application to self-limit its tool use.

Stateless vs. stateful servers. MCP servers should be stateless where possible — each tool call is independent and does not depend on prior session state. Stateful servers (maintaining session context across calls) are harder to scale horizontally and introduce failure modes when sessions are lost.

Registry and discovery. In an enterprise with many MCP servers, establish a central MCP server registry. AI applications query the registry to discover which servers are available and what capabilities they expose. This prevents hardcoded server lists in application configuration.

Healthcare Example#

A Reference Healthcare Organization's MCP architecture deploys five MCP servers:

Each AI application declares which MCP servers it needs. The organization's central gateway enforces that AI applications only connect to authorized servers. The EHR server enforces SMART on FHIR scopes so the prior authorization agent can only access patient data for the encounter it is processing.

Common Mistakes#

No tool authorization at the server. Expecting the AI application to not call tools it should not use is not a security boundary. The MCP server must enforce authorization independent of the client's intentions.

Including PHI in tool descriptions. Tool descriptions are static metadata visible to all clients. Never include patient-specific data, example PHI, or data that varies by request in tool descriptions.

Synchronous blocking in async server. MCP servers are typically async. Calling synchronous blocking I/O (database queries, HTTP requests without async) in an async MCP handler blocks the event loop and degrades throughput under concurrent requests.

No error schema. Tool handlers that return unstructured error messages make it difficult for the LLM to reason about recoverable versus unrecoverable errors. Define a consistent error response schema (with error_code, message, recoverable fields) and apply it in every tool handler.

Best Practices#

• Design MCP tool descriptions as if writing for an intelligent engineer unfamiliar with your system — precision and completeness matter for LLM comprehension
• Enforce tool authorization at the server level, not the client level
• Make MCP servers stateless where possible for horizontal scalability
• Define consistent error response schemas across all tools on a server
• Establish a central MCP server registry for enterprise discoverability
• Validate third-party MCP server tool descriptions before production deployment
• Use HTTP+SSE transport for multi-user, remotely hosted MCP servers; stdio only for local single-process tools

Alternatives#

Interview Questions#

Q1: What problem does MCP solve, and why does it matter at enterprise scale?#

Category: Architecture Difficulty: Mid-level Role: AI Architect / ML Engineer

Answer Framework:

MCP solves the M×N integration problem. Without a standard protocol, M AI applications integrating with N tool/data systems requires M×N integrations, each with custom authentication, serialization, and error handling. At enterprise scale — say, 10 AI applications and 20 data systems — that is 200 integration pairs.

With MCP, each data system exposes one standard MCP server (N servers); each AI application connects to the servers it needs through one standard client interface (M clients). Adding a new data system requires building one MCP server, not one integration per AI application. Adding a new AI application requires only configuring which existing servers it connects to.

Beyond the integration math, MCP provides a uniform tool discovery mechanism (list_tools), a standard authorization point (the server), and a consistent error contract — all of which reduce the operational overhead of maintaining AI integrations in production.

Key Points to Hit:

• M×N reduction to M+N is the core value proposition
• Standard discovery (list_tools) enables dynamic tool discovery without hardcoded schemas
• Authorization is enforced at the server, making it a proper security boundary
• The protocol builds on LSP's precedent in developer tooling

Q2: What are the three MCP primitive types, and what is each used for?#

Category: Architecture Difficulty: Junior Role: ML Engineer

Answer Framework:

Tools are callable functions that perform actions or retrieve data and can have side effects. They have a name, description, and input schema. The LLM calls tools by name with arguments; the server executes them and returns results. Tools are the primary way agents interact with external systems.

Resources are read-only data sources identified by URIs. They provide content (text, binary) that the model can include in its context without executing a function call. Resources are appropriate for static or infrequently-updated content: configuration, reference documents, templates. A clinical guidelines index or a drug formulary catalog is a good resource use case.

Prompts are reusable, parameterized prompt templates that the server exposes. They allow server-side prompt management: the server defines standard prompts (e.g., "discharge summary generation") with required fields, and clients instantiate them with specific values. This keeps prompt logic close to the data it operates on.

Key Takeaways#

• MCP solves the M×N integration problem: N backend systems expose MCP servers; M AI applications connect via standard client interfaces
• Three MCP primitives: Tools (callable functions with side effects), Resources (read-only data by URI), Prompts (reusable parameterized templates)
• Two transports: stdio (local subprocess) and HTTP+SSE (remote, multi-user)
• Tool authorization must be enforced at the MCP server level — the client is not a security boundary
• MCP tool descriptions are rendered in LLM context — treat them with the same rigor as system prompts
• Design MCP servers to be stateless for horizontal scalability

Further Reading#

In This Repository:

• Tool Design Patterns — Tool schema design principles applicable to MCP tool definitions
• Multi-Agent Systems — MCP as an integration layer for multi-agent architectures
• Agentic Security — MCP server security, tool description injection, authorization

External References:

• modelcontextprotocol.io — official MCP specification and SDK documentation
• Anthropic MCP announcement (November 2024) — background and design rationale

Previous: Agent Observability | Next: Agentic Security