CCAR‑F glossary

168 terms for the Claude Certified Architect exam — what each one means, and how it is actually tested. Grouped by domain, every entry linked to the lesson that covers it.

Search it in the study app All 54 lessons

Domain 1: Agentic Architecture & Orchestration

27% of exam · 39 terms

Agentic loop: The cycle of calling the model, inspecting stop_reason, executing any requested tools, returning results, and calling again until the model stops requesting tools.; On the exam
The loop is driven by stop_reason, not by parsing text. Questions that describe an agent "getting stuck" or "never finishing" are usually testing whether you branch on stop_reason and whether you set an iteration cap.; Covered in: The agentic loop and stop_reason →

stop_reason: The field on a Messages API response saying why generation stopped. Values include end_turn, max_tokens, stop_sequence, tool_use, pause_turn and refusal.; On the exam
Know all six and what each obliges you to do. tool_use means execute and continue; max_tokens means the turn was truncated mid-thought; pause_turn means resume, not restart.; Covered in: The agentic loop and stop_reason →

end_turn: The stop_reason indicating the model finished its turn naturally with nothing further requested.; On the exam
This is the only clean loop exit. Terminating on "there was text in the response" is the wrong answer in scenario questions.; Covered in: The agentic loop and stop_reason →

max_tokens (stop_reason): A stop_reason meaning generation hit the max_tokens limit and was cut off mid-output.; On the exam
Distinguish truncation from completion. Truncated JSON is a limit problem, not a schema problem — raising max_tokens is the fix, not a stricter schema.; Covered in: The agentic loop and stop_reason →

pause_turn: A stop_reason indicating a long-running server-side tool has not finished; the turn should be resumed by sending the paused content back unmodified.; On the exam
The distractor is always "retry the original request". Resuming preserves completed work; restarting discards it and re-costs the tokens.; Covered in: pause_turn and server-side tools →

refusal (stop_reason): A stop_reason indicating the model declined to continue for safety reasons.; On the exam
Handle it as its own branch. Retrying the identical request is not a remedy, and treating it as a transient error produces a retry loop.; Covered in: The agentic loop and stop_reason →

tool_use block: A content block in an assistant turn carrying an id, a tool name, and the input the model wants passed to it.; On the exam
The id is what pairs the eventual result to the request. Losing it is the root cause of most malformed multi-tool turns.; Covered in: The agentic loop and stop_reason →

tool_result block: A content block in a user turn returning a tool's output, keyed to a tool_use_id.; On the exam
All results for one assistant turn go in a single user message. One user message per result is a common wrong answer.; Covered in: Parallel tool use and result pairing →

tool_use_id: The identifier linking a tool_result back to the tool_use block that requested it.; On the exam
Order of results does not matter; the id does the matching. Questions about "results attributed to the wrong tool" are pairing questions.; Covered in: Parallel tool use and result pairing →

Parallel tool use: Several tool_use blocks emitted in one assistant turn, executable concurrently, answered together in one user turn.; On the exam
The performance win is real but the structure is strict. Also know that parallel use can be turned off deliberately when ordering matters.; Covered in: Parallel tool use and result pairing →

disable_parallel_tool_use: A tool_choice option forcing at most one tool call per turn.; On the exam
The right answer when a sequence has real ordering dependencies or when concurrent side effects are unsafe.; Covered in: Parallel tool use and result pairing →

Workflow (vs agent): A system where the steps are fixed in code ahead of time. The model performs steps; it does not choose them.; On the exam
Anthropic's guidance is to prefer the simplest thing that works. If the steps are knowable in advance, a workflow is cheaper and more predictable than an agent.; Covered in: Workflow patterns: chaining, routing, parallelisation →

Agent (autonomous): A system where the model directs its own process, choosing tools and steps dynamically based on what it finds.; On the exam
Justified when the required steps cannot be enumerated in advance. Answering "use an agent" for a fixed three-step pipeline is the classic overreach.; Covered in: Agent or workflow? Surfaces, tiers and effort →

Prompt chaining: Decomposing a task into fixed sequential calls where each output feeds the next, often with a validation gate between steps.; On the exam
Choose it when the decomposition is stable. The gate is the point — it stops a bad intermediate result propagating.; Covered in: Workflow patterns: chaining, routing, parallelisation →

Routing: Classifying an input first, then dispatching it to a specialised downstream prompt or model.; On the exam
Lets you send easy traffic to a cheap model and hard traffic to a strong one. Cost-optimisation scenarios usually want routing.; Covered in: Workflow patterns: chaining, routing, parallelisation →

Parallelisation (sectioning / voting): Running independent subtasks concurrently — either splitting distinct sections, or running the same task several times for consensus.; On the exam
Sectioning is for independent parts; voting is for raising confidence on one judgement. Know which the scenario is describing.; Covered in: Workflow patterns: chaining, routing, parallelisation →

