Model Context Protocol (MCP)

MCP is an open protocol that standardizes how LLM applications connect to external data sources and tools, providing a universal interface between AI models and the systems they interact with.

What It Really Means

Before MCP, every LLM application that needed to access tools — databases, APIs, file systems, code interpreters — had to build custom integrations. If you wanted your AI assistant to query a database, search the web, and send emails, you wrote three separate tool integrations, each with their own authentication, data format, and error handling.

MCP standardizes this. It defines a client-server protocol where:

• MCP Servers expose tools, resources, and prompts through a standard interface
• MCP Clients (LLM applications) discover and invoke these capabilities
• The protocol handles capability negotiation, argument validation, and response formatting

Think of MCP as the USB of AI tooling. Before USB, every peripheral needed its own proprietary connector. MCP does the same for LLM tool use — write one MCP server for your database, and every MCP-compatible client can use it.

The protocol was introduced by Anthropic in late 2024 and has gained rapid adoption across the AI ecosystem. It is particularly relevant for multi-agent systems where agents need standardized access to shared tools and data sources.

How It Works in Practice

Protocol Architecture

MCP uses a JSON-RPC 2.0 transport layer with three core primitives:

1. Tools — Functions the LLM can call (e.g., query_database, send_email)
2. Resources — Data the LLM can read (e.g., file contents, database schemas)
3. Prompts — Pre-built prompt templates for common tasks

Communication Flow

1. Initialization: Client connects to server, they exchange capability lists
2. Discovery: Client asks server what tools/resources are available
3. Invocation: LLM decides to use a tool → client sends the request to server
4. Response: Server executes the tool and returns structured results
5. Context: Results are fed back into the LLM's context for continued reasoning

Concrete Example: Database MCP Server

A team builds an MCP server that wraps their PostgreSQL database. The server exposes:

• Tool: run_query(sql: string) — execute read-only SQL queries
• Tool: list_tables() — show available tables
• Resource: schema://public — the database schema
• Prompt: analyze-table — a template for generating table analysis

Any MCP-compatible client (Claude Desktop, Cursor, custom apps) can now query this database through the same interface.

Implementation

Building an MCP Server (Python)

MCP Server Configuration

Trade-offs

When to Use MCP

• Building AI applications that need tool access
• Creating reusable tool integrations across multiple AI clients
• Standardizing tool access in multi-agent systems
• When you want tool definitions to be discoverable and self-documenting

When NOT to Use MCP

• Simple, one-off tool integrations where a direct function call suffices
• Performance-critical paths where the protocol overhead matters (sub-10ms)
• When your LLM provider's native function calling is sufficient

Advantages

• Write once, use everywhere — tool reuse across clients
• Standardized discovery — clients automatically learn available tools
• Security boundary — MCP servers run in separate processes
• Growing ecosystem of pre-built servers

Disadvantages

• Protocol overhead for simple use cases
• Still evolving — breaking changes possible
• Debugging across process boundaries is harder
• Not all LLM providers natively support MCP

Common Misconceptions

• "MCP replaces function calling" — MCP complements function calling. The LLM still uses function calling to decide which tool to invoke. MCP standardizes how the tool is connected and executed, not how the LLM decides to use it.

• "MCP servers must be remote" — MCP servers can run locally as subprocesses. The stdio transport is designed for local execution. Remote servers use SSE (Server-Sent Events) transport.

• "MCP is only for Anthropic/Claude" — MCP is an open protocol. Any LLM application can implement an MCP client. Multiple editors, IDEs, and AI applications support it.

• "Every tool needs its own MCP server" — A single MCP server can expose multiple tools and resources. Group related tools in one server.

How This Appears in Interviews

MCP is a newer topic but increasingly relevant:

• "How would you design a tool integration layer for an AI assistant?" — discuss the need for standardization, discovery, and security isolation that MCP provides. See interview questions on AI architecture.
• "What are the trade-offs of running tools in-process vs out-of-process?" — MCP's process isolation provides security but adds latency.
• "Design an AI agent that can access multiple enterprise data sources" — MCP is the natural integration layer. See our guides on AI engineering.

Related Concepts

• Multi-Agent Systems — MCP standardizes how agents access tools
• AI Guardrails — Security boundaries for tool execution
• Prompt Engineering — MCP includes prompt templates
• RAG — MCP resources can serve as RAG data sources
• LLM Serving — Infrastructure that MCP servers run alongside
• Algoroq Pricing — Practice AI infrastructure interview questions