Model Context Protocol (MCP): Architecture Explained Interview Prep

MCP vs Raw Function Calling vs LangChain Tools — Tool Interface Trade-offs

Sample interview questions

1. What is the key difference between MCP Tools and MCP Resources?
   • A. Tools are read-only; Resources are read-write.
   • B. Tools are callable functions with typed input schemas that perform actions or computations; Resources are addressable data objects (files, database rows, API responses) that the model can read via URI. ✓
   • C. Tools are available only via stdio transport; Resources require Streamable HTTP.
   • D. Tools are registered at startup; Resources are discovered dynamically during the session.

   Option B is correct. The MCP specification draws a clear functional boundary: Tools are typed callables — they have an input schema, accept arguments, execute an action or computation, and return a result. They are the mechanism for agents to take actions in the world (search the web, query a database, run code). Resources are addressable data objects identified by URI (e.g., file:///docs/api.md or postgres:///tables/users/1234) that the model can read, subscribe to, or list. Resources are typically read-only data sources; Tools are the action interface. Option A is wrong. Resources are not inherently read-write — in fact, most MCP Resource implementations are read-only. Write operations are exposed as Tools, not Resources, because writes have side effects that require explicit invocation with an input schema. Option C is wrong. Both Tools and Resources can be served over either transport (stdio for local/process-based servers, Streamable HTTP for remote servers). The transport choice is independent of the capability type. Option D is wrong. Both Tools and Resources are registered on the MCP server and discovered by the client during the capability negotiation (initialize request) at session start. Neither is uniquely "dynamic" during the session. Production reality: a well-designed MCP server exposes read-only data (codebase files, documentation, database records) as Resources and side-effecting operations (code execution, API calls, database writes) as Tools. This separation makes it easier to enforce least-privilege authorization: read-only clients get Resource access; agents with write permissions get Tool access.

2. How does capability negotiation work in MCP at session start?
   • A. The client sends a list of all tools it needs, and the server returns only those tools.
   • B. The client sends an initialize request; the server responds with its supported protocol version and a list of available capabilities (tools, resources, prompts). The client then confirms with an initialized notification before sending any further requests. ✓
   • C. The server advertises its capabilities over a broadcast channel before the client connects.
   • D. Capability negotiation happens only when the client calls a tool that does not exist on the server.

   Option B is correct. The MCP initialization handshake follows this sequence per the specification (modelcontextprotocol.io): (1) the client sends an initialize request containing the protocol version it supports and its own capabilities; (2) the server responds with a protocol version (if it cannot speak the client's requested version it replies with its own latest supported version, and the client disconnects if it cannot use it) and a capabilities object naming the capability categories it supports — e.g. tools, resources, prompts, each with sub-capabilities like listChanged — not the concrete items themselves (those are fetched later via tools/list, resources/list, prompts/list); note that sampling is a client capability, not a server one; (3) the client sends an initialized notification to confirm the handshake is complete; (4) subsequent requests can now use the negotiated capabilities. This two-step initialize/initialized pattern ensures both sides have consistent expectations before any tool calls or resource reads occur. Option A is wrong. The client does not pre-specify which tools it needs — the server declares what it offers, and the client discovers available capabilities from that declaration. Option C is wrong. MCP servers do not broadcast over a pub/sub channel. The initialization is a direct client-server request-response pattern. Option D is wrong. Capability negotiation happens at session start, not lazily when a missing capability is called. Calling a non-existent tool produces a method-not-found error, not a negotiation. Production reality: capability negotiation is what makes MCP composable — an agent can connect to any MCP server and discover what it can do, without hard-coded knowledge of that server's capabilities. This is the core portability advantage of MCP over ad hoc function-calling schemas.

3. When is MCP worth the added overhead compared to implementing raw function calling directly in your agent?
   • A. MCP is always preferable — raw function calling should never be used in production.
   • B. MCP earns its overhead when you need tool portability across multiple agents, standardized auth enforcement at the server boundary, or capability discovery without hard-coded tool lists per agent. ✓
   • C. MCP is only useful for agents that need to read files from the local filesystem.
   • D. MCP is worthwhile only for large enterprises; small teams should use raw function calling.

   Option B is correct. MCP adds overhead in the form of a protocol layer (the initialize handshake, JSON-RPC message framing, and transport setup). That overhead is justified when: (1) portability — you have multiple agents or agent frameworks that all need to use the same tool, and implementing the tool once as an MCP server lets all of them use it without per-agent integration; (2) standardized auth — MCP's server-client boundary is a natural place to enforce auth tokens, rate limits, and capability scoping, whereas raw function calling embeds auth logic inside each tool schema; (3) discovery — agents can dynamically discover what an MCP server offers without being pre-configured with a hard-coded tool list. For a single agent with a stable, small set of tools that will never be shared, raw function calling is simpler. Option A is wrong. Raw function calling is the right choice for simple, single-agent use cases with tools that will not be reused across contexts. Forcing MCP where raw calls suffice adds unnecessary complexity. Option C is wrong. MCP supports arbitrary data sources and action types — web search, database access, API calls, code execution — not just filesystem access. Resources can expose any URI-addressable data. Option D is wrong. MCP portability benefits scale with the number of agents and tool reuse opportunities, not with company size. A small team with two agents sharing the same tools benefits from MCP just as much as a large enterprise. Production reality: the LangChain tool interface and Vercel AI SDK tool definitions are both compatible with MCP adapters, making migration from raw function calling to MCP incremental rather than a rewrite.

4. How do you enforce least-privilege at an MCP tool boundary?
   • A. Least-privilege is not possible with MCP because all clients get all tools.
   • B. At the MCP server, validate auth tokens in each tool handler and scope tool availability per client identity: some clients get read-only Resources, others get specific Tool subsets based on their auth claims. ✓
   • C. Least-privilege in MCP is handled by the transport layer — stdio transport is more secure than Streamable HTTP.
   • D. Remove sensitive tools from the server and provide separate servers per client with only the tools they need.

   Option B is correct. MCP's server-client architecture provides a natural enforcement point for least-privilege: the server receives each request with auth context (token in HTTP Authorization header for Streamable HTTP transport, or process-level identity for stdio), validates the caller's identity, and grants access to only the tools and resources that the caller is authorized to use. This can be implemented by: filtering the tools/resources listed in the capabilities response based on the caller's auth claims, rejecting tool calls that the caller does not have permission for with a standard error response, and scoping resource URIs to paths the caller owns (e.g., only their workspace files). Option A is wrong. MCP does not require all clients to receive all tools. The server is responsible for auth enforcement and can return different capability sets to different clients. Option C is wrong. Transport security (TLS for Streamable HTTP, process isolation for stdio) is about channel security, not capability scoping. Both transports require application-level auth enforcement for least-privilege. Option D is wrong. Running separate servers per client is one implementation strategy but it does not scale well and is harder to maintain than a single server with per-client auth filtering. The standard approach is auth filtering within a single server. Production reality: treat each MCP tool invocation like an API call: validate the auth token, check authorization against a permission model, reject unauthorized calls with 401/403-equivalent errors, and log every invocation for audit trails.

5. Your MCP server's search tool is called many times per session and each call takes 800ms against an external API. How do you add tool-result caching?
   • A. Move the search tool to a faster machine — latency is a hardware problem.
   • B. Implement a server-side cache keyed on the tool input arguments: for identical search queries within a TTL window, return the cached result without calling the external API. Use TTL appropriate to the freshness requirements of the search data. ✓
   • C. Enable MCP's built-in cache flag in the tool definition schema.
   • D. Use prompt caching to cache the tool result in the LLM's KV cache.

   Option B is correct. Tool-result caching for idempotent tools (tools where the same arguments always produce the same result within a time window) is implemented at the MCP server level: the server maintains an in-memory or distributed cache (e.g., Redis) keyed on the normalized tool arguments. When a request arrives, the server checks the cache first; on a hit, it returns the cached result immediately without calling the external API. The TTL is set based on the acceptable staleness of the data — a web search result might have a 5-minute TTL, while a stock price might need a 10-second TTL. The caching is transparent to the MCP client (agent). Option A is wrong. 800ms latency for a network API call is not a hardware problem. Caching eliminates the network round-trip for repeated queries, which is the highest-impact optimization. Option C is wrong. MCP does not have a built-in cache flag in the tool definition schema as of the current specification. Caching is the server implementer's responsibility, not a protocol feature. Option D is wrong. Prompt caching (LLM KV-level caching) caches the token computations for a stable prompt prefix. It does not cache tool results, and tool results are typically in the dynamic part of the prompt that changes per turn. Production reality: a Redis-backed tool-result cache with appropriate TTLs is the standard pattern for high-volume MCP servers. For search tools specifically, deduplicate queries (normalize whitespace and case before cache key computation) to maximize hit rate.

6. An agent using an MCP tool with broad file-write access has overwritten production configuration files. What architectural failure allowed this?
   • A. The agent's LLM was too large and its capabilities exceeded what the tool was designed for.
   • B. The MCP tool lacked a path-scoping constraint and auth boundary enforcement: the tool accepted any file path without validating that the caller was authorized to write to that path, and the agent was not restricted to a sandboxed path subset. ✓
   • C. The MCP transport was using Streamable HTTP, which does not support path-level access controls.
   • D. The capability negotiation step was skipped, causing the agent to have broader access than intended.

   Option B is correct. The failure has two layers: (1) the tool schema accepted any file path without input validation, making it trivial for the agent to generate a path to a production config file; (2) the server did not enforce an auth-boundary check — it did not validate that the agent's identity was authorized to write to paths outside a designated workspace. A correctly designed file-write tool should: validate the path against an allowlist of permitted write prefixes (e.g., /workspace/ or /tmp/agent-output/), reject any path that resolves outside the allowlist after normalization (preventing path traversal attacks), and log every write operation with the caller's identity. Option A is wrong. The model's capability level does not cause this failure. Any agent — large or small — that has an unrestricted file-write tool can overwrite any accessible file if the tool schema allows it. Option C is wrong. Streamable HTTP transport does not determine path-level access controls. Both stdio and Streamable HTTP transports can enforce path-level auth if the server implements it; both are equally vulnerable if they do not. Option D is wrong. Capability negotiation lists available tools; it does not scope tool access at the input argument level. Skipping negotiation is a protocol violation but not the cause of the described incident. Production reality: file-write tools in production agents should always implement path allowlisting and input normalization (resolving .. and symlinks before allowlist check). This is the single most common source of agent-caused data loss incidents in coding agent deployments.

7. How does MCP relate to A2A (Agent-to-Agent) protocols, and why does that distinction matter when designing a multi-agent system?
   • A. MCP and A2A are interchangeable — either protocol can be used for both tool calls and agent-to-agent handoffs.
   • B. MCP is the de-facto standard for LLM-to-tool communication; A2A is the emerging class of protocols for agent-to-agent task handoff. Using MCP for inter-agent calls works in practice but conflates the two concerns and makes the system harder to evolve as A2A matures. ✓
   • C. A2A is a superset of MCP — adopting A2A replaces the need for MCP in any agent system.
   • D. MCP handles synchronous tool calls; A2A handles asynchronous tool calls. The choice depends only on latency requirements.

   Option B is correct. MCP and A2A address two distinct integration surfaces in a multi-agent system. MCP (modelcontextprotocol.io) is the Anthropic-originated, now multi-vendor protocol for how an LLM client connects to tool servers: capability discovery, tool invocation, resource reads, and prompt templates. It is widely adopted and has become the de-facto standard for tool exposure — Claude Code, Cursor, Windsurf, Claude Desktop, and ChatGPT Custom Connectors all speak MCP — though provider-native tool APIs and OpenAPI-style connectors still coexist with it. A2A (Agent-to-Agent) refers to emerging open protocols for agent-to-agent task handoff, status reporting, and capability discovery between autonomous agents — a distinct concern from LLM-to-tool. Google A2A (donated to the Linux Foundation with 150+ supporting organizations as of April 2026) and AGNTCY (complementary infrastructure project for agent discovery, identity, and messaging) are the leading open specs. In practice, using MCP for inter-agent calls works but is under-documented and conflates the transport concerns. Strong candidates treat MCP and A2A as separate axes. Option A is wrong. The protocols solve different problems. MCP is tool-side; A2A is agent-side. Interchanging them works loosely but obscures the architectural contracts. Option C is wrong. A2A does not subsume MCP. A fully A2A-compatible system still needs MCP for each agent's own tool surface. They are complementary, not competing. Option D is wrong. The sync/async distinction is an implementation detail of specific transports, not the defining difference between MCP and A2A. MCP supports both stdio (synchronous) and Streamable HTTP (streaming). A2A protocols also support async task handoff. Production reality: most teams in mid-2026 use MCP for tool calls and their own JSON-over-HTTP or message-queue protocols for inter-agent handoffs, with one eye on the Google A2A and AGNTCY specs as they mature. Designing the two concerns as independent seams makes it straightforward to swap the inter-agent protocol later.

8. A production agent using MCP tools is experiencing tool-call distribution anomalies: one tool is being called 40x per session instead of the expected 3–5x, and its error rate has jumped to 35%. What is the correct first diagnostic step?
   • A. Increase the MCP server's rate limit so the tool can handle the extra calls.
   • B. Check the agent loop's tool-call trace to determine whether the LLM is retrying a failing tool in a tight loop due to missing error handling or an absent stop condition, and verify that the tool's error response is being surfaced to the LLM as a structured observation rather than silently swallowed. ✓
   • C. Redeploy the MCP server with a fresh process — the high error rate indicates a server-side memory leak.
   • D. Reduce the agent's MAX_ITERATIONS cap to prevent excessive tool calls.

   Option B is correct. When a tool is called far more often than expected and its error rate is elevated, the most likely failure mode is an agent loop that is retrying a failing tool without making progress — a classic "stuck loop" pattern. The correct diagnostic is to read the tool-call trace (every tool invocation with arguments, outputs, and errors in the observability store) and answer: (1) Is the LLM seeing the tool's error as a structured observation, or is the error being silently swallowed so the LLM has no signal to change its behavior? (2) Is there a loop budget (MAX_ITERATIONS, token cap, wall-clock cap) that should have terminated the loop? (3) Is the tool's error structured as {"error": "...", "type": "..."} so the LLM can reason about it, or is it returning an empty string or a raw exception? A well-designed loop surfaces tool errors to the LLM as observations; the LLM then decides whether to retry with different arguments, try a different tool, or give up gracefully. Option A is wrong. Increasing the rate limit treats the symptom, not the cause. If the tool is being called 40x because the loop is stuck, a higher rate limit just enables more wasted calls. Option C is wrong. A high error rate alone doesn't indicate a memory leak. Redeploying without diagnosing the root cause would likely reproduce the same behavior. Option D is wrong. Reducing MAX_ITERATIONS mitigates the cost impact but does not fix the architectural failure (missing error handling). The next run would hit the new cap and still fail to complete the task. Production reality: tool-call distribution monitoring — calls per tool per session, error rate per tool, and the argument patterns sent to failing tools — is the fastest signal for diagnosing stuck loops. Every production MCP server should emit these metrics as OpenTelemetry spans so they appear in the trace store.

Frequently asked questions

What is the Model Context Protocol?

MCP is an open protocol published by Anthropic (modelcontextprotocol.io), now adopted by multiple vendors, for connecting language models and AI agents to tools, files, and data sources through a uniform client-server interface. The same MCP server can be consumed by any MCP-aware model or agent without per-model rewrites. MCP defines three server primitives (Tools, Resources, Prompts), capability negotiation via a JSON-RPC 2.0 initialize handshake, message framing, and the permission boundary between the model and the world. It is the settled standard for tool exposure in production agentic systems.

Why does MCP matter for AI engineers?

Before MCP, every team wrote bespoke glue code between a model and each tool or data source — an N×M integration problem. MCP replaces that with a shared standard: one server describes a database, a filesystem, or an internal API, and any MCP-aware client — an IDE, an agent runtime, a chat app — can use it. The protocol shifts integration work to N+M (each model plus each server). MCP is now consumed by Claude Code, Cursor, Windsurf, Claude Desktop, ChatGPT Custom Connectors, and the Anthropic and OpenAI SDKs. For AI engineers, understanding MCP is a baseline requirement for building production tool integrations.

What are MCP servers and clients?

A server exposes three primitive types: Resources (file-like data the model can read — documents, database records, live metrics), Tools (functions the model can call — search, write, compute), and Prompts (reusable prompt templates parameterized by the server). A client (an IDE, agent runtime, or chat app) connects to the server over a transport, negotiates capabilities, and presents the server's offerings to the model. The model then decides which tools or resources to invoke during its reasoning loop. The MCP ecosystem includes hundreds of public servers covering filesystem, GitHub, Linear, Notion, PostgreSQL, Slack, Vercel, Stripe, Supabase, Playwright, and many more.

How is MCP different from plain function calling?

Function calling is a model capability — the model emits a structured JSON call and the application executes it. MCP is a transport and discovery layer that sits above function calling. With raw function calling, every client must hard-code each tool's schema, authentication, and invocation logic. With MCP, the server advertises its own schema at runtime via capability negotiation; clients do not need to know the tool list in advance. MCP also handles versioning, error codes, pagination of resource lists, and cross-transport portability (stdio and Streamable HTTP) — none of which are part of bare function-calling specs. The WP-13 framing: "discover tool schemas via MCP; never hardcode tool definitions in the prompt where they silently drift from the implementation."

What transports does MCP support?

The MCP specification defines two primary transports. stdio is the default: the client spawns the server as a subprocess and communicates over standard input/output — used by local tools and IDE integrations where the server runs on the same machine. Streamable HTTP is the remote transport: the client POSTs JSON-RPC requests to a single HTTP endpoint and receives either a JSON response or a Server-Sent Events (SSE) stream for multi-message exchanges — used for web-hosted MCP servers, multi-tenant deployments, and cloud integrations. It replaced the original HTTP+SSE transport (two separate endpoints), which is now deprecated. Both current transports carry the same JSON-RPC 2.0 message format, so server implementations are transport-agnostic. The Vercel MCP server hosts MCP tools on Vercel and integrates with the AI SDK using Streamable HTTP.

How does MCP relate to A2A protocols?

MCP and A2A address different integration surfaces. MCP is the settled standard for LLM-to-tool communication: one agent connecting to one tool server and invoking its capabilities. A2A (Agent-to-Agent) refers to emerging open protocols for agent-to-agent task handoff — where one autonomous agent delegates a sub-task to another agent and receives status updates and results. Google A2A (donated to the Linux Foundation with 150+ supporting organizations as of April 2026) and AGNTCY (open infrastructure for agent discovery, identity, and messaging) are the leading open A2A specs. Most production teams in 2026 use MCP for tool calls and their own JSON-over-HTTP protocols for inter-agent handoffs, watching the A2A ecosystem mature. Strong candidates treat the two concerns as separate architectural seams.

How do you handle MCP tool errors gracefully in a production agent loop?

Structured error handling at the MCP server and at the agent loop are both required. The MCP server should surface failures as structured errors rather than letting exceptions propagate as raw stack traces — a tool execution error is returned as a tool result with isError set to true plus an error description (so the model sees it as an observation it can act on), while protocol-level errors use JSON-RPC error objects (code, message, optional data). The agent loop should surface these errors to the LLM as observations (not silently swallow them), so the LLM can decide whether to retry with different arguments, try a different tool, or give up gracefully. At the loop level, distinguish transient failures (429 rate limit — retry with exponential backoff) from permanent failures (401 auth — surface to the LLM and stop retrying). Without structured error feedback, the LLM has no signal to change its behavior and the loop can retry the same failing tool call dozens of times — a common production stuck-loop pattern.

What should I know about MCP for an interview?

Know the server vs client roles, the three primitives (Resources, Tools, Prompts), both transports (stdio and Streamable HTTP), capability negotiation, and the auth boundary pattern. Understand when MCP is the right choice over a direct SDK call: MCP earns its overhead when the same tools need to be consumed by multiple clients, when tool schemas need runtime discovery, or when you need to swap tool implementations without changing client code. Know the relationship between MCP (tool-side) and A2A (agent-side) — they address different integration concerns and are complementary. Be prepared to explain how you would add tool-result caching, handle server versioning, enforce least-privilege per client, and monitor MCP tool latency and error rates in production.

How do you monitor MCP tool calls in production?

Every MCP tool invocation should land in the trace store with: timestamp, tool name, arguments, output, latency, error if any, and a trace-ID linking it to the agent run. Use OpenTelemetry GenAI semantic conventions for vendor-neutral attribute naming. Key signals to watch: tool calls per agent run (spike indicates a stuck loop), error rate per tool (above 10% warrants investigation), p99 latency per tool (for SLO budgeting), and argument-pattern distribution (detects prompt-injection or LLM misuse of a tool). Langfuse, Phoenix (Arize), and Weights & Biases Weave all provide tool-call visualization on top of OTel traces. A tool that fails 30%+ of the time is either broken or being called with wrong arguments — the trace tells you which.

What is the difference between MCP resources and tools from a security perspective?

Resources are passive data sources — the model reads them as context (file contents, database rows, live metrics). They are identified by URIs and can be listed, read, and optionally subscribed to for live updates. Tools are active operations — the model calls them to perform side effects (search, write, compute, send a message). The security implication is direct: tools can cause real-world changes, so they require explicit auth checks on every invocation, input validation (especially path validation for file tools to prevent path traversal), and user approval for write-side-effects. Resources, if read-only and scope-limited, carry lower risk. Mixing the two — a "resource" that actually triggers a write when read — is a design mistake that undermines the security model and makes least-privilege enforcement impossible.

Related topics