Orchestrator-workers: A central model decomposes a task at runtime, dispatches subtasks to workers, and synthesises their results.; On the exam
The distinguishing property is that the subtasks are not known in advance. If they were, the answer is parallelisation, not orchestration.; Covered in: Orchestrator-workers and evaluator-optimizer →

Evaluator-optimizer: A generation call paired with a separate critic call that scores output against a rubric and returns actionable feedback for another pass.; On the exam
Requires a clear rubric and a bounded loop. Where no crisp evaluation criterion exists, this pattern does not apply.; Covered in: Orchestrator-workers and evaluator-optimizer →

Coordinator / subagent: A hub-and-spoke arrangement where a coordinator delegates to specialised subagents and merges their outputs.; On the exam
Subagents communicate through the coordinator, not with each other. Questions describing spoke-to-spoke chatter are describing a design error.; Covered in: Coordinator and subagent architecture →

Context isolation (subagents): The property that a subagent starts with a fresh context and does not inherit the coordinator's conversation.; On the exam
Heavily tested. Anything the subagent needs must be stated explicitly in its prompt; references to "the plan above" fail silently.; Covered in: Subagent prompting and tool scoping →

Tool scoping: Granting each agent only the tools its role requires.; On the exam
Both a reliability and a security control. Universal tool access is a wrong answer in almost every scenario that mentions it.; Covered in: Subagent prompting and tool scoping →

Session resume: Continuing an existing conversation by replaying its message history.; On the exam
Contrast with checkpointing. Resume re-costs tokens and, for tools with side effects, risks repeating work that already completed.; Covered in: Session state, resume and crash recovery →

Checkpointing: Persisting structured progress externally after each completed unit of work, so a restart continues from the last confirmed state.; On the exam
The right answer for long-running or side-effecting agents. Conversation history alone is not a durability mechanism.; Covered in: Session state, resume and crash recovery →

Model tier selection: Choosing a model size appropriate to each step rather than using one model for everything.; On the exam
Classification and routing rarely need the strongest model. Mixed-tier designs are usually the intended answer in cost scenarios.; Covered in: Agent or workflow? Surfaces, tiers and effort →

Effort level: A control over how much reasoning the model expends on a request.; On the exam
A lever distinct from model choice: same model, different depth. Useful when quality needs vary across steps of one pipeline.; Covered in: Agent or workflow? Surfaces, tiers and effort →

Agent SDK: Anthropic's toolkit for building agents on the same harness as Claude Code, handling the loop, tools, permissions and session management.; On the exam
Know it as the supported path for production agents rather than hand-rolling the loop, and that it shares Claude Code's configuration model.; Covered in: The Agent SDK and headless automation →

Iteration cap: A hard limit on agentic loop turns, independent of the model's own stopping behaviour.; On the exam
Every well-formed agent has one. Its absence is the defect in "the agent ran up a huge bill" scenarios.; Covered in: The agentic loop and stop_reason →

Transient error: A failure likely to succeed on retry — a timeout, a rate limit, a brief network fault.; On the exam
Retry these inside the tool with backoff. The model should generally never see them.; Covered in: Error classification and propagation →

Permanent error: A failure that retrying cannot fix — bad credentials, a missing resource, a malformed request.; On the exam
Surface with enough context for the agent to route around it. Retrying these is pure waste.; Covered in: Error classification and propagation →

Graceful degradation: Continuing with reduced capability and an explicit statement of what was lost, instead of failing entirely.; On the exam
The key requirement is that degradation is declared. Silent partial coverage presented as a complete answer is the failure being tested.; Covered in: Fallback, retry and graceful degradation →

Exponential backoff: Increasing the wait between retries, usually with jitter, to avoid overwhelming a recovering service.; On the exam
Pairs with transient classification. Immediate uniform retries turn a blip into an outage.; Covered in: Fallback, retry and graceful degradation →

Circuit breaker: Halting calls to a failing dependency after a threshold, then probing periodically before restoring traffic.; On the exam
Appears in scenarios where one bad dependency is stalling an entire agent fleet.; Covered in: Fallback, retry and graceful degradation →

External memory: Durable state stored outside the conversation and retrieved on demand.; On the exam
Survives restarts and compaction. When a scenario requires facts to persist across sessions, in-context state is the wrong answer.; Covered in: State: in-context versus external memory →

Hub-and-spoke: A topology where all coordination flows through one central agent.; On the exam
Contrast with a flat mesh where every agent talks to every other — the mesh multiplies failure paths and is a common distractor.; Covered in: Coordinator and subagent architecture →

Task decomposition: Breaking a goal into subtasks, either statically in code or dynamically by the model at runtime.; On the exam
Static versus dynamic is the discriminator between parallelisation and orchestrator-workers.; Covered in: Orchestrator-workers and evaluator-optimizer →

