Quick Reference and Glossary

Use this page in the final days before your exam. It condenses the numbers, facts, decision rules and terms that other pages teach in full: the cheat sheets and decision rules link to the page that teaches each topic, and glossary rows name the objectives that use each term. Product facts are as of September 2026; where the documentation changed after the July 2026 exam guides, the page gives both versions (usually in a warning box) and the wording the exam expects.

Exam numbers

The logistics numbers for the four exams, from the four exam guides (Version 1.0, effective July 2026), the Anthropic Certification Exam Policy, and the live program pages (the Anthropic Partner Academy FAQ and Policies pages, and Pearson VUE's Anthropic pages) as of September 2026. Where the guides and the live pages disagree, the row gives both.

API cheat sheet

CCDV-F covers Claude API mechanics (messages, tools, streaming, vision, thinking, caching, third-party vendors and batch use), cost and token management, and error handling. The CCAR-F appendix names stop_reason values, tool_choice options, max_tokens, system prompts and the Message Batches API among the technologies that "might appear on the exam", explicitly tests stop-reason loop control, tool_choice configuration and batch appropriateness, and puts streaming, rate limits and pricing calculations, vision, token counting algorithms, cloud provider configuration and caching implementation details beyond knowing caching exists out of scope (CCAR-F guide). Model facts are as of September 2026.

Request fields

Stop reasons

• Exam loop rule (CCAR-F 1.1): continue while stop_reason is "tool_use", finish on "end_turn"; the anti-patterns the guide names are in Reliability rules. The API docs describe the same loop: while stop_reason is tool_use, run the tools and continue; exit on any other stop reason. Loops that use server tools must also handle pause_turn. Answer in the guide's tool_use versus end_turn terms.
• Not errors: stop reasons arrive in successful responses; failures are HTTP 4xx and 5xx.
• Streaming: stop_reason is null in message_start and arrives in message_delta.
• Beta extra: with on-demand compaction (beta header compact-2026-09-04), or threshold compaction (compact-2026-01-12) with pause_after_compaction enabled, a response can also stop with compaction.

tool_choice

• With any or tool, the API prefills the assistant turn, so Claude writes no explanation before the call. For an explanation plus a call, use auto and ask for the tool in the user message.
• Forced choice (any or tool) errors with manual extended thinking and works with adaptive thinking. Opus 5.5, Fable 5.1 and Mythos 5.1 reject any and tool with a 400 invalid_request_error whatever the thinking setting (the token counting endpoint too); auto and none still work there.
• Changing tool_choice invalidates cached message blocks; tool definitions and the system prompt stay cached.

Prompt caching numbers

Message Batches numbers

Error codes

• SDK retries: the official SDKs retry transient failures (connection errors, rate limits and 5xx) twice by default with exponential backoff, honoring retry-after when present. The Python SDK's list is connection errors, 408, 409, 429 and 500 or above; set max_retries (0 disables).
• Error body: JSON with a top-level error object (type, message) plus request_id; catch the SDK's typed exceptions (such as Python RateLimitError) instead of matching message strings.
• Refusals are not errors: stop_reason: "refusal" arrives with HTTP 200.

Key headers and endpoints

Context, tokens, vision and platforms

CCDV-F names vision and invoking Claude through third-party vendors; CCAR-F lists vision, token counting algorithms and cloud provider configurations as out of scope.

Models at a glance (as of September 2026)

Batch requests are 50% off. The pricing page's rule of thumb is Haiku for simple tasks, Sonnet for most production workloads and Opus for the most complex reasoning; the models overview says that if you are unsure, start with Claude Opus 5.5 for most workloads, and it points to Claude Fable 5.1 for demanding reasoning and long-horizon agentic work. The guides frame model choice as Opus versus Sonnet versus Haiku trade-offs in cost, speed and quality, so learn the reasoning rather than this month's lineup.

Claude Code cheat sheet

Claude Code Configuration & Workflows is 20% of CCAR-F. On CCDV-F, Domain 3 (Claude Code) is 3.1%, and the Domain 2 skill Configuration Management (4.1%) separately covers CLAUDE.md files, settings.json, model version pinning, prompt versioning and plugin dependencies. CCAR-P Domain 7 (7%) includes configuring Claude tools and environments for teams, with Claude Code as the guide's example. Product values below are as of September 2026 (changelog v2.1.280, September 22, 2026). The exam decision rules for Claude Code are collected under Claude Code layer rules.

Paths and files

Loading and precedence

Frontmatter keys

A user-only skill from the skills docs. Saved as .claude/skills/deploy/SKILL.md, it becomes /deploy (the directory name sets the command), runs in a forked subagent, and Claude never loads it on its own.

---
name: deploy
description: Deploy the application to production
context: fork
disable-model-invocation: true
---

Deploy the application:
1. Run the test suite
2. Build the application
3. Push to the deployment target

Built-in subagents

The three built-ins a context: fork skill can name as its agent. The docs also list helper agents such as statusline-setup (used for /statusline) and claude-code-guide (questions about Claude Code features).

• Exam framing: CCAR-F 3.4 uses the Explore subagent to isolate verbose discovery output and return summaries, so a multi-phase task does not exhaust the main context window.
• Inheritance and nesting: built-in subagents inherit the parent conversation's permissions. By default a subagent can spawn its own subagents up to three layers below the main conversation (CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH changes this).
• Turning them off: deny Agent(Explore) to disable one subagent; deny the Agent tool itself to stop all delegation.

Exam guide vs current docs

Commands

• Input prefixes and keys: ! runs a shell command in the session, @ mentions a file, Shift+Tab cycles permission modes, Esc interrupts, Ctrl+B backgrounds a running task, Ctrl+G opens a proposed plan in your editor.
• Gone: the # quick-memory shortcut (removed in v2.0.70; ask Claude to edit CLAUDE.md instead) and /vim (removed in v2.1.92).

CLI flags and environment variables

From the permission modes, headless and CLI reference pages:

# CI run: never prompts; any call outside the allowlist that would prompt is denied
claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"

# Machine-readable result for the next pipeline step
claude -p "Summarize this project" --output-format json | jq -r '.result'

# Branch an earlier session into a new session ID
claude --resume abc123 --fork-session

Hook events

A selection; the hooks reference lists more events, such as PostToolBatch and MessageDisplay.

• Where hooks live: under "hooks" in a settings file, nested event, then matcher group, then handlers. Plugins use hooks/hooks.json, and skill or subagent frontmatter can carry hooks too; there is no standalone hooks file for user or project config.
• Handler types: command, http, mcp_tool, prompt, agent (agent hooks are experimental; the docs prefer command hooks for production). Default timeouts: 600 seconds for command, http and mcp_tool; 30 for prompt; 60 for agent.
• Exit codes: 0 is success (stdout is parsed as JSON only if it starts with { and ends with }). 2 is a blocking error on events that can block, and even a JSON permissionDecision of allow cannot override it. For most events, 1 and other codes are non-blocking errors, so the action proceeds. Use exit 2 to enforce a policy.
• PreToolUse JSON: hookSpecificOutput.permissionDecision of allow, deny, ask or defer; when hooks disagree, deny beats defer beats ask beats allow. updatedInput replaces the whole input object. The old top-level decision and reason for PreToolUse are deprecated (approve and block map to allow and deny); events such as PostToolUse, Stop and UserPromptSubmit still use a top-level decision, whose only value is block.
• Limits: hooks can tighten restrictions but not loosen them past what permission rules allow; a PreToolUse deny blocks even in bypassPermissions. A PermissionRequest allow does not override a matching deny rule.
• Matchers: case-sensitive. "*", "" or no matcher matches every occurrence. A matcher of only letters, digits, _, -, spaces, commas and | is an exact name or list (Edit|Write); any other character makes it an unanchored JavaScript regex (Edit.* also matches NotebookEdit). Match a whole MCP server with mcp__server__.*.
• Trust: all matching hooks run in parallel. Interactive sessions hold back settings-file hooks until you accept the workspace trust dialog; -p and SDK sessions treat the folder as trusted, so a repository's committed hooks run there without a prompt.

Both snippets are from the hooks reference. In a settings file, the matcher narrows to Bash calls and the if field (permission rule syntax) narrows to commands matching rm *, so the script only spawns when both match. The script, saved as .claude/hooks/block-rm.sh and made executable, blocks by writing the reason to stderr and exiting 2. The reference pairs the same settings block with a script that prints a JSON permissionDecision of deny when the command contains rm -rf; exit 2 and a JSON deny are two ways to block a call.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(rm *)",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh",
            "args": []
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# Reads JSON input from stdin, checks the command
input=$(cat)
command=$(jq -r '.tool_input.command' <<<"$input")

if [[ "$command" == rm* ]]; then
  echo "Blocked: rm commands are not allowed" >&2
  exit 2  # Blocking error: tool call is prevented
fi

exit 0  # No decision: the normal permission flow applies

Permission modes

• Deny always wins: deny rules block in every mode, including bypassPermissions, where allow rules have no effect.
• No mode approves everything: even bypassPermissions does not auto-approve tools matched by an explicit ask rule, AskUserQuestion, or rm and rmdir removals that target a critical path such as the filesystem root or your home directory.
• Starting mode: --permission-mode (or --dangerously-skip-permissions), then permissions.defaultMode in a settings file, then the built-in default. As of September 2026 the built-in default is auto on Pro, Max and Team plans, and Manual (default) for -p runs, the Agent SDK, Enterprise plans, Console API keys and the cloud platforms.
• Switching: Shift+Tab cycles default, acceptEdits, plan (optional modes slot in after plan; dontAsk never appears). A defaultMode of auto or bypassPermissions does not take effect from project or local settings.
• Plan mode: enter with Shift+Tab, /plan or claude --permission-mode plan; make it a project default by setting permissions.defaultMode to "plan" in .claude/settings.json.

• Each part of a compound command (&&, ;, pipes and similar) must match a rule on its own.
• A Bash deny rule is not a security boundary: Bash(rm *) does not stop /bin/rm -rf build/. For enforcement, add the sandbox or a PreToolUse hook.

A permissions block from the settings reference: npm run scripts run without asking, git push commands ask first, a deny rule covers reads of ./.env (a rule, not an OS-level block), and sessions start in acceptEdits.

{
  "permissions": {
    "allow": ["Bash(npm run *)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)"],
    "defaultMode": "acceptEdits"
  }
}

settings.json keys

Claude Code in CI/CD

Agent SDK cheat sheet

The Claude Agent SDK is a Python and TypeScript library that runs the Claude Code binary inside a process you operate, so your agent gets Claude Code's built-in tools, agent loop, context management, permissions, sessions and hooks. The full treatment is in The Claude Agent SDK; this section is the revision sheet.

On the exams, the CCAR-F appendix lists the SDK's agent definitions, agentic loops, stop_reason handling, hooks, subagent spawning via the Task tool and allowedTools configuration, and three of its six scenarios (1, 3 and 4) build with the SDK. On CCDV-F, the Agent Construction with Claude skill (5.3%) covers the Agent SDK, custom agent loops and harnesses, managed agent deployment models and hooks for deterministic actions.

Four ways to build an agent

CCDV-F names "managed agent deployment models (self-hosted vs. Anthropic-hosted)". In current docs that maps to where Managed Agents sessions run: an Anthropic-managed cloud sandbox, or a self-hosted sandbox on your own infrastructure. Keep the two meanings of self-hosted apart:

• Self-hosting the Agent SDK: the library and its claude subprocess run in a process you operate, so the loop, tools and session files are all on your side.
• A Managed Agents self-hosted sandbox: orchestration stays on Anthropic's side and tool execution moves into infrastructure you control (the agent's code, filesystem and network egress stay in your environment), but tool inputs and outputs still flow to Anthropic's control plane so Claude can see results. The docs call it a good fit for data that cannot leave your network boundary, internal services that are not publicly routable, or your own compliance and audit controls.

