Effective Tool Interface Design with Clear Descriptions and Boundaries

The Tool Interface Design topic is the single most exploited Domain 2 surface on the Claude Certified Architect — Foundations (CCA-F) exam. Task statement 2.1 — "Design effective tool interfaces with clear descriptions and boundaries" — sits at 18% domain weight and carries a heat score of 0.73 because the entire Customer Support Resolution Agent scenario hinges on whether the architect understands that Tool Interface Design is not a schema-writing exercise but a routing exercise. The canonical sample question pits analyze_content against analyze_document with skeletal descriptions and asks the candidate to fix the mis-routing; the wrong answers cluster around "add few-shot examples" or "consolidate the two tools," and the right answer is always "expand the descriptions to include clear boundaries." If you misread Tool Interface Design, you misread half of Domain 2 and a material slice of Domain 1.

This study note walks through the full Tool Interface Design surface a CCA-F candidate is expected to command: how the tool schema (name, description, input_schema) decomposes into selection signals, why the description field is the primary mechanism LLMs use for tool selection, what "purpose-specific" means and why splitting generic tools into purpose-specific tools with defined input/output contracts beats consolidation, how renaming tools (the analyze_content → extract_web_results pattern) eliminates overlap, when system-prompt keyword sensitivity can override tool descriptions, and the exact exam traps that distinguish the 893/1000 pass reports from the 650/1000 fails. Every section is anchored to the Customer Support scenario because that is where minimal descriptions cause the most dramatic Tool Interface Design failures on exam day.

Why Tool Interface Design Matters — Descriptions Drive Selection

Claude does not see your tools the way you see them in your IDE. It sees a flat list of JSON objects — each with a name, a description, and an input_schema — inserted into the system context at the start of every turn. When Claude's agentic loop produces stop_reason: "tool_use", the selection of which tool to call is made almost entirely by pattern-matching the user's intent against the description text of each registered tool. Tool Interface Design is therefore the discipline of writing descriptions that steer Claude toward the correct tool unambiguously, even under scenario ambiguity or prompt drift.

The CCA-F exam guide explicitly names "tool descriptions as routing mechanisms" as a foundational competency, and community pass reports (Kishor Kukreja, 893/1000; Rick Hightower, 985/1000) consistently cite description quality as the single highest-leverage lever on Domain 2 questions. If two tools have overlapping descriptions, Claude guesses. If one tool's description is vaguer than another's, Claude routes to the more specific one even when that is wrong. Tool Interface Design is not cosmetic — it is the steering wheel.

The Three-Field Tool Schema

Every Claude tool definition, whether direct API or MCP-hosted, decomposes into three fields that carry selection weight:

1. name — a short identifier (snake_case). Used for tool invocation and logging. Contributes weakly to selection when the description is thin.
2. description — a natural-language string of roughly 100–500 tokens. The dominant selection signal. Must contain purpose, inputs, outputs, examples, and boundaries.
3. input_schema — JSON Schema describing required and optional parameters. Constrains how the tool is called, not whether it is chosen.

The CCA-F exam tests whether candidates understand the asymmetric weight of these three fields. A well-written description can compensate for a weak name; a perfect input_schema cannot compensate for a weak description.

Why "Clear Boundaries" Appears in the Task Statement

Domain 2.1 is worded "Design effective tool interfaces with clear descriptions and boundaries" — two nouns, not one. Descriptions tell Claude what a tool does; boundaries tell Claude what a tool does not do. A Customer Support tool named analyze_content that says "analyzes content" has a description but no boundary. Adding "Use this tool ONLY for web-search results returned from search_web. Do NOT use for customer-uploaded documents — use analyze_document instead." introduces a boundary and eliminates the mis-routing that plagues the sample question.

The Customer Support Scenario — Where Minimal Descriptions Fail

The Customer Support Resolution Agent is one of the six CCA-F exam scenarios, and it is the canonical stage where Tool Interface Design failures are exposed. The scenario typically presents an agent wired with several tools:

• search_knowledge_base — retrieve internal policy and FAQ articles.
• search_web — search the public web for external information.
• analyze_content — described minimally as "analyzes content."
• analyze_document — described minimally as "analyzes a document."
• create_ticket — escalate to a human agent.

When the customer asks "Can you check what the recent Anthropic usage policy changes are?", Claude calls search_web correctly, receives web results, and then must choose between analyze_content and analyze_document to extract the answer. Because both tools have one-line descriptions, Claude guesses. On half the attempts, it picks analyze_document even though the input is a web result, not a document — and the tool either fails silently or returns malformed output because the input schema mismatch was not caught upstream.