Synthesis step: The coordinator's final pass reconciling worker outputs into one coherent result.; On the exam
Must handle conflicting worker findings explicitly. Concatenating outputs is not synthesis.; Covered in: Coordinator and subagent architecture →

Guardrail: A deterministic constraint enforced outside the model — validation, permission, hook, or threshold.; On the exam
When a requirement says "must never", the answer is a guardrail in code, never an instruction in a prompt.; Covered in: Fallback, retry and graceful degradation →

Human-in-the-loop: A designed checkpoint where a person approves or decides before the system proceeds.; On the exam
Required for consequential, irreversible actions. Know where to place it: before the action, not after.; Covered in: Provenance, conflict and escalation →

Autonomy boundary: The explicit limit on what an agent may do without approval.; On the exam
Scenario questions about refunds, deployments or deletions are usually asking you to draw this line.; Covered in: Agent or workflow? Surfaces, tiers and effort →

Domain 2: Claude Code Configuration & Workflows

20% of exam · 34 terms

settings.json: Claude Code's configuration file, present at user, project and local scope, controlling permissions, hooks, environment and model settings.; On the exam
Know which scope each path represents and which belongs in version control.; Covered in: Settings files and precedence →

Settings precedence: The order in which conflicting settings resolve, with managed enterprise policy at the top and user-level settings at the bottom.; On the exam
The tempting wrong answer is "most local wins". Managed policy deliberately cannot be overridden by a project.; Covered in: Settings files and precedence →

settings.local.json: Per-developer project settings, not intended for version control.; On the exam
Use it for personal overrides. Committing it is the mistake in "why did my teammate get my permissions" scenarios.; Covered in: Settings files and precedence →

Managed settings: Administrator-deployed configuration that takes precedence over all other scopes.; On the exam
The correct mechanism whenever a scenario mentions organisation-wide compliance that developers must not be able to relax.; Covered in: Settings files and precedence →

Permission rules (allow / ask / deny): Rules governing whether a tool call proceeds automatically, prompts for approval, or is refused.; On the exam
deny is not merely the absence of allow. Rules from different scopes combine rather than replacing one another wholesale.; Covered in: Permissions: enforcement vs guidance →

CLAUDE.md: A memory file of project or personal instructions loaded into Claude Code's context.; On the exam
It is guidance, not enforcement. Any "must never" requirement needs a hook or permission rule instead.; Covered in: The CLAUDE.md hierarchy and load order →

User-scope memory: Personal instructions applying across all your projects, stored at ~/.claude/CLAUDE.md.; On the exam
Several third-party study guides wrongly place this at ~/.claude.json. That file holds session and MCP server state, not memory.; Covered in: The CLAUDE.md hierarchy and load order →

Memory hierarchy: The layering of memory files from user scope through project root to subdirectories.; On the exam
Subdirectory files load when Claude works in that area rather than all being read up front — the basis for keeping the root file small.; Covered in: The CLAUDE.md hierarchy and load order →

@path import: Syntax pulling another file's content into a memory file, so shared standards live in one place.; On the exam
The maintainable answer to duplicated conventions across packages.; Covered in: Imports, AGENTS.md and exclusions →

.claude/rules/: A directory of rule files that can be scoped to file patterns via frontmatter.; On the exam
The mechanism for conditional loading — migration conventions that only appear when someone touches migrations.; Covered in: Path-scoped rules with .claude/rules/ →

paths frontmatter: The frontmatter key restricting a rule to matching file paths.; On the exam
Mechanical scoping. Writing "when working on migrations…" in prose is a hint, not a scope.; Covered in: Path-scoped rules with .claude/rules/ →

Hook: A shell command Claude Code runs at a defined lifecycle event, able to observe and in some cases block an action.; On the exam
The enforcement mechanism. Contrast constantly with CLAUDE.md, which is advisory.; Covered in: Hooks: events, exit codes and decisions →

PreToolUse: A hook event firing before a tool executes, able to block it.; On the exam
The only hook that can prevent an action. If a question requires prevention, this is the event.; Covered in: Hooks: events, exit codes and decisions →

PostToolUse: A hook event firing after a tool completes.; On the exam
Good for formatting, logging and validation feedback — but it cannot stop what already happened.; Covered in: Hooks: events, exit codes and decisions →

Hook exit code 2: The blocking exit status: the action is stopped and the hook's stderr is fed back to Claude.; On the exam
Exit 0 is success; other non-zero codes are non-blocking errors. This three-way distinction is directly examinable.; Covered in: Hooks: events, exit codes and decisions →

Skill: A packaged unit of instructions, and optionally scripts and resources, that Claude can invoke for a repeatable procedure.; On the exam
Custom slash commands have converged into this model. Skill selection depends on the description quality, exactly like tool selection.; Covered in: Skills and custom slash commands →