Names that changed

Minimal agent

import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, AssistantMessage, ResultMessage

async def main():
    # Agentic loop: streams messages as Claude works
    async for message in query(
        prompt="Review utils.py for bugs that would cause crashes. Fix any issues you find.",
        options=ClaudeAgentOptions(
            allowed_tools=["Read", "Edit", "Glob"],  # Auto-approve these tools
            permission_mode="acceptEdits",  # Auto-approve file edits
        ),
    ):
        if isinstance(message, AssistantMessage):
            for block in message.content:
                if hasattr(block, "text"):
                    print(block.text)
                elif hasattr(block, "name"):
                    print(f"Tool: {block.name}")
        elif isinstance(message, ResultMessage):
            print(f"Done: {message.subtype}")

asyncio.run(main())

import { query } from "@anthropic-ai/claude-agent-sdk";

for await (const message of query({
  prompt: "Review utils.py for bugs that would cause crashes. Fix any issues you find.",
  options: {
    allowedTools: ["Read", "Edit", "Glob"], // Auto-approve these tools
    permissionMode: "acceptEdits" // Auto-approve file edits
  }
})) {
  if (message.type === "assistant" && message.message?.content) {
    for (const block of message.message.content) {
      if ("text" in block) {
        console.log(block.text);
      } else if ("name" in block) {
        console.log(`Tool: ${block.name}`);
      }
    }
  } else if (message.type === "result") {
    console.log(`Done: ${message.subtype}`);
  }
}

