AUX Transaction Preflight

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description adds useful behavioral context by stating it 'never accepts or processes bank data.' It also reveals that it reads current activation status and related terms, giving the agent confidence about side-effect-free discovery.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the first enumerates exactly what is read, and the second states the read-only/no-data-processing boundary. Everything earns its place and the key verb and scope are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter discovery tool, the description tells the agent what topics are covered and that it is side-effect-free. It does not describe the response shape, and there is no output schema to fill that gap, but the listed capability areas are specific enough for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters and 100% description coverage, so the no-parameter baseline applies. The description goes slightly beyond that by explicitly stating the tool never accepts bank data, making it clear that no input payload is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with the specific verb 'Read' and identifies the resource: activation status, evidence boundary, privacy rules, endpoints, sponsorship, and x402 terms for AUX signed bank-destination receipts. It also labels itself a 'read-only discovery tool,' which separates it from the evaluation/preflight siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the tool's domain clear (capability discovery for AUX bank-destination receipts) but never explicitly states when to choose it over sibling tools such as aux_evidence_evaluate or aux_transaction_preflight. Usage context is implied rather than stated, and no exclusions or alternatives are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description adds meaningful context beyond those: it never establishes legal ownership, never recommends SEND, and never signs, verifies, or transfers anything. These negative guarantees are valuable safety context for an agent deciding whether to rely on this tool for execution.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: the first states what the tool reads, the second adds a legal/ownership caveat, and the third reaffirms its non-execution behavior. Every sentence contributes distinct information, and the most important identifying information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only, idempotent discovery tool, the description is largely complete: it identifies the domain, the data categories, and the safety boundaries. It does not detail the output format, but it does mention schemas, endpoints, and price, and no output schema exists to carry that burden.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4. The description still adds domain context by listing what will be read (Base, Ethereum, Solana, schemas, endpoints, price), which helps an agent anticipate the scope of the result even though no parameter documentation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb, 'Read', and specifies the exact resources: the Base, Ethereum, and Solana wallet-control sequence, identity-context boundary, schemas, endpoints, and price. It is not a tautology of the name and clearly identifies the tool as a discovery capability, distinguishing it from execution-oriented tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly frames the tool as 'This discovery call', which tells the agent when to use it, and explicitly states what it never does: 'never signs, verifies, or transfers anything'. This provides useful exclusions, though it does not explicitly name sibling alternatives or define when a sibling should be chosen instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds meaningful behavioral details: it returns a 'deterministic decision plus revocable ES256-signed receipt' and notes the separation of source authority from cryptographic integrity. This goes beyond annotations and helps the agent understand outcomes, without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, free of filler, and front-loads the primary action. Every sentence adds value, including the limitation note. It is concise without sacrificing essential context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with seven parameters, nested objects, and no output schema, this description is thin. It does not describe the structure of 'claims' or 'attestations,' the expected decision output, or the receipt format. The limitation note is useful but the overall guidance is incomplete, especially for an agent attempting a correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not explain any of the seven parameters (claims, case_id, channel, subject, policy_id, attestations, data_classification) beyond the generic terms in the overview. This leaves the agent without the necessary parameter-level insight.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Evaluate synthetic third-party claims against signed attestation envelopes.' It uses a specific verb and resource, and the title reinforces the purpose. Sibling tools like mortgage preflight and FDIC verification are obviously different, so there is no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for synthetic or test scenarios by stating 'Real providers and private-ledger proof adapters are not yet active,' which tells the agent not to use it for real providers. However, it does not explicitly mention alternatives or provide when-to-use versus sibling tools, leaving some inference needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already declaring readOnly, openWorld, idempotent, and non-destructive, the description adds valuable context: it explicitly notes the tool never authorizes a wire, accepts only fictional data, and returns a signed receipt. This goes beyond the annotations and clarifies constraints, earning a strong score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action and then details about options and constraints. Every sentence contributes value, and there is no fluff or repetition. It is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema), the description covers all necessary aspects: what it evaluates, the optional flag, the return categories, and the safety constraints (no real data, no wire authorization). It is complete for an agent to understand the tool's behavior and scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains the purpose of both parameters: 'one published fictional mortgage closing scenario' corresponds to scenario_id, and 'Optionally add live public FDIC institution context' maps to include_live_fdic_context. It does not enumerate the scenario_id values, but those are self-explanatory in the enum, and the description compensates for the lack of schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool evaluates a fictional mortgage closing scenario for destination changes and cash-to-close evidence sufficiency, and it specifies the return values (MATCH, CHANGE_REVIEW, INSUFFICIENT_EVIDENCE). It does not explicitly differentiate from the sibling tool aux_transaction_preflight, but the specific mortgage closing context gives it clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description outlines what the tool does but gives no explicit guidance on when to use it versus the sibling tool aux_transaction_preflight. It does mention 'never authorizes a wire or accepts real customer or bank data', which is a constraint but not a usage recommendation. No when-to-use or when-not-to-use instructions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds valuable behavioral detail: it checks against 'current official' lists, returns explainable matches and provenance, and produces a signed receipt. This goes beyond the annotations and informs the agent about the nature and freshness of the data and the output structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action and outputs, then a crisp list of what to avoid. No fluff or repetition; every clause adds essential information. The structure is highly efficient for an agent scanning for key facts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the nested subject object and the checks array, the description provides enough context for correct invocation. It covers the domain, constraints, and outputs sufficiently. It omits exact output formatting details, but the rich annotations and clear purpose make this adequate. The absence of an output schema reduces the responsibility on the description for return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema coverage at 0%, the description must compensate. It explicitly defines the subject as a 'public business name' and prohibits other entity types, aligning with subject.name and subject.type. The mention of OFAC and GLEIF implicitly explains the checks array enums. However, it does not describe the optional country parameter or the exact format of the checks array, though those are minor gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Screen') and a resource ('public business name') against specific data sources (OFAC and GLEIF). It also enumerates the exact outputs (matches, timestamps, SHA-256 provenance, PROCEED/REVIEW/STOP decision, signed receipt) and explicitly lists what it is not (legal clearance, complete KYB, payment authorization, credit decision), clearly distinguishing it from broader evaluation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage boundaries by restricting input to 'public business name' and explicitly forbidding submission of people, accounts, borrower data, and similar private records. It also names exclusions ('Not legal clearance, complete KYB...') that guide an agent away from using this for those purposes. However, it does not explicitly reference sibling tools or provide conditional logic for when to choose an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description correctly adds value by describing behaviors beyond safety: AUX gathers evidence, asks questions, accepts confirmations/corrections, refreshes sources, and returns signed statuses. The disclosure that PROCEED_WITH_CONFIRMATION is 'reserved but disabled' is useful state information not captured in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loads the core purpose in the first sentence. It is somewhat jargon-heavy, especially 'authoritative action-profile adapters,' and the first sentence packs many behaviors into a long colon-separated list, but overall it is still relatively efficient and earns its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only discovery tool, the description covers the key operational facts: it exposes a live dialogue, mentions signed outcome states, and explains a reserved-but-disabled status. A remaining gap is that it does not describe the response structure or explicitly connect to the sibling start/continue tools, though the sibling list partially compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to clarify; the baseline of 4 applies. The description appropriately focuses on the tool's behavioral capabilities rather than parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific operation ('Discover the live machine-to-machine RWA evidence dialogue') and frames the tool as a capability-discovery endpoint rather than an execution step. However, it does not explicitly contrast with sibling tools like aux_rwa_action_preflight_start or aux_rwa_action_preflight_continue, so differentiation rests mostly on the verb 'Discover' and the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool should be called when an agent needs to inspect the current preflight dialogue state and permitted outcomes, noting that it 'currently returns signed STOP, REVIEW, or ABORTED.' It does not explicitly state when to use this tool instead of start, continue, or evidence_evaluate, leaving usage guidance to inference rather than direct instruction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds useful behavioral context beyond the annotations, particularly that a false answer is recorded immediately and produces STOP only when CONFIRM_TARGET is explicitly sent. This state-dependent behavior is not derivable from readOnlyHint, openWorldHint, idempotentHint, or destructiveHint alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core action, and the second sentence delivers an important behavioral consequence. The first sentence is a long list of options, but it remains efficient and within reasonable length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, nested objects, no output schema, and zero schema description coverage, the description is not complete enough. It communicates high-level dialogue actions but leaves required identifiers, token semantics, and the structure of evidence-related payloads unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only partially explains the response options (CONFIRM_TARGET, CORRECT, ABORT, PROVIDE_EVIDENCE). It does not explain the required preflight_id and confirmation_token, nor the nested objects corrections, confirmations, artifacts, or acknowledged_evidence_commitment.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action and resource: continuing a live RWA dialogue, and enumerates the possible actions within it. It is distinguishable from the sibling 'start' and 'capabilities' tools through the word 'continue' and 'live', though it does not explicitly name any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Continue a live RWA dialogue' provides clear context for when this tool applies: only when a dialogue already exists and is ongoing. It does not explicitly state exclusions or name alternatives, but the 'live dialogue' context effectively separates it from start/capabilities tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description adds a critical behavioral boundary: it never authorizes or executes an action. It also discloses that a side-effecting 'dialogue' starts and that a private confirmation token is created, which is useful given readOnlyHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with no filler; the operation, return value, and safety boundary are each given one focused sentence. The most important scoping information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (10 parameters, a nested policy, no output schema) but the description does not explain the purpose of most parameters, how the confirmation token should be used, or how this connects to the continuation tool. It provides only a high-level skeleton, which is not enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description must carry parameter meaning, but it only clarifies action and network. Seven required parameters such as idempotency_key, token_contract, receiving_wallet, amount_decimal, payment_asset, and the nested policy object are left to be inferred from names and patterns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Uses a specific verb ('Start') plus a clear resource ('live RWA evidence dialogue') and narrows the scope to Ethereum/Base BUY, TRANSFER, or ACCEPT actions. The closing safety statement and the 'Start' wording distinguish it from the preflight_capabilities and preflight_continue siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is the initiating step of a dialogue and that a token is produced for later use, but it never explicitly says to use preflight_capabilities first or preflight_continue after obtaining the token. No alternative tools or exclusion conditions are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context by specifying what verification checks (ES256 signature binding, expiry, stored status) and by clarifying the limits of what verification proves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly written sentences with no filler. The core verification scope is front-loaded, and the caveat about investment merit and authorization is a necessary, efficient addition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and minimal parameter documentation, so the description carries a heavy interpretive burden. It clearly states what is verified and what the result does not mean, but it leaves parameter construction and verification outcome semantics unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 0% description coverage, and the description does not explain the required formats or roles of `receipt` and `compact_jws`. The phrase 'ES256 signature binding' hints that `compact_jws` is the signed token, but no guidance is given for constructing the `receipt` object or relating it to the JWS.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: verify an AUX RWA receipt's exact ES256 signature binding, expiry, and current stored status. It also distinguishes the tool from evidence-evaluation or authorization tools by explicitly stating it proves integrity, not investment merit or authorization.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The calling context is implied: use this tool when an AUX RWA receipt's signature, expiry, or stored status needs verification. It explicitly says the result does not establish investment merit or authorization, but it does not name sibling tools or state when to prefer aux_evidence_evaluate or the preflight tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by explaining the tool returns an ES256-signed receipt and performs specific checks, supplementing the annotation-provided safety profile without contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The first sentence front-loads the core purpose and checks; the second delivers a critical safety caveat. Every clause carries informational weight, and the structure is highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only evaluation tool with rich annotations, the description covers purpose, specific checks, output decision, evidence, signed receipt, and safety constraints. The lack of parameter guidance hinders full completeness, but overall it provides enough context for correct selection and invocation understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides no explanation of the 'proposal' or 'transaction_history' parameters, and schema description coverage is 0%. While 'scenario' vaguely implies the inputs, the description does not clarify expected structure, required nested fields, or how the inputs map to the stated checks, leaving a significant gap that the schema alone cannot fill.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Evaluate a purpose-built synthetic B2B payment scenario' and enumerates specific checks (duplicate invoices, changed payment destinations, vendor-history anomalies, signed decision evidence). It clearly identifies the output as PROCEED/REVIEW/STOP with evidence and an ES256-signed receipt, making the tool's purpose unmistakable even without siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit context: 'Evaluation only' and a directive to never send real or confidential data, which defines when this tool should be used (synthetic scenarios) and sets clear constraints. No alternative tools are mentioned, but since there are no siblings, this level of guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.