SKILL.md: The entry file of a skill, carrying name and description frontmatter plus the instructions.; On the exam
The description should state when to use the skill, not just what it does.; Covered in: Skills and custom slash commands →

Headless mode: Running Claude Code non-interactively, typically with -p and a structured output format, for scripts and CI.; On the exam
There is no human to approve prompts, so permissions must be deny-by-default. Carrying interactive settings into CI is the tested mistake.; Covered in: The Agent SDK and headless automation →

--output-format json: A flag making headless output machine-parseable.; On the exam
Preferred over scraping prose. Automation questions expect structured output.; Covered in: The Agent SDK and headless automation →

.mcp.json: Project-scoped MCP server configuration, checked into the repository so a team shares the same servers.; On the exam
Distinguish project scope from user scope when a question asks how a whole team gets a server.; Covered in: MCP config and CI/CD workflows →

Plan mode: A mode where Claude investigates and proposes an approach without making changes until approved.; On the exam
The right answer for large or risky changes where you want to review the approach before any edit lands.; Covered in: Claude Code architecture and the execution model →

Context window (Claude Code): The working memory holding system prompt, memory files, tool schemas, file contents and conversation.; On the exam
Everything you add to CLAUDE.md competes with actual work for this space.; Covered in: Claude Code architecture and the execution model →

.claudeignore / exclusions: Configuration keeping specified files out of Claude Code's reach and context.; On the exam
Both a context-cost control and a secrets-hygiene control.; Covered in: Excluding files and controlling project scope →

Permission prompt: The interactive approval requested when a tool call matches an ask rule.; On the exam
Absent in headless runs — which is exactly why headless permission design differs.; Covered in: Permissions: enforcement vs guidance →

Subagent (Claude Code): A separately configured agent with its own prompt, tool grants and fresh context, invocable for delegated work.; On the exam
Keeps exploratory work out of the main context window while enforcing least privilege.; Covered in: Subagent prompting and tool scoping →

Slash command: A named invocable procedure in Claude Code; custom ones are now authored as skills.; On the exam
If a question offers a standalone custom-command file format, check it against the current skills model.; Covered in: Skills and custom slash commands →

AGENTS.md: A cross-tool convention for agent instructions that Claude Code can recognise alongside its own memory files.; On the exam
Relevant when a repo must serve several agent tools without duplicating conventions.; Covered in: Imports, AGENTS.md and exclusions →

Project scope vs user scope: Whether configuration travels with the repository or with the individual developer.; On the exam
"Everyone on the team should get this" means project scope and version control.; Covered in: Settings files and precedence →

CI/CD integration: Running Claude Code as a pipeline step for review, generation or checks.; On the exam
Expect questions on permission scoping, structured output parsing and failure handling — not on the model's writing quality.; Covered in: MCP config and CI/CD workflows →

Least privilege: Granting only the access required for the task at hand.; On the exam
Applies to tool grants, MCP servers and file access alike. Blanket access is rarely the intended answer.; Covered in: Permissions: enforcement vs guidance →

Enforcement vs guidance: The distinction between mechanisms that make an action impossible and instructions that ask for compliance.; On the exam
Arguably the single most tested idea in this domain. Map every candidate answer onto one side of it.; Covered in: Permissions: enforcement vs guidance →

Session state (Claude Code): The per-project conversational and tool state Claude Code maintains between turns.; On the exam
Distinct from durable project memory. Session state does not survive as a record of decisions.; Covered in: Claude Code architecture and the execution model →

Tool allowlist: An explicit set of permitted tools or commands, everything else refused.; On the exam
The deny-by-default posture headless automation requires.; Covered in: Permissions: enforcement vs guidance →

Domain 3: Prompt Engineering & Structured Output

20% of exam · 32 terms

Structured outputs: A response-format mechanism constraining the model's output to a supplied JSON Schema.; On the exam
One of two schema mechanisms. Use it when you want the response body itself to be conforming data.; Covered in: Structured outputs: two distinct features →

Strict tool schema: Schema enforcement applied to a tool's input, guaranteeing the tool_use input conforms.; On the exam
The other schema mechanism. Use it when the model must also act, not merely return data.; Covered in: Structured outputs: two distinct features →

output_config: The request field carrying the output format specification.; On the exam
Know that structure is configured, not requested in prose.; Covered in: Structured outputs: two distinct features →

JSON Schema: The vocabulary describing the required shape of a JSON document — types, required keys, enums, nesting.; On the exam
Support has documented limits. A question offering an exotic construct is often testing whether you know the boundaries.; Covered in: JSON Schema support and limits →

Syntax error vs semantic error: A syntax error is malformed or non-conforming output; a semantic error is well-formed output that is wrong.; On the exam
The most repeated trap in the domain. Schemas eliminate the first class entirely and the second not at all.; Covered in: Syntax errors vs semantic errors →

