1. In the MCP architecture, where do API credentials live, and why there?
A In the model's system prompt, so it can authenticate itself per callB In the host application's UI settings, injected into the model's context at startupC In the server process (env vars / secrets manager) — the model only ever sees tool names and schemas, so a secret that never enters model context can't leak through injection or model errorD Split between client and server so neither holds a complete key
2. Tools, resources, and prompts — who invokes each?
A Tools: the model, mid-task; resources: the application/host, which attaches them to context; prompts: the user, explicitly (slash-command style templates)B All three are invoked by the model whenever it choosesC Tools: the user; resources: the model; prompts: the hostD The server invokes all three and pushes results to the client
3. How does an MCP session begin?
A The client immediately sends tools/call; discovery is optionalB The client sends an initialize request declaring protocol version and capabilities; the server responds with its own; the client sends an initialized notification — then normal traffic like tools/list can flowC The server dials the client and streams its tool list unpromptedD Both sides exchange TLS certificates, which doubles as capability negotiation
4. Your API has 12 REST endpoints. The straightforward MCP server mirrors each as a tool. Why is this usually wrong, and what's better?
A It's correct — fidelity to the API is the goal of an MCP serverB Wrong only because 12 exceeds a protocol limit on tool countC It's wrong because tools can't call more than one endpoint internallyD Models choose worse as tool count grows, and thin wrappers force the model to chain calls and join data in-context, burning tokens and multiplying failure points; better: fewer task-level tools that accept what the model has (names, queries) and return shaped, pre-joined summaries
5. Why are tool descriptions 'prompts in disguise'?
A The client concatenates them into the system prompt verbatim, replacing your instructionsB They're validated by the API for prompt-injection patternsC The model selects tools and forms arguments based on names, descriptions, and schemas alone — so a description change (e.g., adding 'NOT for refunds — use process_refund') directly changes agent behavior, exactly like editing a promptD They're only shown to human users browsing the server
6. A tool can match 200k tokens of results. What's the right response strategy?
A Return everything — the model will skim what it needsB Silently return the first 1,000 tokens so the response stays smallC Refuse to answer queries that match too much dataD Server-enforced caps and pagination (bounded page_size, per-item truncation), plus an explicit signal — 'showing 20 of 3,400; more available, request page 2 or refine the query' — so the model knows the view is partial and what to do next
7. How should a tool signal errors, and why not just raise exceptions?
A Raise exceptions — the client converts them into retries automaticallyB Return instructive text the model can act on ('Ambiguous: 3 customers match — call again with a full name'; 'auth expired — tell the user, do not retry'), because the model can read and recover from in-band results but learns nothing actionable from a dead callC Return HTTP status codes as bare integersD Log the error server-side and return an empty string
8. Name the sandbox property and the attack it prevents. Which pairing is correct?
A Read-only filesystem → prevents infinite loopsB Memory limits → prevent data exfiltrationC No network access → prevents exfiltrating data/secrets and calling attacker infrastructure; memory/CPU/pids limits → prevent resource-exhaustion bombs; timeout → kills infinite loops; ephemeral non-root read-only FS → prevents persistence and privilege escalationD Timeouts → prevent fork bombs
9. What problem does MCP solve versus A2A?
A MCP connects an agent to tools and data (agent↔tool); A2A connects agents to other agents as opaque peers across trust boundaries (agent↔agent) — complementary, and an A2A peer may use MCP internallyB A2A is the successor protocol that deprecates MCPC MCP is for local servers, A2A is MCP-over-HTTPD MCP handles authentication while A2A handles tool schemas
10. When should you choose stdio versus streamable HTTP transport?
A Always streamable HTTP — stdio is legacyB stdio for anything with more than one userC stdio when the client and server share a machine and a single user — the client spawns the server as a subprocess, inheriting local trust with zero deployment; streamable HTTP when the server is remote or shared by multiple clients, which brings auth, TLS, and ops obligationsD They're interchangeable; pick by personal taste
11. What are the three layers of testing for an MCP server?
A Linting, formatting, and type-checkingB Unit tests on the tool logic as plain functions (mock the real API); integration tests that speak actual MCP — spawn the server over stdio with a ClientSession, list and call tools, assert on results; and adversarial/end-to-end testing through a real client where someone tries to break it (bad IDs, huge queries, destructive calls without confirm)C Load testing, soak testing, and chaos testing onlyD Testing is unnecessary — the protocol validates everything
12. A model keeps calling your destructive delete_project tool during exploratory questions. Which defense is the right FIRST layer, within your server?
A Remove the tool — destructive operations can never be exposedB Rely on the host app's approval dialog and change nothingC Rename the tool to something the model won't noticeD A two-phase confirm parameter defaulting to false — the bare call returns a preview of exactly what would be deleted, and only an explicit confirm=true call acts — with the docstring instructing that confirmation requires the user's explicit approval of the previewed item