Model Context Protocol (MCP)#

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#

Client                          Server
  │                               │
  │── initialize ──────────────>  │  Exchange capabilities
  │<─ initialized ─────────────   │
  │                               │
  │── tools/list ──────────────>  │  Discover available tools
  │<─ {tools: [...]} ──────────   │
  │                               │
  │── tools/call ──────────────>  │  Execute tool
  │   {name, arguments}           │
  │<─ {content: [...]} ────────   │  Return result

Core Architecture#

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