Validation-retry loop: Checking output against business rules in code and returning the specific violation to the model for another attempt.; On the exam
Feedback must name the violated rule. "Invalid, try again" produces the same output again.; Covered in: Syntax errors vs semantic errors →

Deterministic validation: Enforcing rules in ordinary code rather than by asking the model to check its own work.; On the exam
Preferred wherever the rule is expressible. A second model call to validate the first is weaker and costlier.; Covered in: Syntax errors vs semantic errors →

Few-shot prompting: Including worked examples in the prompt to demonstrate the desired behaviour.; On the exam
Boundary and edge cases teach more than typical cases. Example selection beats instruction rewording.; Covered in: Prompt construction for production →

System prompt: The instruction block establishing role, constraints and success criteria for the whole conversation.; On the exam
Also the natural home of the cacheable static prefix — a point where Domain 3 and Domain 5 intersect.; Covered in: Prompt construction for production →

XML tag structuring: Delimiting prompt sections with tags so instructions, examples and input data are unambiguously separated.; On the exam
The standard remedy when a long prompt starts behaving unpredictably.; Covered in: Structuring complex prompts with XML tags →

Prefill (removed): The legacy technique of seeding the start of the assistant's reply to force a format.; On the exam
Do not reach for it on current models. Format guarantees now come from schemas; tone comes from the system prompt.; Covered in: Prefill removal and its replacements →

temperature / top_p / top_k: Legacy sampling controls over randomness and candidate selection.; On the exam
Current models reject combinations that older material recommends. Do not answer a determinism question by lowering temperature — answer it structurally.; Covered in: Generation parameters and what replaced them →

Message Batches API: An asynchronous endpoint processing large request sets at a substantial discount with a long completion window.; On the exam
The discriminator is always latency tolerance. Never the answer for a user-facing path.; Covered in: Message Batches: economics and limits →

custom_id: The caller-supplied key on each batch request, used to match results back to source records.; On the exam
Results are not guaranteed to arrive in submission order. Joining by position is the tested mistake.; Covered in: Message Batches: economics and limits →

Partial batch failure: The case where some requests in a batch succeed and others fail.; On the exam
Per-request status must be inspected. Treating the batch as one atomic success silently drops records.; Covered in: Batch recovery and accuracy measurement →

Sample-then-scale: Validating prompt accuracy on a small synchronous sample before committing to a large batch run.; On the exam
The correct sequencing in any large-volume scenario. Discovering a prompt flaw after the full run is the avoidable outcome.; Covered in: Batch recovery and accuracy measurement →

Stratified accuracy: Measuring accuracy per category rather than as a single aggregate.; On the exam
Aggregates hide a change that improves common cases and destroys a rare but important one.; Covered in: Evaluating prompts: datasets, grading and regression →

Regression detection: Comparing a prompt change against a fixed evaluation set to catch degradation.; On the exam
Makes prompts shippable. Its absence is the defect in "the new prompt broke production" scenarios.; Covered in: Evaluating prompts: datasets, grading and regression →

Golden dataset: A stable labelled set of cases used as the benchmark across prompt versions.; On the exam
Must be fixed. Editing it alongside the prompt destroys comparability.; Covered in: Evaluating prompts: datasets, grading and regression →

Model-graded evaluation: Using a model with a rubric to score outputs that cannot be checked by exact match.; On the exam
A fallback, not a default. Prefer deterministic grading wherever the task permits it.; Covered in: Evaluating prompts: datasets, grading and regression →

Chain of thought: Prompting the model to reason step by step before answering.; On the exam
Helps on multi-step reasoning; adds latency and tokens on simple classification. Know when it is not worth it.; Covered in: Chain-of-thought and extended thinking →

Extended thinking: A model capability allocating additional internal reasoning before producing a response.; On the exam
Distinguish the capability from prompt-level chain-of-thought instructions.; Covered in: Chain-of-thought and extended thinking →

Multi-turn context accumulation: The growth of conversation history across turns, raising cost and diluting attention.; On the exam
The reason long agent sessions need editing, compaction or external memory.; Covered in: Multi-turn design and context accumulation →

Explicit success criteria: Stating in the prompt what a good output looks like, concretely enough to grade.; On the exam
Vague quality language produces vague output. Scenario answers that add criteria usually beat those that add emphasis.; Covered in: Prompt construction for production →

Role assignment: Establishing the persona and domain framing the model should adopt.; On the exam
A system-prompt concern, and part of what replaced prefill for tone control.; Covered in: Prompt construction for production →

Output token limit: The max_tokens ceiling on a single response.; On the exam
Truncated structured output is a limit problem. Tightening the schema does not fix it.; Covered in: JSON Schema support and limits →