Options that appear in questions

The minimal default system prompt leaves out the Claude Code preset's safety instructions and environment context, and it differs from claude -p, which uses the Claude Code system prompt. CLAUDE.md loading is controlled by setting_sources, not by the preset.

Permission modes and evaluation order

The six modes (default, dontAsk, acceptEdits, plan, auto, bypassPermissions) are defined in the Claude Code cheat sheet. What changes when the SDK runs them:

A tool request passes through these steps in order:

1. Hooks
2. Deny rules
3. Ask rules
4. Permission mode
5. Allow rules

6. The canUseTool callback

7. A hook that returns allow does not skip the deny and ask rules.

8. Auto-approved calls never reach canUseTool. A check that must run on every call belongs in a PreToolUse hook, whose deny applies even in bypassPermissions.
9. allowed_tools=["*"] or ["mcp__*"] is ignored with a startup warning; globs work only after a literal mcp__<server>__ prefix, as in mcp__puppeteer__*.
10. set_permission_mode() / setPermissionMode() changes the mode mid-session.

Messages and results

A turn in the SDK is one tool-use round trip, and max_turns counts only those. The Claude Code glossary uses turn for one complete response to a user message, however many tool calls it contains.

TypeScript has no session-holding client: pass continue: true on later query() calls. Streaming input mode is the SDK's preferred mode; single-message input suits stateless environments such as a lambda function.

