50 Model Context Protocol (MCP) Interview Questions and Answers

MCP standardizes how capabilities are exposed and invoked, but it does not automatically make those capabilities safe to execute. A backend operation may still require authentication, authorization, input validation, transaction handling, and business-rule enforcement. For example, exposing a refund endpoint as an MCP tool must not allow the model to bypass refund limits or customer ownership checks. Treat MCP as an integration interface, not as a replacement for application security controls.

No. MCP primarily standardizes interactions between AI applications and servers exposing tools, resources, and prompts. Agent delegation, task planning, scheduling, and coordination are responsibilities of the surrounding application or a separate orchestration mechanism. An agent may invoke an MCP tool whose implementation communicates with another service or agent, but that does not make agent delegation a built-in MCP requirement. The team should define orchestration semantics separately and use MCP where standardized capability access is useful.

First verify that the server advertises the tools capability and that the host supports tool discovery. Inspect the initialization exchange, then determine whether the client sends a tools/list request and receives a valid response. Check for malformed tool definitions, pagination handling, server-side filtering, and host policies that hide or disable tools. A successful transport connection only proves connectivity; it does not establish that tools were discovered, accepted, or authorized for execution.

Separate connections preserve independent capability negotiation, lifecycle management, server identity, and failure handling. Each server may expose different tools, use different authentication arrangements, or become unavailable independently. For example, a database server can fail while a documentation server remains operational without invalidating the latter's connection. The host may present capabilities through a unified interface, but it must retain the correct originating server and security context for each operation.

The host should refresh its tool inventory when the server indicates that the available tool list has changed, provided the relevant notification capability is supported. In MCP implementations supporting tool-list change notifications, the server can signal that clients should rediscover tools rather than transmitting an authoritative replacement inventory. The host should repeat discovery, reconcile additions and removals, and update its model-facing tool representation. If notifications are unavailable, the application needs an explicit refresh or reconnection strategy.

The server should reject arguments that do not satisfy its declared input contract rather than silently relying on implicit conversions. Validate the received JSON against the tool schema and return an appropriate failure through the implementation's error-handling strategy. The host may use validation feedback to request corrected arguments, but automatic retry should be bounded. For example, the corrected arguments might be {"orderId":"123","includeItems":true}, provided those values reflect the user's intent.

An empty successful result means the operation completed without finding matching data, while a failed invocation indicates that the operation could not fulfill its intended contract. The host should inspect the tool result's failure indicator and content rather than assuming that empty content implies an error. For example, a search returning zero orders is different from a database connection failure. Preserving this distinction prevents unnecessary retries and avoids misleading the user about whether the underlying system is healthy.

Limit result size at the backend and expose explicit pagination or filtering arguments in the tool contract. Return concise structured records, meaningful metadata, and a continuation mechanism controlled by the application. For example, search_transactions could accept pageSize and cursor arguments instead of returning thousands of rows in one response. Avoid treating a resource link or summary as automatic protection: enforce access controls and verify that truncation does not hide important information.

Prompt support is a separately negotiated capability, so the integration must verify that the host can discover and retrieve server prompts. A server offering prompts does not require every host to display or consume them. If the host lacks support, keep other compatible capabilities operational and provide an application-specific fallback where appropriate. For example, the host might offer its own incident-analysis workflow without pretending that it retrieved the server's prompt.

Validate the URI format, identify the requested resource, and authorize access using the authenticated caller's effective permissions. The server must not assume that knowing a resource URI grants permission to read its contents. For example, a customer document URI should resolve only to documents belonging to tenants or accounts the caller can access. Use controlled resource resolution to prevent traversal, unintended file access, and access to internal endpoints when the implementation supports dynamic locations.

Standard output is used to carry MCP protocol messages in a stdio connection. Writing arbitrary log lines to that stream can corrupt message framing or cause the client to interpret non-protocol text as protocol data. For example, a startup banner printed to stdout may cause initialization to fail before any tools become available. Write diagnostics to stderr or another configured logging destination, and verify the protocol stream contains only valid MCP messages.