Enum constraint: A schema construct restricting a field to a fixed value set.; On the exam
Makes an invalid category structurally impossible rather than merely discouraged.; Covered in: JSON Schema support and limits →

Nested schema: A schema with objects or arrays inside other objects.; On the exam
Deep nesting raises both token cost and failure rate. Flattening is often the better answer.; Covered in: JSON Schema support and limits →

Prompt versioning: Tracking prompt changes so behaviour differences can be attributed and rolled back.; On the exam
Treat prompts as code. "It worked last week" is unanswerable without it.; Covered in: Evaluating prompts: datasets, grading and regression →

Schema-guaranteed parse: The property that schema-constrained output can be deserialised without defensive parsing.; On the exam
If an answer still wraps json.loads in a retry, it is not using the mechanism.; Covered in: Structured outputs: two distinct features →

Instruction / data separation: Keeping user-supplied content clearly delimited from system instructions.; On the exam
A correctness measure and an injection-resistance measure at once.; Covered in: Structuring complex prompts with XML tags →

Latency tolerance: How long a path can acceptably wait for a result.; On the exam
The deciding property in every synchronous-versus-batch question.; Covered in: Message Batches: economics and limits →

Domain 4: Tool Design & MCP Integration

18% of exam · 32 terms

MCP (Model Context Protocol): An open protocol standardising how applications supply tools, data and prompts to language models.; On the exam
Know the roles and primitives. Vendor-specific claims about MCP fields are a common distractor.; Covered in: MCP architecture: host, client, server →

MCP host: The application the user interacts with, which manages clients and coordinates servers.; On the exam
Host, client and server are three distinct roles; questions conflate them deliberately.; Covered in: MCP architecture: host, client, server →

MCP client: The component inside the host maintaining a one-to-one connection with a server.; On the exam
One client per server connection — relevant to multi-server routing questions.; Covered in: MCP clients and multi-server routing →

MCP server: A program exposing tools, resources and prompts over the protocol.; On the exam
Know what belongs in each primitive; that choice is directly examinable.; Covered in: Building an MCP server →

Tools (MCP primitive): Model-invocable functions that perform actions, typically with side effects.; On the exam
For doing. Exposing a read-only catalogue as a tool is the classic misuse.; Covered in: MCP primitives and transports →

Resources (MCP primitive): Readable data the client can list and fetch as context.; On the exam
For reading. When a scenario says "browse the available documents", this is the primitive.; Covered in: MCP primitives and transports →

Prompts (MCP primitive): Reusable templated interactions a server offers.; On the exam
The least-remembered primitive and therefore a favourite exam target.; Covered in: MCP primitives and transports →

stdio transport: Communication over standard input and output, for a server running as a local subprocess.; On the exam
Right for local developer tooling. Cannot serve a remote team.; Covered in: MCP primitives and transports →

Streamable HTTP transport: HTTP-based transport for remote or shared MCP servers.; On the exam
Right for a service several people reach over a network. Brings authentication into scope.; Covered in: MCP primitives and transports →

JSON-RPC 2.0: The message format underlying MCP.; On the exam
Worth recognising by name; not usually tested at wire-format depth.; Covered in: MCP architecture: host, client, server →

Tool description: The natural-language text telling the model what a tool does and when to use it.; On the exam
The primary lever on selection accuracy. Fix confusion here rather than in the system prompt.; Covered in: Tool descriptions are the primary lever →

Tool schema: The JSON Schema describing a tool's parameters.; On the exam
Every schema is resent each turn — a real and recurring context cost.; Covered in: Designing tool inputs and outputs →

Enum vs freeform parameter: Constraining a parameter to a fixed set versus accepting arbitrary strings.; On the exam
Closed value sets should be enums. Freeform strings invite invalid values the tool must then reject.; Covered in: Designing tool inputs and outputs →

Machine identifier vs natural attribute: Whether a tool takes an opaque id or a human-meaningful description.; On the exam
Models handle natural attributes more reliably than ids they must have obtained elsewhere. Requiring an unavailable id is a design flaw.; Covered in: Designing tool inputs and outputs →

isError: The flag marking a tool result as an error.; On the exam
Study guides that invent isRetryable or errorCategory fields are wrong. Put your own retry semantics in the result payload.; Covered in: Tool errors and trust boundaries →

Structured error response: An error result carrying a class, a message and enough context for the caller to act.; On the exam
Actionability is the test. A bare "error" produces a blind retry.; Covered in: Tool errors and trust boundaries →

Empty result vs failed lookup: The distinction between "nothing matched" and "the search did not run".; On the exam
Returning an empty array for both makes the model report an outage as an absence of results.; Covered in: Tool errors and trust boundaries →