Hooks

CCAR-F's "tool call interception" is the PreToolUse event, and its data-normalization hooks (1.5-S1) are PostToolUse. The guide's rule is to choose hooks over prompt-based enforcement when business rules require guaranteed compliance (1.5-S3). The block below enforces the guide's refund example. It is adapted from the SDK hooks docs' block_etc_writes example; the server name billing, the tool process_refund and the amount field are illustrative, and the limit of 500 comes from the "refunds exceeding $500" example in CCAR-F 1.5-S2.

from claude_agent_sdk import ClaudeAgentOptions, HookMatcher

REFUND_LIMIT = 500

async def enforce_refund_limit(input_data, tool_use_id, context):
    amount = input_data["tool_input"].get("amount", 0)
    if amount > REFUND_LIMIT:
        return {
            # Top-level field: message shown to the user
            "systemMessage": "Refund above limit routed to a human agent.",
            "hookSpecificOutput": {
                "hookEventName": input_data["hook_event_name"],
                "permissionDecision": "deny",
                # Shown to Claude for "deny", so it can switch to the escalation workflow
                "permissionDecisionReason": "Refunds over $500 require human approval. Escalate to a human agent with a structured handoff summary instead.",
            },
        }
    return {}

options = ClaudeAgentOptions(
    hooks={"PreToolUse": [HookMatcher(matcher="mcp__billing__process_refund", hooks=[enforce_refund_limit])]}
)

More hook patterns, including a prerequisite gate and timestamp normalization: Hooks in the SDK.

Subagents

from claude_agent_sdk import ClaudeAgentOptions, AgentDefinition

options = ClaudeAgentOptions(
    # Auto-approve these tools
    allowed_tools=["Read", "Grep", "Glob", "Agent"],
    agents={
        "code-reviewer": AgentDefinition(
            # description tells Claude when to use this subagent
            description="Expert code review specialist. Use for quality, security, and maintainability reviews.",
            # prompt defines the subagent's behavior and expertise
            prompt="You are a code review specialist with expertise in security, performance, and best practices. ...",  # shortened here
            # tools restricts what the subagent can do (read-only here)
            tools=["Read", "Grep", "Glob"],
            # model overrides the default model for this subagent
            model="sonnet",
        ),
    },
)

Sessions

