Model Context Protocol (MCP)
The open standard for connecting models to tools and data — servers, resources, tools, and transport, and why it matters.
Introduction
Model Context Protocol, usually shortened to MCP, is an open standard originating from Anthropic for connecting LLM applications to external tools and data through a uniform client/server protocol. Instead of every IDE, chat client, agent framework, and desktop app inventing a different integration format, MCP gives them a shared way to discover capabilities, exchange messages, and call external systems.
The core idea is simple: integrations should be written once and reused across many hosts. A host application runs one or more MCP clients, and each client maintains a connection to an MCP server. The server exposes capabilities such as model-callable tools, readable resources, and reusable prompts. The model still reasons in the host, but the host can now obtain context and perform actions through standardized servers.
In interviews, MCP is a strong signal topic because it sits at the boundary between LLM product design and distributed systems. A good explanation distinguishes MCP from raw tool calling, describes the initialize and capabilities handshake, names the transports and JSON-RPC 2.0 framing, and calls out trust, permissions, and resource exposure as first-class design concerns.
Where this shows up in production
MCP shows up anywhere a product wants LLM features to reach real systems without hardcoding every integration into every app.
- AI coding assistants connect to source control, issue trackers, local files, build tools, and documentation servers.
- Enterprise copilots expose approved CRM, ticketing, wiki, calendar, and data warehouse context through reusable servers.
- Agent platforms let teams install third-party MCP servers instead of writing custom adapters for each host.
- Desktop and IDE hosts can run local stdio servers for private machine context while also connecting to remote HTTP servers for cloud services.
Learning Objectives
Explain MCP as an open client/server standard for connecting LLM hosts to tools, resources, and prompts.
Describe the host, MCP client, MCP server, and underlying external system roles.
Differentiate the three core server primitives: tools, resources, and prompts.
Understand stdio and streamable HTTP/SSE transports, JSON-RPC 2.0 framing, and the initialize handshake.
Contrast MCP with raw function or tool calling in a model request.
Identify security risks around server trust, permissions, sensitive resources, and tool authorization.
Theory & Concepts
MCP standardizes integrations around the host and server boundary
MCP treats the LLM application as a host. The host might be an IDE, desktop chat client, web chat product, agent runtime, or internal copilot. The host runs one or more MCP clients, and each client connects to exactly one MCP server over a supported transport.
The server owns an integration boundary. It might know how to read a repository, query a database, search a wiki, create a ticket, or call an internal API. The host does not need to know each service API directly. It only needs to speak MCP, discover what the server offers, and decide when to surface those capabilities to the model or user.
The M-by-N integration problem becomes M hosts plus N servers
Without a shared protocol, every host has to build a custom adapter for every external system. Five hosts and ten services can become fifty integration projects, each with its own schemas, authentication assumptions, error handling, and permission UX.
MCP changes that shape. Each host implements MCP client behavior once, and each service exposes an MCP server once. New hosts can reuse existing servers, and new servers become available to existing hosts. This does not remove product-specific policy, but it removes a large amount of repetitive transport and capability plumbing.
Tools are model-callable functions
An MCP tool is an operation the host may allow the model to call. A tool has a name, description, input schema, and result. Examples include search_issues, summarize_ticket, run_sql_readonly, create_calendar_hold, or fetch_pull_request_diff.
Tools are the closest MCP primitive to familiar LLM function calling, but the important difference is where the integration lives. In raw function calling, the application usually sends tool schemas inside a model request and executes the functions itself. In MCP, the server publishes tools through a reusable protocol, and multiple hosts can discover and call the same server-defined capability.
Resources are readable context
An MCP resource is data the application can load as context. Resources are usually addressed by a URI-like identifier and may represent files, documents, database rows, logs, tickets, dashboards, or generated views over a service.
Resources are not automatically safe just because they are read-only. A server can expose sensitive documents, private paths, or stale data if it is configured carelessly. A production host should make resource selection visible, enforce authorization outside the model, and avoid loading broad private context simply because a server can provide it.
Prompts are reusable task templates
An MCP prompt is a reusable, parameterized prompt template published by a server. Prompts let an integration package recommended workflows with the context source it understands. For example, a repository server could publish prompts for reviewing a pull request, explaining a module, or drafting a changelog from commits.
Prompts are not a replacement for the host system prompt. They are reusable assets the host may present to the user or combine with application policy. A mature host still decides priority, safety rules, model selection, and what context or tools are allowed for a given user action.
Protocol mechanics: JSON-RPC, transports, and capabilities
MCP messages use JSON-RPC 2.0 style request, response, and notification framing. The client and server begin with an initialize exchange where they negotiate protocol version and advertise capabilities. After initialization, the client can ask the server to list tools, list resources, list prompts, read a resource, get a prompt, or call a tool.
For local integrations, stdio is common: the host starts the MCP server as a subprocess and exchanges JSON-RPC messages over standard input and output. For remote integrations, streamable HTTP and SSE-style streaming support networked servers. The transport changes how bytes move, but the capability model stays consistent.
Architecture Diagram
The diagram intentionally separates the host from the server. The host owns the model conversation, user experience, policy decisions, and permission prompts. The server owns service-specific integration code and exposes a normalized MCP surface.
The MCP client is not the model. It is host-side protocol machinery. The model may propose using a tool or request context, but the host decides whether to call an MCP server, which arguments to send, whether the user must approve, and how returned data enters the model context.
Local stdio servers are attractive for private developer workflows because the host can spawn a subprocess with limited local permissions. Remote servers are attractive for shared enterprise integrations, but they require stronger authentication, tenant isolation, network controls, audit logs, and careful handling of streaming responses.
Request Flow
- 1
1. User opens a host application
The user works inside an LLM host such as an IDE, chat client, or agent console. The host has its own model configuration, system prompt, UI, account identity, and product policy. MCP does not replace that host; it gives the host a standard way to reach outside capabilities.
- 2
2. Host starts or connects MCP clients
For each configured server, the host creates an MCP client session. A local server may be launched as a subprocess over stdio. A remote server may be contacted over streamable HTTP or SSE. Each client tracks one server connection, lifecycle, and protocol state.
- 3
3. Client and server initialize
The first protocol exchange negotiates version and capabilities. The client sends initialize information, the server replies with the protocol version and supported features, and the session moves into normal operation. If versions or required capabilities do not match, the host should fail closed or degrade cleanly.
- 4
4. Host discovers capabilities
The host asks the server to list available tools, resources, and prompts. This is discovery, not automatic permission to use everything. A good host filters capabilities by user identity, workspace trust, admin policy, and whether a server is local, remote, first-party, or third-party.
- 5
5. User or model selects a capability
The model may infer that a tool would help, the user may choose a prompt, or the host may load a resource as context. The host should make the action understandable: which server is involved, what data will be sent, what operation will occur, and whether the operation is read-only or mutating.
- 6
6. Client sends a JSON-RPC request
The MCP client sends a typed request such as reading a resource, getting a prompt, or calling a tool. Arguments are serialized through JSON-RPC 2.0 framing. The server validates the request, runs integration logic, and returns structured content, errors, or progress notifications depending on the capability.
- 7
7. Host injects results into the LLM workflow
The returned data may become model context, a displayed artifact, a tool result message, or a follow-up prompt. The host should preserve provenance so the model and user can distinguish server-provided evidence from user instructions and model-generated text.
- 8
8. Host audits and enforces policy
Production hosts log the server, capability name, arguments, user identity, approval decision, response status, latency, and errors. For sensitive or mutating actions, the host should require explicit approval, apply allowlists, and keep enough audit data to investigate misuse.
Deep Dive
MCP is not the same as function calling
Function calling is usually a model API feature: the application supplies a set of function schemas in the model request, the model selects a function-like call, and the application executes local code. That is powerful, but the schema and execution path are often specific to one app.
MCP is an integration and transport standard. It defines how hosts discover and call capabilities from servers outside the model request. A host may still translate MCP tools into whatever tool-calling format its chosen model provider expects. MCP standardizes the application-to-integration boundary, not the model provider interface itself.
Capability discovery changes product UX
Because servers can list tools, resources, and prompts at runtime, a host can build dynamic UI around installed integrations. Users can inspect what a server offers, approve a specific operation, or choose a reusable prompt exposed by a domain-specific server.
The risk is overexposure. A server with hundreds of tools or broad resource roots can overwhelm both the user and the model. Good hosts rank, filter, group, and describe capabilities rather than dumping every server action into the model context on every turn.
Transports affect trust and operations
Stdio is simple for local integrations because the server runs as a child process of the host. It is easy to install, works offline, and can access local developer context when allowed. It also means the host is executing code on the user's machine, so package trust, path configuration, and environment variables matter.
Remote HTTP or SSE-style transports make shared enterprise servers easier to operate, patch, observe, and govern. They also introduce network failures, authentication flows, rate limits, multi-tenant authorization, and data residency questions. The protocol is uniform, but the operational risk profile is not.
Resources need provenance and least privilege
A resource can look harmless because it is read-only, but reading the wrong thing into an LLM context can leak secrets or create prompt injection risk. Files, tickets, documents, and dashboards may contain instructions that should be treated as data, not policy.
Production designs should scope resource roots, require user authorization, label resource origin, and avoid blindly loading large or sensitive context. The host should also protect higher-priority instructions from being overridden by content that came from a resource.
Errors and partial results are normal
MCP servers are integrations, and integrations fail. A tool call can time out, a resource can disappear, a remote server can rate limit, or a local subprocess can crash. The host should render errors in a way the model and user can act on instead of silently retrying until state changes unexpectedly.
For mutating tools, idempotency and confirmation are especially important. If a create_ticket call times out after reaching the external API, a retry might create duplicates unless the server or host uses request ids, deduplication keys, or an explicit read-after-write verification step.
Production Considerations
Server trust and supply chain
Installing an MCP server is closer to installing an integration plugin than adding a prompt snippet. A local server may execute code on the user's machine, and a remote server may receive sensitive context. Enterprises need allowlists, provenance checks, version pinning, package review, and clear ownership for every approved server.
Permission prompts and approval design
The host should ask for approval at the right granularity. Reading a known public README is different from reading a private directory. Searching tickets is different from closing a ticket. Permission prompts should show the server name, capability name, arguments, data scope, and whether the action is read-only or mutating.
Observability and audit logs
Log capability discovery, tool calls, resource reads, prompt usage, transport errors, latency, approval outcomes, user identity, workspace identity, and server version. These logs help debug model behavior, investigate data access, and prove that the host enforced policy rather than letting the model act freely.
Timeouts, retries, and graceful degradation
A slow server should not stall the whole chat or IDE. Hosts need request timeouts, cancellation, bounded retries, and clear fallback behavior. Remote servers should return structured errors and rate-limit information. Local servers should be restarted only when safe, with crash loops surfaced to the user instead of hidden.
Interview Perspective
What interviewers look for
- ✓A precise definition of MCP as an open client/server standard for LLM integrations, not another model architecture.
- ✓Clear architecture language: host runs MCP clients, each client connects to an MCP server, and the server exposes tools, resources, and prompts.
- ✓Understanding of protocol mechanics: stdio and HTTP/SSE transports, JSON-RPC 2.0 messages, initialize handshake, and capability discovery.
- ✓Security maturity around server trust, permission prompts, least-privilege resources, and not treating prompts as access control.
Alternative designs
Direct app integrations
The host directly implements every service integration. This gives maximum control and can be best for a small number of first-party, deeply integrated workflows. It scales poorly when many hosts and many services need to interoperate because each pair needs custom code and maintenance.
Provider-specific tool schemas only
The application describes tools directly in each model request using one provider's function-calling format. This is straightforward for a single app and a fixed model provider. It becomes less reusable when multiple hosts, model providers, or external service teams need a shared integration surface.
Plugin marketplace without a shared protocol
A marketplace can solve discovery and distribution but still leave each plugin with custom runtime contracts. MCP is lower level: it defines how a host and server communicate. A marketplace can sit on top of MCP, but the protocol is what makes server capabilities portable across hosts.
Likely follow-up questions
How is MCP different from raw function calling?
Raw function calling is usually defined inside a model provider request: the app sends tool schemas, the model emits a tool call, and the app executes local code. MCP is a reusable integration protocol between a host and external servers. A host may translate MCP tools into provider-specific function calls, but MCP standardizes discovery, transport, and server reuse across hosts.
What are the three core MCP server primitives?
Tools are model-callable operations. Resources are readable data or context the app can load. Prompts are reusable, parameterized prompt templates published by a server. A mature host treats these differently because calling a tool, reading a resource, and applying a prompt have different user experience and security implications.
Why does MCP reduce the M-by-N integration problem?
Each host implements MCP client behavior once, and each external system can expose one MCP server. Instead of every host writing a custom integration for every service, hosts and servers meet at a shared protocol. Product policy still differs by host, but the transport, discovery, and capability model are reusable.
What should a host do before allowing a tool call from an MCP server?
The host should verify that the server is trusted, the user is authorized, the capability is allowed in this workspace, the arguments are understandable, and the action is safe or explicitly approved. For mutating tools, the host should show a permission prompt and log the decision, arguments, result, and external system status.
Common mistakes
- ×Calling MCP a model feature instead of an application integration protocol.
- ×Forgetting that the host runs clients and owns policy; the MCP server exposes capabilities but should not decide all user-facing safety behavior.
- ×Dumping every discovered tool and resource into model context without filtering, ranking, or permission checks.
- ×Assuming read-only resources are automatically safe to expose to an LLM.
Interactive Playground
This static playground frames MCP as a host design choice. The same external ticketing integration can be exposed as a reusable MCP server instead of hardcoded into one chat product.
System prompt
You are designing an enterprise LLM host that supports MCP integrations. Explain integration choices in terms of reuse, trust, capability discovery, and user permissions. Do not assume that a server is trusted just because it implements MCP.
User prompt
Scenario: The support team wants an AI assistant to summarize tickets and draft replies from the company ticketing system. Compare two options: 1. Build a one-off ticketing integration directly inside the host. 2. Build a ticketing MCP server exposing read_ticket, search_tickets, and draft_reply_prompt. Return a concise recommendation with security checks.
transport
streamable_http
A remote shared server fits a centrally operated enterprise ticketing integration.
capability_scope
read_ticket, search_tickets, draft_reply_prompt
Expose a narrow set first instead of the full ticketing API.
permission_mode
prompt_on_sensitive_read
Ask for approval when reading private or customer-sensitive tickets.
audit_fields
user, server, capability, arguments, approval, status
The host and server should both leave an investigation trail.
Sample output
Recommendation: use an MCP server if the ticketing integration should be reused by multiple hosts or teams. The host should still control which users can access the server, which tools are visible, when approval is required, and how ticket data is inserted into model context.
Security checks:
- Approve the server package and owner.
- Scope ticket reads by user role and workspace.
- Display the tool name and ticket ids before sensitive reads.
- Treat ticket text as data, not instructions.
- Log capability calls and returned status.
Visual Learning
MCP server primitives
| Primitive | What it exposes | Best use | Main risk |
|---|---|---|---|
| Tools | Callable operations with schemas and results | Searching, creating, updating, or computing through external systems | Mutating actions can be triggered without clear approval |
| Resources | Readable data or context addressed by identifiers | Files, documents, tickets, database views, logs, and dashboards | Sensitive or untrusted content may enter the model context |
| Prompts | Reusable parameterized prompt templates | Shared workflows such as review, summarize, explain, or draft | Template priority can be confused with host policy |
Transports and deployment shapes
| Transport | Typical deployment | Best fit | Tradeoff |
|---|---|---|---|
| stdio | Local subprocess started by the host | Developer tools, local files, CLIs, private machine context | Local code execution and environment trust matter |
| streamable HTTP | Remote server reached over the network | Shared enterprise integrations and centrally operated services | Requires authentication, tenancy, rate limits, and network resilience |
| SSE-style streaming | Remote endpoint that can stream events | Long-running operations or incremental updates | More operational complexity and connection handling |
MCP versus nearby patterns
| Pattern | Where the contract lives | Reuse model | When to choose it |
|---|---|---|---|
| MCP | Between host clients and MCP servers | One server can serve many hosts | When integrations should be portable across LLM applications |
| Raw function calling | Inside a model provider request | Usually specific to one app and provider path | When a single app owns the tools and execution loop |
| Direct REST integration | Inside host application code | Reusable only if the app team packages it separately | When tight product control matters more than portability |
| Plugin API | Inside a host-specific extension runtime | Reusable mainly within that host ecosystem | When distribution and UI extension points are host-specific |
Decision guide
Choosing when to use MCP
Use MCP when a capability should be reused across more than one LLM host, when service teams want to own their integration code, or when a product needs runtime discovery of tools, resources, and prompts.
Use raw function calling when one application owns a small set of tools and does not need portability. It is often simpler for a single product workflow, especially when the tool code already lives beside the model orchestration layer.
Use direct integrations when the host needs deep, custom UX and policy that would be awkward to express through a generic server. This can be right for first-party flagship features, but it does not scale well across many services and hosts.
Prefer stdio for local developer or desktop workflows where the server needs local context and can be installed with clear trust boundaries. Prefer remote HTTP/SSE when a company wants centralized operations, shared credentials, audit controls, and consistent updates.
Before adopting any MCP server, answer four questions:
- Who owns and updates the server?
- What tools, resources, and prompts does it expose?
- What data can leave the host and what data can enter the model context?
- Which actions require user approval, admin approval, audit logging, or complete blocking?
Hands-on Examples
Sketch a minimal MCP server exposing one tool
This Python sketch uses the MCP Python SDK style to expose a single read-only tool. In a real server, replace the in-memory dictionary with an authorized service call and keep the transport, permissions, and audit behavior explicit.
server.py
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("workspace-helper")
@mcp.tool()
def summarize_ticket(ticket_id: str) -> str:
tickets = {
"INC-1001": "Checkout errors increased after deploy 42. Rollback completed.",
"INC-1002": "Search latency is high in region west. Index rebuild is in progress."
}
details = tickets.get(ticket_id)
if details is None:
return "Ticket not found: " + ticket_id
return "Ticket " + ticket_id + ": " + details
if __name__ == "__main__":
mcp.run(transport="stdio")Configure a host to start the local server
A local stdio server is commonly registered in host configuration. The important product details are not just the command and arguments; the host should also know whether the workspace trusts this server and what capabilities should be visible to the model.
mcp_config.json
{
"mcpServers": {
"workspace-helper": {
"command": "python",
"args": ["server.py"],
"env": {
"READ_ONLY": "true"
}
}
}
}Quiz
0/6 answered
1.What problem does MCP primarily solve?
2.Which architecture description is correct?
3.Which list names the three core MCP server primitives?
4.What protocol mechanics are central to MCP?
5.How should you contrast MCP with raw function calling?
6.Which security practice is most appropriate for MCP?
Flashcards
Cheat Sheet
Model Context Protocol cheat sheet
Definition
- MCP is an open standard for connecting LLM applications to external tools and data through a uniform client/server protocol.
- It originated from Anthropic and is designed so integrations can be written once and reused across hosts.
- MCP is about the application integration boundary, not about changing transformer architecture.
Roles
- Host: the LLM app, such as an IDE, chat client, desktop app, or agent runtime.
- MCP client: host-side session that connects to one server.
- MCP server: integration process or service that exposes capabilities.
- Underlying systems: files, CLIs, databases, SaaS APIs, internal services, and knowledge stores.
Server primitives
- Tools: callable operations the host may let the model invoke.
- Resources: readable data or context the host can load.
- Prompts: reusable parameterized prompt templates.
Protocol mechanics
- Messages use JSON-RPC 2.0 style request, response, and notification framing.
- Sessions start with initialize and capability negotiation.
- Local servers commonly use stdio.
- Remote servers use streamable HTTP or SSE-style streaming.
- Capability discovery lets hosts list tools, resources, and prompts at runtime.
MCP versus function calling
- Function calling usually describes provider-specific tool schemas in a model request.
- MCP describes how a host connects to reusable external servers.
- A host can expose MCP tools to a model through function calling, but the concepts live at different layers.
Security checklist
- Trust the server before installing or connecting.
- Scope tools and resources by user, workspace, and admin policy.
- Prompt for sensitive reads and mutating actions.
- Treat resource content as data, not instructions.
- Log server, capability, arguments, approval, result, latency, and errors.
- Do not expose broad local files, secrets, or private systems blindly.
Interview answer shape
- Define MCP as an open client/server integration standard.
- Name host, MCP client, MCP server, and underlying system roles.
- Explain tools, resources, and prompts.
- Mention stdio, HTTP/SSE, JSON-RPC 2.0, and initialize/capabilities.
- Contrast MCP with raw function calling.
- Close with permissions, trust, least privilege, and auditability.
References
- DocsModel Context Protocol Introduction — Model Context Protocol
- DocsModel Context Protocol Specification — Model Context Protocol
- BlogIntroducing the Model Context Protocol — Anthropic
- DocsMCP Python SDK — Model Context Protocol