The Minimal-Description Failure Mode

A minimal description looks like this:

{
  "name": "analyze_content",
  "description": "Analyzes content.",
  "input_schema": { ... }
}

Claude sees this as "a tool that does something with content." When a sibling tool analyze_document has a similarly minimal description, Claude has no principled way to distinguish them. Selection becomes a coin flip weighted by whichever name best matches surface keywords in the user's latest message — "document" in the user's prompt nudges toward analyze_document even when the actual data flowing in is a web-search result.

The Expanded-Description Fix

The expanded version encodes purpose, inputs, outputs, examples, and explicit boundaries:

{
  "name": "extract_web_results",
  "description": "Extracts structured information from web search results returned by search_web. Accepts an array of SearchResult objects (title, url, snippet). Returns a summary paragraph plus a list of cited URLs. Use this tool whenever you need to synthesize information from the public web. Do NOT use this tool for customer-uploaded documents — use analyze_document for that purpose.",
  "input_schema": { ... }
}

Two improvements compound. First, the name was changed from analyze_content to extract_web_results to eliminate keyword overlap with analyze_document. Second, the description now encodes what the tool consumes, what it produces, when to use it, and — most importantly — when NOT to use it.

Tool Descriptions as the Primary Selection Mechanism

Four Signals, One Dominant

When Claude selects a tool, four signals compete:

1. Description text (dominant) — the richest natural-language description of purpose and scope.
2. Tool name (secondary) — weak keyword signal; helps when descriptions are similar.
3. Input schema (tertiary) — eliminates tools whose required parameters cannot be populated from context.
4. System prompt hints (conditional) — can bias selection but does not override a clearly-boundaried description.

The CCA-F exam tests whether candidates understand the ranking. Candidates who believe "add more system prompt instructions" is the answer to mis-routing fail the Customer Support scenario. Candidates who rewrite descriptions pass.

The Description Quality Rubric

A production-grade tool description satisfies all six criteria:

• Purpose statement — one sentence on what the tool does.
• Input contract — what data the tool expects, by type and origin.
• Output contract — what the tool returns, by shape.
• Positive examples — 1–2 example invocations ("Use when the user asks X").
• Negative boundaries — explicit "do NOT use when Y; use Z instead."
• Edge-case notes — error conditions, rate limits, prerequisite state.

Descriptions that omit boundaries are the most common failure mode. Descriptions that try to substitute a single example for a boundary are the second most common.

Purpose-Specific Tools vs Generic Tools

The Split-vs-Consolidate Decision

Intuitively, fewer tools might seem better — less cognitive load, simpler agent configuration. The CCA-F exam punishes this intuition. When two tools overlap in purpose, the correct architectural move is to split them into purpose-specific tools with narrower, non-overlapping descriptions, not to consolidate them into one generic tool with a union of behaviors.

Why? A consolidated tool named analyze with a description saying "analyzes web results, documents, images, and emails" forces Claude to infer the input type from context and then branch internally. Claude cannot reliably do this because the branching happens after tool selection and inside the tool implementation — Claude's selection mechanism only operates at the boundary between tools, not inside them.

The Rename-to-Disambiguate Pattern

A companion pattern to splitting is renaming tools to eliminate keyword overlap. The canonical example from the CCA-F sample question:

• Before: analyze_content + analyze_document (both start with analyze_, both claim to "analyze")
• After: extract_web_results + parse_customer_document (no shared prefix, no shared verb)

The rename operation is not cosmetic — it removes the coincidental token overlap that nudged Claude toward the wrong tool when descriptions were thin. Combined with expanded descriptions, the rename+describe pattern is the canonical CCA-F answer to mis-routing scenarios.

Input and Output Contracts

Input Schema as Constraint

input_schema is JSON Schema. Its job is to tell Claude which parameters are required, which are optional, their types, enum constraints, and value ranges. A well-designed input schema has:

• Only the fields the tool actually needs (no kitchen-sink parameters).
• Meaningful required-vs-optional distinction.
• Enum values where there is a closed set (e.g., priority: "low" | "medium" | "high").
• Descriptions on nested fields, not just the top-level object.

A tight input schema acts as a secondary selection signal: if a tool requires a search_query_id parameter and the current context has no such ID, Claude will deprioritize that tool even if the description seems to match.