• Capture the ID from session_id on the result message; it is present on every result subtype.
• Sessions persist the conversation, not the filesystem. Forking branches history only, so a forked agent's file edits are real. File checkpointing tracks Write, Edit and NotebookEdit changes (not Bash), and rewinding files does not rewind the conversation.
• Transcripts live in ~/.claude/projects/<encoded-cwd>/*.jsonl. TypeScript persistSession: false turns persistence off, and such sessions cannot be resumed.
• resume_session_at (resumeSessionAt in TypeScript) loads a session only up to a given message UUID, usually together with fork_session.
• Sessions created by claude -p or the Agent SDK are left out of the session picker and out of claude --continue (claude -p --continue includes them); resume them by ID.
• Name a CLI session at startup with claude -n auth-refactor or mid-session with /rename.
• To move work between hosts, passing captured results into a fresh session's prompt is often more reliable than shipping transcript files.

# Fork: branch from session_id into a new session; the original is untouched
async for message in query(
    prompt="Instead of JWT, outline how OAuth2 would work for the auth module",
    options=ClaudeAgentOptions(
        resume=session_id,
        fork_session=True,
        max_turns=5,
    ),
):
    if isinstance(message, ResultMessage):
        forked_id = message.session_id  # The fork's ID, distinct from session_id

When to resume and when to start fresh is a decision rule: see Context rules.

SDK custom tools

Custom tools are functions you expose through the SDK's in-process MCP server, which runs inside your application rather than as a separate process. A tool has four parts (name, description, input schema, handler). TypeScript schemas are Zod; Python takes a dict of names to types or a full JSON Schema dict. The blocks below condense the weather-tool examples from the custom tools docs (handler bodies elided) and include the docs' readOnlyHint annotation.

from typing import Any
from claude_agent_sdk import tool, create_sdk_mcp_server, query, ClaudeAgentOptions, ToolAnnotations

@tool(
    "get_temperature",
    "Get the current temperature at a location",
    {"latitude": float, "longitude": float},
    annotations=ToolAnnotations(readOnlyHint=True),  # Lets Claude batch this with other read-only calls
)
async def get_temperature(args: dict[str, Any]) -> dict[str, Any]:
    ...
    return {"content": [{"type": "text", "text": "Temperature: ..."}]}

weather_server = create_sdk_mcp_server(
    name="weather",
    version="1.0.0",
    tools=[get_temperature],
)

options = ClaudeAgentOptions(
    mcp_servers={"weather": weather_server},
    allowed_tools=["mcp__weather__get_temperature"],
)

import { tool, createSdkMcpServer, query } from "@anthropic-ai/claude-agent-sdk";
import { z } from "zod";

const getTemperature = tool(
  "get_temperature",
  "Get the current temperature at a location",
  { latitude: z.number(), longitude: z.number() },
  async (args) => ({ content: [{ type: "text", text: "..." }] }),
  { annotations: { readOnlyHint: true } } // Lets Claude batch this with other read-only calls
);

const weatherServer = createSdkMcpServer({ name: "weather", version: "1.0.0", tools: [getTemperature] });

for await (const message of query({
  prompt: "What's the temperature in San Francisco?",
  options: { mcpServers: { weather: weatherServer }, allowedTools: ["mcp__weather__get_temperature"] }
})) { /* ... */ }

• The handler returns content (required) plus optional structuredContent and isError. The Python @tool decorator forwards only content and is_error.
• A handler error does not stop the loop: an uncaught exception becomes an error result, and returning isError: true lets you write the message Claude reads.
• Custom tools run sequentially by default. readOnlyHint: true lets the tool run in parallel with other read-only tools; the other annotations are informational. Annotations are metadata, not enforcement.
• tools: [] removes every built-in, so Claude can use only your MCP tools.

Structured output, cost and hosting

• Structured output: pass a JSON Schema in output_format / outputFormat. The SDK validates with JSON Schema draft-07 and re-prompts on a mismatch; failure ends with error_max_structured_output_retries, and a success without structured_output also counts as failure. The CLI equivalent is --json-schema (print mode only).
• Cost fields: total_cost_usd and costUSD are client-side estimates, not billing data, so do not bill end users from them. usage excludes subagent activity; modelUsage (model_usage in Python) covers the whole tree. A resumed call reports the whole session's spend, while max_budget_usd counts only the call's own spend.
• Hosting: the SDK supervises a claude subprocess that owns a shell, a working directory and on-disk sessions. Transcripts, CLAUDE.md memory and working files do not survive a container restart; a SessionStore mirrors transcripts only. A starting size is 1 GiB RAM, 5 GiB disk and 1 CPU per agent.
• Multi-tenant isolation: setting_sources=[], CLAUDE_CODE_DISABLE_AUTO_MEMORY=1, and a per-tenant CLAUDE_CONFIG_DIR and cwd. Keep credentials out of the agent's environment: a proxy outside it injects them, so the agent never sees them.
• Managed Agents, as of September 2026: four concepts (Agent, Environment, Session, Events), the managed-agents-2026-04-01 beta header, permission policies (always_allow, always_ask, auto) set per toolset with per-tool overrides (the agent toolset defaults to always_allow, MCP toolsets to always_ask, and custom tools are not governed by policies), no server-side max_turns, and no eligibility for Zero Data Retention or HIPAA BAA coverage.