Trust boundary: The line between data the system controls and data that arrives from elsewhere.; On the exam
Tool output and server annotations are untrusted input. Self-reported safety claims are not a control.; Covered in: Tool errors and trust boundaries →

tool_choice: The request field steering tool use — auto, any, a named tool, or none.; On the exam
Forcing a specific tool removes a decision the model should not be making when the sequence is already known.; Covered in: Scaling the tool surface →

Tool surface bloat: Degradation in selection accuracy and context budget as the registered tool count grows.; On the exam
Fix structurally — route, group, or scope per subagent. Shortening descriptions makes selection worse.; Covered in: Scaling the tool surface →

Pagination metadata: Fields telling the caller a result set is partial and how to fetch the rest.; On the exam
Without it, a model treats the first page as the complete answer.; Covered in: Designing tool inputs and outputs →

Idempotency key: A caller-supplied identifier letting a server recognise a repeated request and return the original result.; On the exam
The remedy for the succeeded-but-response-lost case. A timeout is not evidence the operation did not happen.; Covered in: Idempotency, partial success and safe retries →

Partial success: A multi-item operation where some items succeeded and others failed.; On the exam
Report per-item status. A single overall boolean forces the caller to redo everything or lose information.; Covered in: Idempotency, partial success and safe retries →

Tool result normalisation: Presenting heterogeneous backend outputs in one consistent shape.; On the exam
Reduces the reasoning burden on the model and the surface for mis-parsing.; Covered in: Designing tool inputs and outputs →

MCP server scoping: Controlling which servers a project or user may reach.; On the exam
A supply-chain control. An unvetted server is executing code in your environment.; Covered in: MCP security and production hardening →

Multi-server routing: Directing calls across several connected servers, including handling name collisions.; On the exam
Two servers offering similarly named tools is a real operational problem and a plausible exam scenario.; Covered in: MCP clients and multi-server routing →

Server annotations: Metadata a server supplies describing its own tools, such as whether they are read-only.; On the exam
Self-reported and therefore untrusted. Enforce the property yourself; do not accept the claim.; Covered in: MCP security and production hardening →

Least-privilege tool grants: Giving each agent or context only the tools it needs.; On the exam
Recurs across Domains 1, 2 and 4 — a reliably correct instinct.; Covered in: MCP security and production hardening →

Built-in tools: Tools provided by the platform, such as server-side web search, as distinct from ones you implement.; On the exam
Some run server-side and can trigger pause_turn, linking this domain back to Domain 1.; Covered in: Scaling the tool surface →

Tool input validation: Checking arguments inside the tool before acting on them.; On the exam
Schema conformance is not business validity. The tool still owns its own rules.; Covered in: Designing tool inputs and outputs →

Interface stability: Keeping tool names and schemas stable so callers and cached prefixes do not break.; On the exam
Schema churn silently invalidates prompt caches — a Domain 4 decision with a Domain 5 cost.; Covered in: Building an MCP server →

Read-only vs mutating tool: Whether a tool observes or changes state.; On the exam
Drives permission design, retry safety and idempotency requirements alike.; Covered in: MCP security and production hardening →

Domain 5: Context Management & Reliability

15% of exam · 31 terms

Prompt caching: Reusing a previously processed prompt prefix to cut cost and latency on repeated calls.; On the exam
Prefix-based. Everything static must precede everything variable, or there is nothing stable to match.; Covered in: Prompt caching mechanics →

Cache breakpoint: The marker designating how much of the prompt prefix should be cached.; On the exam
Placement is the whole skill. Several breakpoints suit prompts whose layers change at different rates.; Covered in: Prompt caching mechanics →

Prefix matching: The rule that a cache hit requires an exact match from the very start of the prompt.; On the exam
Explains why a one-character change near the top invalidates everything after it.; Covered in: Prompt caching mechanics →

Cache write vs cache read: Writing to the cache costs more than a normal input token; reading from it costs far less.; On the exam
A prefix used once is a net loss. Caching pays off with reuse, and the break-even point is calculable.; Covered in: Cache economics and verification →

Cache verification: Confirming a cache hit from the cache token counts in the response usage field.; On the exam
Assumed caching is the common production error. Measure it.; Covered in: Cache economics and verification →

Silent cache invalidator: An element that varies per request while sitting inside the cached prefix — a timestamp, session id, or user name.; On the exam
Costs stay high with no error anywhere. A frequent "why is this expensive" scenario.; Covered in: Invalidation hierarchy and silent invalidators →

Invalidation hierarchy: The rule that a change invalidates its own segment and everything after it, not before.; On the exam
Order the prompt from most stable to most volatile.; Covered in: Invalidation hierarchy and silent invalidators →

Context editing: Removing stale content, typically old tool results, from the conversation to reclaim window space.; On the exam
Surgical. Contrast with compaction, which summarises everything and loses detail wholesale.; Covered in: Context editing, compaction and memory →