Output Shape as Handoff Contract

Equally important is the output shape. A tool that returns { "result": "..." } vs one that returns { "summary": "...", "citations": [...], "confidence": 0.87 } creates very different downstream possibilities. The second form enables the coordinator agent to make structured decisions ("if confidence < 0.7, call create_ticket") while the first forces the coordinator to re-parse unstructured text.

For MCP tools specifically, the response envelope also carries isError, errorCategory, and isRetryable fields — covered in the companion topic Structured Error Responses for MCP Tools — which are part of the output contract even though they sit outside the user-facing content.

Boundary Definition — What the Tool Does NOT Do

The Three Boundary Clauses

A production-grade boundary clause has three parts:

1. Positive scope — "Use this tool when [condition X holds]."
2. Negative scope — "Do NOT use this tool when [condition Y holds]."
3. Redirect — "Use [other tool name] instead for [condition Y]."

Example applied to the Customer Support scenario:

Use extract_web_results when processing output from search_web. Do NOT use this tool for customer-uploaded files — use parse_customer_document instead.

This single sentence eliminates the mis-routing failure mode in the minimal-description version.

Boundaries Across Tool Families

Boundaries should be written pairwise between tools that could plausibly be confused. You do not need a boundary clause between create_ticket and extract_web_results because no reasonable user intent would route to both. But you absolutely need one between analyze_document and extract_web_results because both consume text and both produce summaries.

System Prompt Keyword Sensitivity and Tool Descriptions

When System Prompts Bias Selection

If the system prompt says "you are a document analysis agent" and a user asks a general question, Claude is biased toward tools whose descriptions mention "document" — even when the actual user intent is a web search. This keyword sensitivity is why system prompts must be written carefully when tool descriptions are thin.

But the fix is not to remove keywords from the system prompt — the fix is to strengthen the tool descriptions so the boundary between tools is robust against system-prompt-induced bias.

The Description-First Rule

On CCA-F exam scenarios, the correct diagnostic order is:

1. First, examine the tool descriptions. Are they minimal? Do they overlap? Are boundaries stated?
2. Only if descriptions are already production-grade, examine the system prompt for keyword bias.
3. Only if both are correct, consider tool_choice overrides.

Candidates who reverse this order — blaming the system prompt first — consistently pick the wrong answer on mis-routing questions.

Plain-Language Explanation: Tool Interface Design

Abstract schema discussions click into place when anchored to physical analogies. Three different analogies cover the full span of Tool Interface Design for CCA-F.

Analogy 1: The Toolbox with Labeled Compartments

Imagine a carpenter's toolbox. The tools inside — hammer, screwdriver, wrench, chisel — are useful only when the carpenter can pick the right one quickly under pressure. If every compartment is labeled simply "tool," the carpenter wastes time opening each one. If the labels say "hammer for nails, NOT for screws — use the screwdriver for screws," the carpenter picks correctly every time, even in dim light.

A Claude tool registry works the same way. The description field is the label on the compartment. A minimal description ("analyzes content") is a compartment labeled "tool" — useless. A bounded description ("extracts structured data from web-search results; do NOT use for customer-uploaded files — use parse_customer_document for those") is a compartment labeled "hammer for nails, NOT for screws" — unambiguous.

This analogy maps every Tool Interface Design concept:

• A tool name is the short sticker on the front of the compartment.
• A tool description is the full label underneath.
• A tool boundary is the "do NOT use for..." addendum on the label.
• A purpose-specific tool is a single-purpose compartment (one per compartment, not "all fasteners").
• The input/output contract is the matching shape of the compartment — you cannot fit a wrench in a screwdriver compartment.

Analogy 2: The Hospital Triage Desk

A hospital emergency room has multiple specialists — cardiology, orthopedics, neurology, pediatrics. The triage nurse at the front desk routes each incoming patient to the right specialist. If the nurse's routing directory says "Dr. Smith sees patients" and "Dr. Jones sees patients" (minimal descriptions), the nurse guesses and patients get misrouted. If the directory says "Dr. Smith sees chest pain, shortness of breath, and cardiovascular emergencies; NOT pediatric or orthopedic cases — those go to Dr. Jones or Dr. Lee," the nurse routes correctly.

Claude is the triage nurse. Each tool is a specialist. The tool descriptions are the routing directory. Without explicit boundaries in the directory, the nurse (Claude) cannot route reliably. With boundaries — "Use this specialist when X; NOT when Y; for Y use specialist Z" — routing becomes deterministic even for borderline cases.