Deeper coverage: Subagents in the SDK, Permissions and enforcement, Sessions, resumption and forking, Custom tools in the SDK and Deployment models.

MCP cheat sheet

The Model Context Protocol is the open standard Anthropic open-sourced on November 25, 2024 "for connecting AI assistants to the systems where data lives". All MCP messages are JSON-RPC 2.0. As of September 2026 the current specification revision is 2026-07-28; the one before it was 2025-11-25. The full treatment starts at MCP architecture.

On the exams, MCP sits in CCAR-F Domain 2 (Tool Design & MCP Integration, 18%) and CCDV-F Domain 8 (Tools and MCPs, 10.6%), whose MCP Server Development skill covers authoring, deploying and integrating servers, their resources, tools and prompts, and communication patterns. CCAR-P asks you to choose among integration mechanisms (MCP, API/CLI, agent-to-agent).

Architecture

MCP has two layers: a data layer (the JSON-RPC protocol, primitives and notifications) and a transport layer (connection setup, message framing and authorization). An application gathers the tools of every connected server into one registry for the model.

Server primitives: who controls what

The CCAR-F in-scope list sums up the design rule as "resources for content catalogs, tools for actions": expose issue summaries, documentation hierarchies or database schemas as resources so the agent does not burn tool calls exploring.

Transports

• An HTTP server MUST validate the Origin header (403 when invalid) to stop DNS rebinding, SHOULD bind to localhost rather than 0.0.0.0 when local, and SHOULD authenticate every connection.
• The CCDV-F guide lists "communication patterns (stdio, sockets, client vs. server)"; in the spec, sockets fall under the custom transports in the table above. Claude Code also accepts WebSocket servers (type: "ws"), configured only through .mcp.json or claude mcp add-json.

Two protocol eras

Tool definitions and results

Clients MUST treat annotations as untrusted unless they come from a trusted server. A tool result carries unstructured content (text, image, audio, resource links, embedded resources) and/or structuredContent, which in 2026-07-28 may be any JSON value. A tool that returns structured content SHOULD also return the serialized JSON in a text block. structuredContent is server data and has nothing to do with the Claude API's structured outputs feature.

Errors

Codes to recognize: -32700 and -32600 to -32603 are the standard JSON-RPC codes; -32602 (Invalid params) covers an unknown tool, missing prompt arguments and invalid cursors; -32603 is an internal error; -32022 is UnsupportedProtocolVersion in 2026-07-28. If a tool reports its own failure as a protocol error instead of inside the result, the model cannot see that an error occurred.

The spec's tool execution error is isError: true plus explanatory content; the spec's tools page has no field named errorCategory, isRetryable or retriable. CCAR-F adds application-level error metadata: an errorCategory (transient, validation, permission), an isRetryable flag and a human-readable description (the guide does not say where these fields go; the example below carries them in the isError result's text content), with retriable: false and a customer-friendly explanation for business-rule violations. The guide's knowledge bullet names business errors as a fourth category, so the example below uses business as a category value; that is a reconciliation of the guide's two lists, not guide wording. The example is illustrative: its envelope follows the spec's tool execution error example (resultType, content, isError: true), and the text payload is ours.

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "{\"errorCategory\": \"business\", \"isRetryable\": false, \"description\": \"This order is outside the return window, so a refund cannot be issued. Explain the return policy to the customer and offer a human agent.\"}"
      }
    ],
    "isError": true
  }
}

Servers on 2025-11-25 or earlier do not send resultType; a 2026-07-28 client MUST treat an absent resultType as "complete".

MCP in Claude Code

claude mcp add --transport http notion https://mcp.notion.com/mcp                 # remote HTTP (local scope by default)
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
  -- npx -y airtable-mcp-server                                                   # stdio: server command after --
