Skip to lesson

AnthropicClaude Certified Architect – Foundations2026-102.1 Design effective tool interfaces with clear descriptions and boundaries

Remove keyword rules that misdirect tools

Completed by the knowledge check

Learning objective

Audit system prompts for keyword-sensitive instructions that cause unintended tool associations.

Core idea

A clear tool description can compete with a system prompt that supplies a different selection rule. “Whenever the user says analysis, use summarize_document” routes by a word, even when the request needs extracted web evidence rather than a document overview. This Bite uses the illustrative application tools extract_web_results and summarize_document, not Anthropic built-ins.

The CCAR-F exam guide explicitly identifies keyword-sensitive system instructions as a source of unintended tool associations. This is a prompt-design failure to investigate, not a documented keyword-matching algorithm inside Claude. Do not assume that every occurrence of a word deterministically selects a tool, or that a description always wins over supplied instructions. The tool-definition documentation does state that prompting influences which tool Claude picks under auto, so a misdirecting line has an effect worth auditing.

As an architect, audit the complete selection context. The Messages API constructs tool-use instructions from definitions, tool configuration, and your system prompt. Make those inputs express one coherent decision based on the requested outcome and available source. See 2.1.1 for writing descriptions and 2.1.2 for repairing overlapping interfaces.

How it works

Inspect the prompt that is actually supplied

For a Messages API integration, inspect the top-level system content sent with the request and the tools definitions available for that call. The relevant instruction is the one in the assembled request, not only a source template that the application might supplement.

The tool-definition documentation explains that definitions, configuration, and user-specified system instructions contribute to the constructed tool-use prompt. Review their agreement. If the system content says to send all analysis to a document tool while its description limits it to uploaded reports, the selection context contains competing guidance.

Look for exact tool names and their previous names. A rename from analyze_content to extract_web_results can improve the definition while leaving a system example that still teaches the former association. Check examples and output instructions as well as direct imperatives; a repeated example can imply a selection pattern without stating a rule.

This audit focuses on supplied selection guidance. Permission and business-policy enforcement have separate mechanisms; see 1.5.3. Rewording a system prompt can improve intended use, but it does not replace a deterministic pre-execution check.

Find the association and its counterexample

Identify instructions that map broad vocabulary to a specific tool. Terms such as “analyze,” “verify,” “document,” and “research” describe many possible requests. A lexical rule can collapse distinct tasks into one operation simply because they share wording.

Read system line by line and flag three shapes: a tool’s name, or a word from its description, used as an ordinary verb; a keyword rule of the form “when the user mentions X, use Y”; and an “always” rule that points at one tool whatever the request.

For the research assistant, “Use summarize_document for every request containing document” is suspect. “Find web evidence about the document’s growth forecast” needs retrieved evidence, not an overview of the uploaded report. Mentioning a document does not establish that its contents are the requested source.

Conversely, “Extract the reported growth figure from these web results” and “Analyze these web results to find the reported growth figure” can require the same extraction operation. A rule that changes the tool because the second phrasing contains “analyze” creates an unintended association.

Write down the selection criterion that the tool contract actually supports: source type, required input, and intended output. Compare that criterion with the rule in system. The defect becomes concrete when a request satisfies the contract for one tool but the prompt directs it toward another.

Replace the rule with outcome-based guidance

Keep the description’s responsibility in the tool definition. The system prompt can explain how the assistant combines responsibilities to satisfy a request. Avoid copying several slightly different versions of the same contract into different prompt sections.

Replace “Use the analyzer whenever analysis is requested” with one selection criterion per tool: use extract_web_results for evidence from retrieved web results and summarize_document for a narrative overview of an ingested report. The system prompt states the source and outcome criteria; it leaves argument formats and returned-record details to the tool descriptions.

Account for compound requests. A user can request a report overview and related web evidence in one sentence. An outcome-based instruction should allow the needed operations rather than declaring one exclusive route based on the first recognizable keyword. The tool descriptions still define the valid inputs and returned results for each operation.