Apply the version-negotiation rules of the specific MCP specification revision implemented by both peers rather than assuming the newest version always wins. In the 2025-06-18 specification, a server that cannot support the requested version may respond with another supported version, and the client must decide whether it can continue using that version. If no mutually supported version can be established, terminate the connection with a clear compatibility diagnostic. Do not silently mix lifecycle rules, methods, or transport behavior from incompatible revisions.

A JSON-RPC error indicates that the protocol request itself could not be processed successfully, such as an invalid method or malformed parameters. A tool execution failure can instead be represented by a normal tools/call response containing a tool result marked as an error. For example, an unknown tool name may produce a protocol-level error, while a known tool encountering a downstream database failure can return a tool-level failure. Clients should classify these separately because their recovery, logging, and model feedback strategies differ.

Implement the authorization model required by the selected MCP specification revision and the applicable OAuth standards, including protected-resource metadata and authorization-server discovery where required. Validate token signatures or introspection results as appropriate, along with issuer, audience, expiration, and granted permissions. For example, a token issued for an unrelated API must not automatically authorize access to the MCP server. OAuth establishes a framework for delegated access, but application-specific authorization decisions remain necessary for individual tools and resources.

Derive the effective tenant authorization from trusted identity and policy context rather than accepting the model-provided tenantId as proof of access. Validate that the requested tenant belongs to the authenticated principal and enforce tenant isolation in the downstream service or database query. For example, an order lookup should restrict results using the authorized tenant scope even if the caller supplies another tenant's identifier. Test cross-tenant attempts directly, because JSON Schema validation only checks argument structure and cannot establish business authorization.

Treat retrieved resource content as untrusted task data, not as an instruction source with authority over the host. Maintain a clear separation between application instructions, user intent, and external content, and require authorization for every sensitive tool invocation. For example, a document containing a malicious export instruction should be summarized or analyzed as document content rather than executed. Prompt-injection defenses should combine context separation, tool restrictions, output handling, and execution-time policy checks rather than relying on a single prompt.

A local stdio server executes as a process with permissions granted by its operating-system environment, potentially including access to local files and credentials. A remote server instead operates across a network boundary and introduces concerns such as endpoint identity, transport protection, and remote authorization. For example, a malicious local server executable may read files available to its process even before any model-requested tool invocation. Use trusted installation sources, restricted process permissions, sandboxing where practical, and carefully scoped credentials.

Compare the executable path, working directory, environment variables, user permissions, and standard-stream handling between the two launch methods. Capture stderr and process exit status while keeping stdout reserved for protocol communication. For example, the host may launch the process without a required API credential or from a directory where a relative configuration path no longer resolves. Reproduce the host's exact launch environment before changing protocol code, because process startup failures often occur before MCP initialization.

Measure end-to-end invocation latency and separate time spent in transport handling, argument validation, business logic, and downstream dependencies. Track request counts, concurrency, error rates, connection-pool utilization, and relevant infrastructure saturation. For example, distributed traces may reveal that the MCP adapter takes 20 milliseconds while a downstream database query consumes almost the entire delay. Use correlation identifiers and carefully redacted telemetry to investigate performance without exposing sensitive tool arguments or results.

Use a controlled fake or sandbox downstream service that reproduces the relevant API contract and failure behaviors. Exercise successful operations, validation failures, timeouts, duplicate requests, and uncertain completion outcomes through the MCP interface. For example, configure the fake payment service to commit a transaction but delay its response, then verify that the MCP implementation does not blindly retry. Supplement deterministic tests with limited contract checks against an approved test environment to detect differences between the fake and the real service.

An MCP tool definition describes a capability exposed by an MCP server, while a model provider's function-calling interface describes how the model can request application-defined operations. A host may translate discovered MCP tool schemas into the provider's supported tool format, then route selected calls back through MCP. For example, an MCP search_orders tool can be represented as a callable function in a model request. The translation is host integration logic; MCP does not require a particular model provider or guarantee identical schema support across providers.

Create an MCP adapter layer that translates tool invocations into calls to existing application services or authorized HTTP endpoints. Keep order validation, transaction boundaries, access checks, and domain rules in the established service layer. For example, an MCP cancel_order tool can validate its input contract and delegate to the same cancellation service used by REST controllers. This preserves one source of business behavior while allowing the MCP adapter to handle discovery, protocol errors, result formatting, and integration-specific policies.