Deck 2 — Tool Design & MCP Integration (Domain 2, 18%)
45 cards. Cards 1–25 = tool design and selection. 26–45 = MCP, errors, built-ins.
1
Q: What is the primary mechanism by which the model selects a tool? A: The tool description.
2
Q: Five things a good tool description contains? A: What it does · input formats · example queries · edge cases · explicit boundaries (what it is not for).
3
Q: Which element of a description most directly prevents misrouting? A: The explicit boundary clause — stating what the tool doesn't handle and which tool does.
4
Q: analyze_content and analyze_document are used interchangeably and wrongly. Diagnosis?
A: Overlapping descriptions. Fix by rewriting both with explicit boundaries.
5
Q: One generic analyze_document tool is used badly for three different jobs. Fix?
A: Split it — e.g. extract_data_points, summarize_content, verify_claim_against_source.
6
Q: Rewrite descriptions or split the tool — how do you choose? A: Rewrite when the tools are right but boundaries are unclear. Split when one tool genuinely does several different jobs.
7
Q: The correct tool exists with a good description but is still never selected. What else do you audit? A: The system prompt, for keyword-sensitive instructions steering the model elsewhere.
8
Q: Selection accuracy dropped after the tool count grew. What number does the exam use? A: 18 tools instead of 4–5 degrades selection accuracy.
9
Q: Fix for too many tools? A: Consolidate, and scope tools per agent — least privilege.
10
Q: 85% of a tool's uses are one narrow job. Design implication?
A: Provide a scoped tool for that case (e.g. verify_fact) rather than a general tool everyone misuses.
11
Q: Agents keep passing arbitrary URLs to fetch_url and getting garbage. Fix?
A: Replace it with a validating load_document that checks and normalizes its input.
12
Q: An MCP tool keeps losing to the built-in Grep. Fix?
A: Enhance the MCP tool's description so its advantage over Grep is explicit.
13
Q: Is there a config option to mark MCP tools as "preferred"? A: No. Non-existent option. Fix the description.
14
Q: tool_choice values, all three?
A: auto · any · {"type": "tool", "name": "..."}.
15
Q: Which tool_choice do you use for reliable structured output?
A: The forced form: {"type": "tool", "name": "..."}.
16
Q: Why is least privilege a selection accuracy property, not just a safety one? A: Fewer candidate tools means fewer opportunities for the model to pick the wrong one.
17
Q: When do you build a custom MCP server instead of using a community one? A: Only for your own internal systems. Standard integrations (Jira, GitHub, Slack) → community server.
18
Q: Is deploying or hosting an MCP server on the exam? A: No — explicitly out of scope. Infrastructure answers are distractors.
19
Q: MCP resources — what are they for? A: Exposing content catalogs (readable content), as distinct from callable tool actions.
20
Q: Where do you record the boundary between two similar tools? A: In both tools' descriptions, symmetrically.
21
Q: Two tools have distinct jobs but confusingly similar names. Enough to rewrite descriptions? A: Rewrite descriptions and rename where the names themselves collide semantically.
22
Q: A tool's description says what it does but not what it rejects. What class of failure follows? A: Misrouting — the model tries it for adjacent jobs it can't handle.
23
Q: When are tools discovered from an MCP server? A: At connection time.
24
Q: After discovery, are MCP tools available one at a time or all together? A: All simultaneously available.
25
Q: One sentence: where do you fix tool-selection problems? A: In the descriptions, first and almost always.
26
Q: Which file holds project MCP server config, and is it committed?
A: .mcp.json at the repo root — yes, committed.
27
Q: Which file holds user-level MCP server config?
A: ~/.claude.json — not shared.
28
Q: How do you commit MCP config that needs a secret?
A: ${ENV_VAR} expansion — e.g. "GITHUB_TOKEN": "${GITHUB_TOKEN}".
29
Q: Which MCP flag marks a tool result as a failure?
A: isError (set to true).
30
Q: 🎯 A permission failure returns []. What's wrong?
A: An access failure is not a valid empty result. It must be isError: true with a category. Otherwise the agent reports "no data exists."
31
Q: When is [] with isError: false correct?
A: When the query ran successfully and genuinely nothing matched.
32
Q: The four error categories? A: transient · validation · business · permission.
33
Q: Which categories are retryable? A: transient yes; validation only after correcting the input; business and permission no.
34
Q: What field marks a business-rule failure as not worth retrying?
A: isRetryable: false (retriable: false).
35
Q: Four fields a structured error should carry?
A: errorCategory · isRetryable · a specific message · suggested alternatives.
36
Q: Why is a generic "search unavailable" message wrong?
A: It hides the category, retryability, what failed, and what succeeded. The coordinator can only guess.
37
Q: Where should a subagent handle a recoverable error? A: Locally. Propagate only what it can't resolve.
38
Q: What must accompany a propagated error? A: Partial results — whatever did succeed.
39
Q: Two symmetric error anti-patterns? A: Silently suppressing the error and reporting success · terminating the whole workflow on one failure.
40
Q: The middle path between those two? A: Complete what you can, report precisely what you couldn't, and annotate the gap in the output.
41
Q: Grep vs Glob?
A: Grep = file contents. Glob = file paths/names (e.g. **/*.test.tsx).
42
Q: Find every React test file in a repo. Which tool?
A: Glob — **/*.test.tsx.
43
Q: What does Edit require?
A: A unique text anchor.
44
Q: The target text appears three times in the file. Which tools?
A: Read + Write — Edit has no unique anchor.
45
Q: Efficient way to understand an unfamiliar codebase? A: Grep for entry points, then Read to follow the imports. Not reading every file.