claude mcp add --transport http shared-server --scope project https://example.com/mcp   # writes .mcp.json
claude mcp add --transport http hubspot --scope user https://mcp.hubspot.com/anthropic  # all projects
claude mcp list
claude mcp reset-project-choices # reset .mcp.json approvals

{
  "mcpServers": {
    "api-server": {
      "type": "http",
      "url": "${API_BASE_URL:-https://api.example.com}/mcp",
      "headers": {
        "Authorization": "Bearer ${API_KEY}"
      }
    }
  }
}

MCP in the API and the Agent SDK

curl https://api.anthropic.com/v1/messages \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: mcp-client-2025-11-20" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 1000,
    "messages": [{"role": "user", "content": "What tools do you have available?"}],
    "mcp_servers": [
      { "type": "url", "url": "https://example-server.modelcontextprotocol.io/sse",
        "name": "example-mcp", "authorization_token": "YOUR_TOKEN" }
    ],
    "tools": [
      { "type": "mcp_toolset", "mcp_server_name": "example-mcp",
        "default_config": { "enabled": false },
        "configs": { "search_events": { "enabled": true } } }
    ]
  }'

from claude_agent_sdk import query, ClaudeAgentOptions, ResultMessage

options = ClaudeAgentOptions(
    mcp_servers={
        "claude-code-docs": {"type": "http", "url": "https://code.claude.com/docs/mcp"}
    },
    allowed_tools=["mcp__claude-code-docs__*"],
)

The cURL tab joins the connector docs' basic request to their allowlist toolset; search_events is the tool name from the docs' calendar allowlist example, shown here only to illustrate the shape. An allowlist sets default_config.enabled: false, then enables named tools in configs, and tool-specific configs override default_config. The opposite, a denylist of write or destructive tools, is what the docs recommend for read-only assistants or when you want a human confirmation step before state changes. The Python tab is the Agent SDK MCP docs' example (the query() loop omitted). In-process SDK tools are covered under SDK custom tools.

Building a server

The Python tab is the v2 Python SDK README example plus the mcp.run(transport="stdio") entry point from the 2026-07-28 build-server tutorial; the TypeScript tab is the v2 TypeScript SDK README example. In Python the type hints are the schema, so no hand-written JSON Schema is needed.

from mcp.server import MCPServer

mcp = MCPServer("Demo")

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b

@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
    """Greet someone by name."""
    return f"Hello, {name}!"

if __name__ == "__main__":
    mcp.run(transport="stdio")

import { McpServer } from '@modelcontextprotocol/server';
import { StdioServerTransport } from '@modelcontextprotocol/server/stdio';
import * as z from 'zod/v4';

const server = new McpServer({ name: 'greeting-server', version: '1.0.0' });

server.registerTool(
    'greet',
    {
        description: 'Greet someone by name',
        inputSchema: z.object({ name: z.string() })
    },
    async ({ name }) => ({
        content: [{ type: 'text', text: `Hello, ${name}!` }]
    })
);

async function main() {
    const transport = new StdioServerTransport();
    await server.connect(transport);
}
main();

• Older tutorials use the v1 names: from mcp.server.fastmcp import FastMCP in Python and the @modelcontextprotocol/sdk package in TypeScript. pip install mcp now installs the 2.x line.
• A stdio server must never write to stdout: print() in Python or console.log() in TypeScript corrupts the JSON-RPC stream. Log to stderr.
• Test with the MCP Inspector: npx @modelcontextprotocol/inspector for the web UI, --cli for scripts and CI.
• CCAR-F lists deploying or hosting MCP servers as out of scope; CCDV-F's MCP Server Development skill includes server authoring and deployment.

Security quick facts

• Tools represent arbitrary code execution. Hosts must obtain explicit user consent before invoking any tool, and there SHOULD always be a human in the loop who can deny an invocation.
• Authorization is optional. HTTP transports SHOULD follow the spec's OAuth 2.1-based authorization; stdio servers SHOULD NOT and take credentials from the environment instead.
• A server that calls upstream APIs must not pass through the token it received from the MCP client, and must not accept tokens that were not issued for it.
• Organizations control servers with managed-mcp.json (exclusive control) or allowedMcpServers and deniedMcpServers. A denylist match always wins, and a serverName entry is not a security control: use serverCommand or serverUrl.
• Servers that fetch external content can expose you to prompt injection, so verify you trust each server before connecting it.
• CCAR-F excludes OAuth and authentication protocol details; CCDV-F covers identity, secrets and key management.