Compaction: Summarising the conversation so far and continuing from the summary.; On the exam
Buys space at the cost of detail. When exact earlier values matter, it is the wrong tool.; Covered in: Context editing, compaction and memory →

Memory tool: A mechanism for writing durable facts outside the context and retrieving them on demand.; On the exam
The only one of the three that survives a restart.; Covered in: Context editing, compaction and memory →

Lost in the middle: The effect where material in the middle of a long context is recalled less reliably than material at either end.; On the exam
Argues for retrieval and deliberate placement. A larger window does not fix it.; Covered in: Long-context effects →

Context window: The total tokens a model can attend to in one request.; On the exam
Presence is not attention. "Use a bigger window" is usually a distractor.; Covered in: Long-context effects →

Selective retrieval: Fetching only the relevant material rather than loading a whole corpus.; On the exam
Beats full loading on cost and, because of position effects, often on accuracy too.; Covered in: RAG architecture: chunking, embedding, retrieval →

RAG: Retrieval-augmented generation: fetching relevant documents and grounding the answer in them.; On the exam
Know the pipeline stages and the failure mode at each.; Covered in: RAG architecture: chunking, embedding, retrieval →

Chunking: Splitting documents into retrievable units, usually with overlap and preserved metadata.; On the exam
Chunks too small lose context; too large dilute relevance. Overlap prevents boundary loss.; Covered in: RAG architecture: chunking, embedding, retrieval →

Embedding: A vector representation capturing semantic meaning for similarity search.; On the exam
Strong on paraphrase, weak on exact identifiers — the reason hybrid retrieval exists.; Covered in: RAG architecture: chunking, embedding, retrieval →

Semantic search: Retrieval by meaning rather than by literal term overlap.; On the exam
Misses exact error codes, SKUs and product names — precisely where users expect exactness.; Covered in: Semantic, keyword and hybrid retrieval →

Keyword search: Retrieval by literal term matching.; On the exam
Exact where semantic search is fuzzy; blind to paraphrase where semantic search is strong.; Covered in: Semantic, keyword and hybrid retrieval →

Hybrid retrieval: Combining semantic and keyword results into one fused ranking.; On the exam
The default correct answer when a scenario mixes conceptual questions with exact identifiers.; Covered in: Semantic, keyword and hybrid retrieval →

Reranking: A second pass reordering retrieved candidates by relevance before they reach the model.; On the exam
Improves precision when first-stage retrieval returns many plausible chunks.; Covered in: Semantic, keyword and hybrid retrieval →

Citation: A reference tying a generated claim back to the source passage supporting it.; On the exam
Makes answers auditable. Without it, a hallucination is indistinguishable from a retrieved fact.; Covered in: Production RAG: multi-index, citation and grounding →

Grounding check: A verification pass flagging claims not supported by retrieved sources.; On the exam
The mechanism behind "the system must not invent facts" requirements.; Covered in: Production RAG: multi-index, citation and grounding →

Provenance: The record of where a piece of information came from.; On the exam
Required to resolve conflicts and to let a human audit a decision.; Covered in: Provenance, conflict and escalation →

Source conflict: Two retrieved sources disagreeing.; On the exam
Check dates first — an apparent contradiction is often just staleness. Genuine conflict should surface, not be silently resolved.; Covered in: Provenance, conflict and escalation →

publication_date metadata: Source timestamp metadata carried through retrieval.; On the exam
What lets a system distinguish "the policy changed" from "the sources disagree".; Covered in: Provenance, conflict and escalation →

Escalation threshold: A predefined condition — value, ambiguity, low coverage, conflict — that routes a case to a human.; On the exam
Must be enforced in code. A prompt instruction to escalate is not a threshold.; Covered in: Provenance, conflict and escalation →

Confidence calibration: The degree to which stated confidence matches observed accuracy.; On the exam
An uncalibrated confidence score is worse than none — it licenses unwarranted automation.; Covered in: Provenance, conflict and escalation →

Coverage: How much of the required evidence a run actually obtained.; On the exam
Incomplete coverage must be stated in the output. Answering confidently from partial evidence is the failure.; Covered in: Provenance, conflict and escalation →

Token budget: The deliberate allocation of context and cost across system prompt, tool schemas, retrieved material and conversation.; On the exam
Tool schemas and memory files are recurring line items, not free overhead.; Covered in: Cache economics and verification →

Rate limiting: Platform caps on request and token throughput.; On the exam
Handle with backoff and queuing. A rate limit is transient — retryable, unlike an authorisation failure.; Covered in: Cache economics and verification →

Observability: Instrumentation of token usage, cache hits, tool latency, error classes and escalation rates.; On the exam
You cannot tune caching, cost or reliability on assumption. Measurement is the recurring right answer.; Covered in: Cache economics and verification →