This analogy is especially useful for understanding why consolidation is wrong. Merging cardiology and orthopedics into a single "general specialist" does not help the triage nurse — it forces the specialist to re-triage internally, which is exactly what an agentic system cannot do reliably.

Analogy 3: The Library Reference Desk with Specialized Librarians

A large academic library has multiple reference librarians, each with a subject specialty — sciences, humanities, rare books, digital archives. A patron walks up with a question. The desk has a printed card for each librarian that says what they handle.

If the cards say only "reference librarian" (minimal descriptions), the patron (or a junior clerk routing the patron) has to guess. If the cards say "Rare Books Librarian — handles pre-1900 printed materials and manuscripts; does NOT handle digital-only sources — ask the Digital Archivist instead," the routing is unambiguous.

Notice what the expanded card does: it gives the positive scope ("pre-1900 printed"), the negative scope ("NOT digital-only"), and the redirect ("ask the Digital Archivist"). That is exactly the three-part boundary clause pattern for Claude tool descriptions.

Which Analogy to Use on Exam Day

• Questions about tool description quality and boundaries → toolbox analogy.
• Questions about routing ambiguity and mis-selection → hospital triage analogy.
• Questions about purpose-specific vs generic tools and the rename-to-disambiguate pattern → library reference desk analogy.

The Description-vs-Few-Shot Trap — Description Wins

This is the single most-tested CCA-F Domain 2 trap, and it warrants its own section.

A scenario presents mis-routing between two tools. Four answer choices:

• (A) Add 3–5 few-shot examples to the system prompt showing the correct tool choice for representative user queries.
• (B) Expand the tool descriptions to include positive scope, negative scope, and redirect clauses.
• (C) Combine the two tools into one generic tool with internal branching.
• (D) Train a smaller classifier to route requests before Claude sees them.

The correct answer is (B). Why?

• Few-shot examples in the system prompt (A) are local and fragile. They work on the example cases but degrade on novel phrasings. They also inflate token usage on every turn.
• Expanded descriptions (B) are global — they apply to every turn, every phrasing, every novel case. They are also the intended mechanism per Anthropic's official tool-use documentation.
• Consolidation (C) worsens the problem by forcing Claude to infer the input type inside the tool instead of at the selection boundary.
• External classifiers (D) add a new point of failure and sidestep the agentic architecture entirely.

Tool Granularity — Composable Fine-Grained vs Monolithic Multi-Function

A related architectural decision is tool granularity. Given a family of related capabilities, do you expose one big tool with a mode parameter, or several small tools each doing one thing?

The Monolithic Approach

One tool, many modes:

{
  "name": "analyze",
  "description": "Analyzes content. Pass mode: 'web' for web results, 'document' for documents, 'email' for emails.",
  "input_schema": {
    "type": "object",
    "properties": {
      "mode": { "enum": ["web", "document", "email"] },
      "content": { "type": "string" }
    }
  }
}

The Composable Approach

Several tools, one per purpose:

[
  { "name": "extract_web_results", "description": "..." },
  { "name": "parse_customer_document", "description": "..." },
  { "name": "summarize_email_thread", "description": "..." }
]

Which One Wins on CCA-F?

The composable approach wins for most CCA-F scenarios, especially Customer Support. Reasons:

• Purpose-specific tools have tighter boundaries and clearer descriptions.
• Input/output contracts are per-tool, not union-shaped across modes.
• Selection happens at the tool boundary (Claude's strong suit), not inside the tool (the agent's weak suit).

The monolithic approach is only correct when the modes share genuinely identical input/output contracts and differ only in a trivial configuration flag — which is rare in practice.

Description Anti-Patterns

The CCA-F exam guide and the Anthropic engineering blog converge on a short list of description anti-patterns:

• Vague verbs — "analyzes," "processes," "handles." Replace with specific verbs: "extracts citations from," "parses PDF headers of," "summarizes thread replies."
• Missing scope — "Analyzes content" without saying what kind of content. Add input type and source.
• Absent preconditions — Tools that require prior state (e.g., search_web must have been called first) but do not say so in the description.
• No negative boundaries — Descriptions that say only what the tool does, never what it does not do.
• Overloaded descriptions — Single descriptions trying to cover three tasks; split into three tools.
• Copy-pasted descriptions — Two tools with nearly-identical descriptions differing only in a single noun.

