MCP architecture interview questions & answers

There are three main actors. First, the host application with the MCP client — like Claude Desktop, an IDE extension, or our own enterprise agent runtime. It holds the state, manages the transport connections, enforces authorization, and puts the context into the LLM. Second, the LLM — it is the reasoning engine and it is stateless. It reads the prompt and the tool schemas, decides what to call, and writes the final answer. Important point — the LLM does not call the MCP server directly over the network. Third, the MCP server — an isolated process or microservice that exposes capabilities using JSON-RPC 2.0, over standard input-output for local servers, or SSE or HTTP for remote enterprise services.

Tools are model-driven. The model decides when and how to call them, based on the JSON schema, and they can have side effects — like running code, creating a Jira ticket, writing to a database or triggering a deployment. Resources are application-driven. The client or user attaches or fetches data by a URI, and the model just reads it. They are read-only — like log files, database schemas or a PDF. Prompts are user-driven. They are ready-made templates exposed by the server for standard workflows — like a slash command for debugging a production incident, or a code review template.

Sure. Step one, discovery and handshake — when the client starts, it calls initialize and negotiates capabilities like tools, resources, prompts and logging. Step two, schema injection — the client calls tools/list and adds those JSON schemas into the LLM's context. Step three, the user asks something, and the LLM outputs a tool-use block with the tool name and arguments. Step four, the client catches this, validates the arguments against the schema, checks the user's permissions, and sends a tools/call JSON-RPC request to the server. Step five, the server executes the business logic — like an API or database call — catches any errors in a standard JSON-RPC error format, and returns the result. Step six, the client adds the result back into the conversation and sends it to the LLM, which writes the final answer for the user.

Five areas. Authentication and authorization — for local stdio servers, they run with the OS user's permissions, so we must clean environment variables like PATH and credentials. For remote servers, we use OAuth2 or OIDC bearer tokens, or mTLS, and pass the user identity so we can enforce role-based access control right down to the target system. Second, security — treat every tool argument from the LLM as untrusted input, validate it against the schema before it touches any shell or database, and run remote servers in sandboxes like ephemeral Docker containers, gVisor or WASM. Third, human-in-the-loop gates for risky actions. Fourth, reliability — explicit timeouts per tool, like 10 seconds for a database query, async callbacks for long jobs, and circuit breakers. Fifth, observability — trace every MCP call with OpenTelemetry, with the JSON-RPC message ID, duration, token overhead and error rate.

If we expose the full schema as one big static resource, it will bloat the context window immediately — high token cost, more latency, and we may hit the model's token limit. So I will use a hybrid. A lightweight resource that gives only the list of table names. And a targeted tool, like get_table_schema, which takes a list of table names, so the model asks for schema details only for the tables it actually needs for that query. Yes, it adds one extra tool call, but the context stays small.

I will not put all 300 tool schemas into the system prompt. Instead, dynamic tool selection. I store all tool descriptions and schemas in a search index — an in-memory vector index or BM25. Then two passes. Pass one, based on the user's intent, I retrieve only the top few relevant tools — say the top 8. Pass two, I give only those 8 tool definitions to the LLM for planning and execution. So the context goes from 40,000 tokens to a small fraction.

Four layers. One, risk annotations — every tool has a risk tier in its definition, like read-only, safe side effect, or destructive. Two, the MCP client intercepts any call marked destructive before sending the JSON-RPC request to the server. Three, human-in-the-loop — the agent loop pauses and asks the user for approval, through a UI prompt or something like a Slack confirmation. If the user approves, it goes to the server. If the user denies, we return an abort error to the model. Four, by default the server uses a read-only database connection, and write operations need an explicit, elevated access token.

First, a circuit breaker around the remote transport calls — for example, if the server times out three times in a row, the circuit opens and we stop calling it immediately. Second, graceful degradation — instead of crashing the whole agent run, the client catches the failure and sends a structured error back into the conversation, like "status error, server unavailable, the Jira MCP server is not reachable, inform the user and suggest alternative steps." Third, the LLM now clearly knows the integration is offline, so it can explain the issue to the user or take an alternate path, instead of hanging forever.