Anthropic’s context-engineering guidance recommends instructions at an appropriate level of specificity, between brittle hardcoded logic and vague high-level goals. It also recommends distinct prompt sections and diverse representative examples rather than an exhaustive list of edge cases. Apply those principles to the audit: define meaningful outcomes, then use a few contrasts to demonstrate them.

Verify the change through calls and evidence

Hold the tool definitions and their implementations fixed while comparing the original and revised system guidance, so the prompt is the only variable. Use the evaluation method in 2.1.2; the checks here target unintended associations.

Pair paraphrases that preserve intent, such as requests to “extract” or “analyze” the same web figures. Contrast requests that share vocabulary but require different outcomes, such as summarizing a document and finding web evidence about that document. Include compound requests to check that one keyword does not suppress a required operation.

If removing a keyword rule repairs selection but leaves malformed arguments, return to the parameter contract. If the selected operation returns irrelevant evidence, inspect the implementation. Use the observed failure to identify the next repair rather than adding another lexical exception.

Key distinctions and trade-offs

Each flagged shape has a rewrite that states the outcome instead of the word:

Line in systemAssociation it createsRewrite around the outcome
“Summarize every source you find before answering.”“Summarize” repeats summarize_document, which can pull web results toward the document tool“Report the evidence each source gives; give an overview only when asked for one.”
“Whenever the user mentions a document, use summarize_document.”Fires on the noun, including web-evidence requests about a document“Use summarize_document when the user wants an overview of an ingested report.”
“Always start with summarize_document.”Points every request at one toolDelete it; the tool descriptions already state each selection condition

Mentioned subject versus required source: “Document” can identify the subject of a request. It does not decide whether the user needs its narrative overview or web evidence about it.

Prompt guidance versus deterministic routing: A system instruction guides model behavior. Application-controlled routing assigns the choice explicitly; see 1.1.3. Choose the control mechanism from the requirement.

Paraphrase versus changed task: Different words can express the same intent. The same word can occur in tasks requiring different results. Evaluate both relationships.

Specificity versus brittleness: Name meaningful selection conditions and exact tool identifiers. Avoid large lexical rule collections that create accidental associations or contradict the tool descriptions.

Architecture / decision scenario

A multi-agent research assistant has clearly described web extraction and document-summary tools. Its system prompt says “For any analysis request, use summarize_document first.” Users asking to analyze retrieved web results therefore receive document summaries or unnecessary attempts to obtain document identifiers.

The architect compares the assembled system content with the tool definitions and traces the wrong tool_use requests. The web extraction tool’s contract fits the requested source and outcome; the keyword-sensitive system instruction directs the assistant elsewhere.

They remove the broad association and add guidance based on the required result. Retrieved-web evidence goes to extract_web_results; narrative summaries of ingested reports go to summarize_document. Examples include two differently worded web-extraction requests and two document requests requiring different outcomes.

The evaluation holds tool definitions constant. It includes “analyze these web results,” “extract the figures from these web results,” and a compound request to summarize a report and compare its figures with retrieved evidence. Success requires the relevant tools and source-backed results, not avoidance of the word “analysis.”

If the compound task still loses web attribution, the team inspects result handling rather than adding another keyword instruction. If argument formation fails, they repair parameter descriptions or examples. The prompt repair has a bounded purpose: remove the competing association and restore the documented selection criteria.

Common exam traps

  • Reviewing descriptions while ignoring conflicting system instructions.
  • Assuming a source noun determines the required operation.
  • Replacing one broad keyword rule with a growing list of lexical exceptions.
  • Updating direct instructions while leaving contradictory examples or previous tool names.
  • Declaring success from plausible prose without inspecting calls and evidence.
  • Treating prompt guidance as a substitute for enforced execution policy.

What to remember

Audit the supplied system prompt, definitions, and examples together. Replace accidental word-to-tool associations with source, input, and outcome criteria. Test paraphrases and contrasting tasks, then inspect actual calls and evidence to verify the repair.

Knowledge check

References