Every anti-pattern on this list corresponds to at least one documented failure mode in the Customer Support scenario.

Testing Tool Descriptions Before Production

Production-grade Tool Interface Design includes a description-testing step. Approaches:

• Selection evals — curated user queries paired with the expected tool name, run through Claude with the registered tools, measuring selection accuracy.
• Boundary probes — borderline queries designed to sit between two tools, to measure whether boundary clauses are strong enough.
• Ablation testing — temporarily remove one tool's description fields (start with boundaries) and observe the accuracy drop; tells you which description elements carry the most weight.

CCA-F does not require candidates to implement these evals, but it does reward candidates who recognize that description quality is evaluable, not just aesthetic.

Common Exam Traps — Tool Interface Design

The CCA-F exam aggressively exploits six recurring trap patterns tied to Tool Interface Design. Drill each one until recognition is reflexive.

Trap 1: Few-Shot Examples Instead of Description Expansion

Covered in detail above. When a mis-routing scenario appears, the trap answer says "add examples to the system prompt." The right answer says "expand the descriptions."

Trap 2: Consolidation Instead of Splitting

Answer choices that say "combine the two tools into one with a mode parameter" are almost always wrong. Splitting is the CCA-F default.

Trap 3: Forcing tool_choice to Override Selection

Answer choices that say "use tool_choice: forced to bypass Claude's selection judgment" are wrong unless the scenario specifically requires deterministic structured output. Forcing bypasses the selection mechanism and is an admission that the descriptions are broken.

Trap 4: Adding More Tools Instead of Better Descriptions

The trap: "add a router tool that picks the right tool and then calls it." This adds indirection without fixing the underlying description problem. The right answer is still to fix the descriptions on the existing tools.

Trap 5: Renaming Without Expanding

A subtle trap: answer choice says "rename analyze_content to extract_web_results" but does not also expand the description. Renaming alone is insufficient — the description still carries the routing signal. The correct answer combines rename + expand.

Trap 6: Treating Description as System Prompt Surface

Answer choices that say "move the tool description content into the system prompt" are wrong. Descriptions are per-tool metadata that Claude sees at selection time; system prompts are session-level instructions that bias but do not replace descriptions.

Practice Anchors — Task 2.1 Scenario Questions

CCA-F practice questions tied to Tool Interface Design cluster around the Customer Support Resolution Agent scenario and, to a lesser extent, the Developer Productivity scenario.

Anchor A: The analyze_content vs analyze_document Mis-Routing

A customer support agent is configured with search_web, search_knowledge_base, analyze_content, and analyze_document. Users report that when they ask about recent external information, the agent sometimes fails with tool errors. Investigation shows Claude occasionally calls analyze_document on web-search results. What is the best fix?

• (A) Add few-shot examples to the system prompt mapping user queries to tools.
• (B) Rename analyze_content to extract_web_results and expand both descriptions to include explicit scope, examples, and "do NOT use when..." redirect clauses.
• (C) Consolidate analyze_content and analyze_document into a single tool with a mode parameter.
• (D) Force tool_choice to analyze_content whenever search_web has been called.

Correct answer: (B). The rename eliminates keyword overlap; the expanded descriptions provide the routing signal; the boundary clauses eliminate mis-routing on borderline cases.

Anchor B: Minimal Descriptions on a Developer Productivity Agent

A code-assistant agent has tools read_file, write_file, search_code, analyze_code. Users report that search_code and analyze_code are selected interchangeably when they ask about "find all the places that handle authentication." What is the root cause?

Correct answer: both descriptions lack boundary clauses that distinguish "finding matches" (search_code) from "reasoning about code semantics" (analyze_code). The fix is to add scope + negative scope + redirect clauses to both descriptions.

Anchor C: Consolidation Scenario

A team proposes replacing four purpose-specific tools (search_kb, search_web, extract_web_results, parse_customer_document) with a single ask_anything tool that takes a source_type parameter. What is the exam-correct critique?

Correct answer: consolidation removes the per-tool input/output contracts and the per-tool description boundaries, forcing Claude to branch inside the tool rather than selecting at the tool boundary. The original purpose-specific design is architecturally sound; the consolidation regresses it.

Anchor D: System Prompt vs Description Priority

A team has a mis-routing bug. They propose either (i) expanding tool descriptions or (ii) tuning the system prompt with keyword hints. Which should they do first, and why?