Choosing between MCP, a built-in tool, a custom tool or a Skill: see Tool rules and Built-in tools, custom tools, Skills or MCP.

Decision rules

All four exams use multiple-choice and scenario-based multiple-response items, and the scenarios turn on a small set of recurring judgments. The first table collects the reasoning patterns the official rationales use; after it, each rule is one table row: the rule, the wrong answers it rules out, and in the Basis column a pointer to the objective, sample question or anti-pattern in the official guides (CCAO-F, CCDV-F, CCAR-F, CCAR-P). Q numbers are CCAR-F sample questions; Sample numbers belong to the other three guides. All of them are reproduced with Anthropic's rationales on the exam pages (CCAO-F, CCDV-F, CCAR-F, CCAR-P). "Prep course" in the Basis column means a learning objective of the free Claude Certified Architect - Professional Prep Course; which CCAR-P objective it sits beside is our mapping, not Anthropic's. The CCAO-F and CCAR-P guides list their objectives as unnumbered bullets; labels such as CCAO-F D3.4 and CCAR-P 3.7 are this site's numbering, counted in each guide's order. CCAR-F task statement numbers and CCDV-F skill names are the guides' own. Where current docs differ from a guide, a warning box here or in the cheat sheet a rule links to gives both sides; answer exam items in the guide's terms.

How the official rationales pick an answer

Enforcement rules

Go deeper: the refund-limit hook in the Agent SDK cheat sheet, policy blocks and result normalization in Hooks in the SDK, prerequisite gates in Permissions and enforcement, and Claude Code hooks in Hooks.

Tool rules

Go deeper: Writing tool descriptions that steer selection, Designing a tool set and Built-in tools, custom tools, Skills or MCP.

Context rules

Go deeper: Preserving critical information in long conversations, Subagents as context isolation and Sessions, resumption and forking.

Reliability rules

Agent loops and orchestration

The guide frames loop control as "tool_use" versus "end_turn"; the other stop reasons real code must handle, pause_turn included, are in Stop reasons. Answer with the guide's pair.

Errors and escalation

Review, validation and oversight

Synthesis and provenance

Go deeper: The agentic loop, Error propagation in multi-agent systems, Escalation and ambiguity, Human review and confidence calibration and Provenance and uncertainty in synthesis.

Prompt rules

Two notes on current docs. The prompting best-practices page recommends 3 to 5 examples for best results, while the guide's figure is 2 to 4 targeted examples for ambiguous cases; answer with the guide's figure. The CCAR-F guide appendix phrase "strict mode for syntax error elimination" (listed under JSON Schema) corresponds, in our reading, to what the API now calls strict: true; how structured outputs and strict tool use relate to the guide's tool-use framing is in the warning under tool_choice. Answer exam items with the guide's framing.

Go deeper: Explicit criteria and precision, Few-shot examples, Structured output with tools and JSON schemas and Validation, retry and feedback loops.

Claude Code layer rules

Where the September 2026 docs describe these layers differently from the guide (commands merged into skills, allowed-tools, argument-hint, /memory, when path-scoped rules load), both versions are in Exam guide vs current docs; MCP scopes are in the warning under MCP in Claude Code. Q4's answer still works, and exam items take the guide's terms.

Go deeper: The configuration layers at a glance, Path-scoped rules, Plan mode or direct execution and Claude Code in CI/CD.

Governance rules

Go deeper: Prompt injection, Least privilege for tools and agents and Data retention, training and compliance.

Cost and latency rules

Batches and tool calling: the guide's rule (no multi-turn tool calling inside one batch request) and what the docs now say about server tools in batches are both in the warning under Message Batches numbers.

Go deeper: Message Batches, Prompt caching and Models and how to choose one.

Glossary

Each term below appears in at least one of the four exam guides, unless its row says otherwise, and is defined briefly, with the objectives and official sample questions that use it. Where a guide's wording has drifted from current documentation, the row gives both; answer exam items in the guide's terms. CCAR-F numbers are the guide's own task statements; CCAO-F and CCAR-P numbers count the official bullets in order, as the exam pages do; CCDV-F is cited by skill name. Product details are as of September 2026.

A

B to C

D to F

G to L

M to O

P to R

S

T to W