What is MCP, and why does agent tooling need a protocol?
- 2 min — what and why: N×M → N+M; governance as of Oct 2026
- 3 min — host/client/server; tools, resources, prompts; sampling, roots, elicitation
- 2 min — transports and OAuth 2.1
- 3 min — trust: vetting, least privilege, description drift, token cost
- 2 min — ownership: system teams publish, platform governs
The Model Context Protocol is an open standard, introduced by Anthropic in November 2024 and donated in December 2025 to the Agentic AI Foundation under the Linux Foundation, for connecting AI applications to tools and data. It is JSON-RPC 2.0 between a host (the AI app), its clients (one per connection) and servers.
- Server features: tools (model-invoked functions), resources (application-controlled data addressed by URI), prompts (user-selected templates).
- Client features: sampling (server asks the host's model for a completion), roots (filesystem/URI boundaries the server may work within), elicitation (server asks the user for structured input mid-task; added in the 2025-06-18 revision).
- Transports: stdio for local servers; Streamable HTTP for remote servers (2025-03-26 revision, replacing HTTP+SSE).
- Authorization: OAuth 2.1-based for HTTP transports; the server acts as an OAuth resource server and tokens must be audience-bound to it — passing a client's token through to upstream APIs is explicitly disallowed.
It turns an N hosts × M integrations problem into N + M.
A company wraps its ticketing system, engineering wiki and metrics store as three remote MCP servers. The IDE assistant, the chat assistant and a custom triage agent all consume them with no per-app glue; the observability team maintains one metrics connector instead of four. The metrics server exposes 6 tools and a metrics://service/{name}/slo resource; the wiki server uses elicitation to ask the user which space to search when a query is ambiguous rather than guessing.
A protocol standardises plumbing, not trust. Every server is code you run and descriptions you feed the model, so: vet servers like dependencies (pin versions, review tool descriptions on update — a changed description is a prompt-injection vector), give each server least-privilege credentials, authorise per user via OAuth rather than a shared service token, and log every call with the user principal. Context cost is real: 5 servers × 15 tools × ~200 tokens ≈ 15k tokens of definitions per turn before any work — load per route or on demand.
Org scope. Each system-owning team publishes and operates its MCP server (they know the API and its failure modes); a platform team runs the gateway or registry (allow-list, OAuth integration with the corporate IdP, rate limits, audit) and the description review. Build vs buy: use vendor-published servers for SaaS tools only after review; build internal ones on the official SDKs. Roll out by allow-list per host — not “any server a developer pastes into a config”. Failure mode: an unvetted community server with broad tokens becomes the exfiltration path.
What the answer sounds like at each level
MCP is a standard way to plug tools into AI apps so one connector works everywhere.
Explains host/client/server, the three server primitives and three client features, stdio vs Streamable HTTP, and OAuth 2.1 with audience-bound tokens.
Runs MCP as governed infrastructure: system owners publish servers, a platform registry enforces allow-lists, auth and audit, and tool-definition token cost is managed per route.
Follow-ups the interviewer will push
1What is sampling for, and what is its risk?
It lets a server use the host's model without its own API key (e.g. summarise a fetched page). Risk: a server can craft prompts that run on the user's model and budget — hosts should show or gate sampling requests and cap their tokens.
2Now a server you depend on updates its tool descriptions overnight. What protects you?
Version pinning, a diff of tool definitions on update with review before the new version is allowed, and an eval run on the agent's task set — a description change can redirect tool selection or carry injected instructions.
3Resources vs tools: when would you use a resource?
When the application or user decides what context to attach (a file, a dashboard snapshot) rather than the model deciding to act. Resources are read-only, URI-addressed context; tools are model-invoked actions.
Red flags interviewers listen for
- Describes MCP as a model or an agent framework rather than a protocol.
- Proposes one shared service token for all users of a remote server.
- Claims MCP makes connected tools safe by default.
How it's scored
| Dimension | What strong looks like |
|---|---|
| Protocol accuracy | Correct primitives, client features, transports and auth model, dated to spec revisions. |
| Security | Per-user OAuth, no token passthrough, description review, least privilege. |
| Cost awareness | Quantifies tool-definition tokens and loads per route. |
| Org scope | Publishing vs governing ownership split; allow-listed rollout. |
Sources
- Model Context Protocol specification — MCP maintainers, 2025spec