Correct answer: expand tool descriptions first. Descriptions are the primary selection signal; system prompts are secondary. Tuning the system prompt without fixing descriptions produces fragile routing that breaks on novel user phrasings.

Anchor E: Boundary Clause Construction

Given two tools with overlapping purpose, write the boundary clause for the first tool. Expected pattern:

"Use <tool_a> when [positive scope condition]. Do NOT use <tool_a> when [negative scope condition] — use <tool_b> instead."

Candidates who produce this three-part pattern consistently score correctly on CCA-F Task 2.1 questions.

Tool Interface Design Frequently Asked Questions

What is the most important field in a Claude tool definition for CCA-F?

The description field. It is the primary selection signal Claude uses when choosing among registered tools. The name contributes weakly; the input_schema constrains how the tool is called but not whether it is chosen. CCA-F explicitly tests the asymmetric weight of these three fields — candidates who over-invest in input_schema design while leaving descriptions minimal consistently mis-answer Domain 2 questions.

When two tools mis-route, should I add few-shot examples to the system prompt or expand the tool descriptions?

Expand the tool descriptions. This is the single highest-frequency CCA-F Domain 2 trap. Few-shot examples in the system prompt are fragile (they fail on novel phrasings), token-expensive (they cost every turn), and they do not address the underlying selection mechanism. Tool descriptions are the selection mechanism. The correct fix is to rewrite both descriptions with positive scope, negative scope, and redirect clauses — and often to rename one tool to eliminate keyword overlap with its sibling.

What is a "purpose-specific tool" and why does CCA-F prefer it over a generic tool?

A purpose-specific tool is a tool whose interface — name, description, input contract, output contract — is tightly scoped to a single well-defined task (for example, extract_web_results only for search_web outputs). CCA-F prefers purpose-specific tools because their narrower boundaries make descriptions cleaner, selection more reliable, and mis-routing less frequent. Generic tools like analyze_content force Claude to infer the input type inside the tool rather than at the selection boundary, which is the wrong layer for that decision.

What is a tool boundary and how do I write one?

A tool boundary is the explicit "do NOT use when" clause in a description that tells Claude the scope limits of the tool and redirects to a sibling tool when scope is exceeded. Write boundaries in three parts: positive scope ("Use this tool when X"), negative scope ("Do NOT use this tool when Y"), and redirect ("Use tool_z instead for Y"). Apply boundary clauses pairwise between tools that could plausibly be confused. The three-part pattern is the CCA-F canonical answer for eliminating mis-routing.

Can a well-written system prompt fix mis-routing caused by weak tool descriptions?

No. A well-written system prompt can bias selection, but it cannot override weak descriptions reliably across novel phrasings. The CCA-F exam rewards the description-first diagnostic order: examine tool descriptions first, tune the system prompt second, consider tool_choice overrides last. Candidates who reverse this order consistently pick the wrong answer on mis-routing questions.

Should I consolidate two similar tools into one with a mode parameter, or split them into purpose-specific tools?

Split. The CCA-F default is to split generic tools into purpose-specific tools with tighter descriptions, non-overlapping boundaries, and per-tool input/output contracts. Consolidation forces Claude to branch inside the tool, which is the wrong layer — selection must happen at the tool boundary, where Claude is strong, not inside the tool, where the agent is weak. The only exception is when the "modes" share genuinely identical input/output contracts and differ only in a trivial flag.

Do tool names matter, or only descriptions?

Descriptions dominate, but names are not ignored. When two tools have similar descriptions, name keyword overlap (analyze_content vs analyze_document) can nudge Claude toward the wrong selection. The CCA-F canonical fix combines rename + expand: rename to eliminate keyword overlap (extract_web_results vs parse_customer_document), and expand descriptions to carry explicit boundary clauses. Renaming alone is insufficient; expanding alone is often sufficient; doing both is the most robust pattern.

Further Reading

• CCA-F Exam Guide (official PDF): https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Define tools — best practices for tool descriptions and tool_choice: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/implement-tool-use
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents
• Tool use with Claude — overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Handle tool calls — tool_result format and error responses: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Community pass report (Kishor Kukreja, 893/1000): https://medium.com/@kishorkukreja/i-passed-anthropics-claude-certified-architect-foundations-exam-with-a-score-of-893-1000-2206c27efd6c

Related ExamHub topics: Structured Error Responses for MCP Tools, Tool Distribution Across Agents and Tool Choice Configuration, MCP Server Integration into Claude Code and Agent Workflows, Built-in Tools Selection and Application.