Topic 4: MCP interview questions

MCP, or Model Context Protocol, is an open protocol for connecting AI applications to external tools, resources, and prompts through a consistent interface. An MCP host manages the model interaction and connects to one or more servers. The protocol reduces bespoke integration work, but it does not make a tool trustworthy automatically; authorization, validation, privacy, and operational controls remain application responsibilities.

The host is the AI application that coordinates user interaction and model access. A client is the protocol component inside the host that maintains a connection to one server. The server exposes capabilities such as tools, resources, or prompts. This separation lets a host connect to several servers while keeping each server’s capabilities and transport session logically isolated.

An MCP server can expose tools that perform actions, resources that provide application-controlled context, and prompts that package reusable interaction templates. Tools are model-invokable operations; resources are typically selected or read by the host; prompts help users or applications start consistent tasks. Each capability should have clear descriptions, schemas, permissions, and failure semantics so clients can use it safely.

During initialization, an MCP client and server negotiate protocol details and capabilities. The client can then discover available tools, resources, or prompts and receive their metadata, including names, descriptions, and input schemas. Discovery allows a server to evolve without hard-coding every operation into the host. A robust client still filters and validates discovered capabilities before exposing them to a model.

A tool represents an operation, such as querying a ticket system or creating a calendar event, and may have side effects. A resource represents data or context, such as a document or schema, that can be read by the client. The distinction helps users understand risk and helps hosts apply different consent and caching policies. A resource should not be treated as trusted instructions.

MCP supports local and remote communication through transports defined by the protocol, including standard input/output for local processes and streamable HTTP for networked servers. The practical choice depends on deployment, isolation, authentication, and streaming needs. I would use local transport for tightly controlled desktop integrations and authenticated HTTP for shared services, with timeouts, origin checks, and network policy.

Authentication depends on the transport and deployment, but a remote MCP server should use a standard, verifiable mechanism such as bearer tokens or an OAuth-based flow when delegated access is required. The server must validate audience, issuer, expiry, scopes, and tenant context. Secrets should never be placed in tool descriptions or model-visible content, and authorization must be enforced on every operation.

I apply least privilege at several layers: which servers a host may connect to, which tools a user or agent may invoke, which records or scopes the token permits, and whether the specific operation requires approval. The server must re-check authorization using the authenticated identity and current resource state. Model-generated tool calls are requests, not proof of permission.

Important risks include malicious or compromised servers, prompt injection in resources, confused-deputy access, excessive tool permissions, credential leakage, unsafe side effects, and data exfiltration. Supply-chain controls, server allowlists, scoped credentials, output limits, audit logs, confirmation for risky actions, and independent authorization reduce exposure. Treating every discovered capability as safe defeats the purpose of a security boundary.

A precise input schema makes required fields, types, enums, formats, and constraints explicit before execution. The server should validate again because clients or models can send malformed data. Descriptions should state side effects, units, pagination, and error conditions. Structured outputs are preferable to ambiguous prose because the host can inspect, retry, display, or compose results without guessing their meaning.

The server should return protocol-valid errors with a safe, actionable message and stable classification where possible. Clients should distinguish invalid input, authentication, authorization, not-found, rate-limit, and transient server failures. Retries belong only on operations known to be safe and idempotent. Diagnostic details go to protected logs, while the model receives enough information to recover without exposing secrets.

The client should negotiate protocol compatibility during initialization and avoid assuming unsupported capabilities. Servers should preserve backward-compatible tool contracts where practical, version breaking changes, and document migration behavior. Clients can validate schemas at startup, feature-detect capabilities, and fail clearly when a required operation is unavailable. Contract tests against representative servers help catch changes before production rollout.

I would define a narrow capability surface, use typed schemas, authenticate callers, enforce per-user authorization, and keep side effects explicit. The server needs timeouts for downstream systems, bounded pagination and output sizes, idempotency for writes, structured logs, metrics, traces, and health checks. I would add contract, security, load, and failure-injection tests before allowing an agent to invoke it.

Resources must be labeled as untrusted data and kept separate from system policy. The host should control which resources are fetched and how they enter context, while the model should not be allowed to reinterpret resource text as authorization. Tool permissions remain enforced outside the model. I also test documents containing instructions such as requests to reveal secrets or change security rules.

The host should pause before a high-impact tool call and show the user the server, tool, arguments, target, expected side effect, and relevant evidence. Approval should be bound to that exact request, expire, and be auditable. A generic “allow this server forever” prompt is usually too broad. Read-only calls may need less friction, but writes and external communication deserve explicit consent.

Function calling is a model API feature that lets a model request structured functions supplied by an application. MCP is a protocol for discovering and exchanging tools, resources, and prompts between an application and external servers. A host can translate discovered MCP tools into the model’s function-calling format, then execute and return results through MCP. They solve related but different integration layers.

I record connection lifecycle, negotiated capabilities, tool name, request correlation ID, latency, outcome class, retry count, and resource or tenant scope, while redacting arguments and results that contain sensitive data. Metrics should show error rates, timeouts, saturation, and cost. Distributed traces connect the user request, model decision, MCP client, server, and downstream dependency for diagnosis.

Use least-privilege credentials, tenant-aware authorization, field-level filtering, pagination, output-size limits, and explicit redaction before results reach the model. Avoid returning entire records when a summary or selected fields meet the task. Define retention and logging rules separately because observability systems can become a second data leak. Access should be denied by default when scope or identity is unclear.

MCP may be unnecessary when the integration is internal, static, and simpler to call directly, or when adding a general protocol would create more operational surface than value. It is also inappropriate to use it as a substitute for access control or a transaction boundary. I would choose MCP when multiple hosts or agents need a stable, discoverable capability interface.

I would test initialization and capability negotiation, schema validation, successful reads and writes, malformed requests, authentication and authorization failures, timeouts, retries, duplicate calls, oversized outputs, and server restarts. Security tests should include malicious resource content and confused-deputy scenarios. End-to-end tests verify the host-model-tool loop, while contract tests ensure server changes do not break clients.