Foundry: prepaid AI compute in USDF

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

Far exceeds the annotations (readOnly=false, openWorld=true, idempotent=false): it discloses the billing source (USDF balance, never free credit), the cost cap semantics (at most max_price, nothing on top), that a non-2xx unanswered call costs nothing or only what the seller kept, the 503 market_calls_unarmed gating, and the required Bearer auth. This is exactly the behavioral context a paid, open-world call needs.

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?

Front-loads the action and keeps nearly every clause load-bearing (cost, error, auth, return). The first sentence is long and clause-dense, verging on run-on, which slightly hurts scannability.

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?

With no output schema, the description still states the return value ('the seller's answer and the receipt') and covers auth, cost, and error paths. Limits handling ('within the key's and its agent's limits') is mentioned but its failure behavior is not spelled out, a minor gap for this complexity.

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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: input is forwarded to the seller whose own policy governs it, and id is explicitly tied to agents_market_search output. The max_price rationale (seller price changes) also deepens the required-parameter understanding.

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?

States a specific verb and resource ('Calls a listing of the agents market by its id') and pins the id's provenance to the agents_market_search sibling, so an agent can separate it from search/quote tools without opening a schema. The scope is unambiguous.

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?

It clearly signals the prerequisite (the svc_... id comes from agents_market_search) and why max_price is mandatory (a seller may change its price). It does not explicitly route to the quote/quote_tool siblings for pre-call pricing, so the when-to-use-vs-alternatives guidance is implied rather than stated.

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 and openWorldHint, so the safety profile is covered; the description adds genuine context: searches need no key, prices are quoted in USDF drawn from this key's balance, and results are sorted by popularity/price/newest. It omits pagination and rate-limit behavior, which keeps it at 4 rather than 5.

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 long opening clause front-loads the resource and its return shape, followed by two short sentences on ordering and the sibling alternative. The field enumeration is dense but earns its place since no output schema exists, though it is on the verbose side.

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?

With no output schema, the description usefully enumerates the fields each listing returns (id, name, tags, cost, I/O examples, data policy) and the sort/default and no-key behaviors. It is missing pagination guidance for limit/offset, which is the main gap for a 6-parameter search tool.

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 coverage is 67%, so the schema documents most parameters itself. The description restates the sort options and the id format but adds no meaning for q, tag, limit, offset or max_price beyond what the schema already provides, so the baseline 3 is warranted.

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 establishes the resource — a single market of agents, APIs and tools priced per call — and names the sibling (agents_market_call) that invokes one, so an agent can separate search from call. The verb 'search' is only implied from the name/title rather than stated, keeping it just short of a 5.

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?

It gives an explicit routing rule — 'No key needed to search; agents_market_call calls one' — which tells the agent when to search vs. invoke. It also notes the default ordering (popularity). It stops short of 5 because it never states when not to use search or how the other siblings (list_tools, list_models) differ.

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 and openWorldHint=false, so the safety profile is covered. The description goes beyond that by disclosing the required auth header format (Authorization: Bearer sk_...), the fact that the address mode is unauthenticated, and the x402/Permit2 payment context that gives the returned allowance meaning.

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, front-loaded with the default keyed behavior before the `address` alternative, with no redundant filler. It is dense — the parenthetical auth header interrupts the balance list — but every clause carries information.

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?

There is no output schema, so the description carries the return-value burden and does so by enumerating both modes' outputs (available balance, account balance, held amount, budget left, chain balances, allowance). For a single-optional-param read tool with annotations present, this is essentially complete.

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 coverage is already 100%, so the baseline is 3, but the description adds real meaning: the `address` parameter switches to a keyless mode and changes both the semantics and the returned fields (on-chain USDF/USDG, Permit2 allowance) rather than just trimming the response.

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 the specific resources returned: the calling key's available balance, the account balance and held amount, the key's budget remaining in USDF, plus a second mode returning a wallet's on-chain USDF/USDG and Permit2 allowance. That is precise enough to distinguish it from payment siblings like quote or x402_pay, though it never names a sibling explicitly.

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?

It gives a clear conditional for choosing the `address` mode over the keyed mode ('With `address` instead, no key'), which is useful mode-selection guidance. It does not explain when an agent should call balance at all versus siblings such as receipt, so overall usage guidance remains implied rather than explicit.

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 present, the bar is only that the description add behavior beyond them, and this one is exceptionally forthcoming: an up-front hold for maximum cost, non-streamed output, a 4096-token cap, the 55 s / 15 s / 10 min timing model, truncation to finish_reason 'length', refund and gas behavior, the 20 s deadline_too_close refusal, and that cancellation messages are unsupported and stopped-but-not-disconnected calls are still billed. The declared non-read-only, non-idempotent, open-world profile is consistent with this 'metered, spending, stateful' account.

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 first sentence is well front-loaded, but the body is a single dense paragraph mixing key-auth, x402, MPP, refunds and deadlines. It is not padded with fluff, yet the truncation-to-'length' rule is effectively restated for the x402 case, and the material would be far more usable as structured bullets. Size is defensible for the complexity but structure is poor.

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?

There is no output schema, so the description must cover returns, and it does: text plus a receipt with tokens, price, cost, balance and settlement, plus _meta x402/payment-response and org.paymentauth/receipt. For a tool involving metered payment, proofs and deadline-driven refunds, the failure modes an agent could hit are all covered.

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 100%, so a 3 is the baseline. The description exceeds it by explaining the payment parameter's mechanics beyond the schema text: sign one accept and resubmit via _meta["x402/payment"], the payment argument, or the PAYMENT-SIGNATURE header, and by tying max_tokens to the hold, the 4096 cap, and the output-price calculation.

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 opening sentence gives a specific verb and resource: 'Runs a chat completion through the metered gateway and returns the text with its receipt (tokens, price, cost, balance, settlement).' That is unambiguous and far better than a tautology. However, it never explicitly routes the agent relative to siblings like quote, receipt or x402_pay, so the differentiation is left implicit.

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 rich conditional usage: with a Bearer key it spends the key's balance, with no key it switches to the x402 flow, and it spells out the progress-token timeout semantics and the deadline/cancellation conditions. What is missing is guidance on when to call this tool versus the sibling quote/receipt/x402_pay tools, so context selection is implied rather than stated.

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 and openWorldHint=false, so safety is covered; the description still adds two useful facts beyond them: no API key is required, and the tool reports whether a route is available 'right now', implying live rather than cached state. It stops short of describing pagination or rate limits.

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?

A single dense sentence that front-loads the resource and then lists the fields returned; every clause carries information. The parenthetical price explanation is slightly heavy but earns its place.

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?

With no output schema, the description carries the burden of explaining return values, and it does so completely: pricing units, context window, output limits, and route availability. Nothing an agent needs to invoke or interpret the call is missing.

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 instead spends its words on return-field semantics (USD per 1M tokens vs USDF), which is appropriate for a parameterless call.

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 gives a specific resource ('models the gateway serves') and enumerates the returned fields (prices in USD/USDF, context window, output limits, route availability), so the agent knows exactly what it gets. It does not, however, distinguish itself from the sibling list_tools, which an agent could easily confuse with this one.

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?

No when-to-use or when-not-to-use guidance is offered, and no alternative such as list_tools or quote is named. The only usage-adjacent fact is 'No key needed', which clarifies auth requirements but not selection.

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 only declare readOnlyHint and a closed-world hint; the description adds materially more: no authentication required, the pricing model (USDF base units, cost plus at most 5%), the page size ceiling of 200, and the page.next cursor mechanism. That is exactly the auth, cost, and pagination context an agent cannot get from the 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?

It is a single dense sentence-cluster, but front-loads the important facts (endpoint, pricing, callability) before q and pagination. Every clause carries information, though the semicolon-chained phrasing is packed tightly enough to slow parsing slightly.

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?

With no output schema, the description must describe return values and it does: price, per-tool input schema, title ordering, and page.next for continuation. Auth, cost, and pagination are all covered, so nothing needed to call it correctly is missing.

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 100%, so q and cursor are already documented, establishing a baseline of 3. The description only marginally extends this by tying cursor to 'page.next' and clarifying that q matches id, title, or description; it adds no format or edge-case detail beyond the schema.

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 ('Tools callable through POST /v1/tools/{id}') and elaborates the returned payload: price in USDF base units, each tool's input schema, and ordering by title. An agent can distinguish this catalogue lister from siblings like list_models, agents_market_search, or quote_tool without opening any schema.

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?

It gives real invocation context ('No key needed', 'every tool listed can be called now') and explains what q narrows, but never states when to choose this over agents_market_search or quote_tool, nor any exclusion. Usage is implied by the 'callable now' framing rather than stated as guidance.

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 only say readOnlyHint=true/openWorldHint=false, yet the description adds substantial context: it is an estimate and not a billing ceiling, actual billing follows provider-reported usage and is normally less, no key is required, and attested/private routing is quoted at the model's price on verified routes. This is exactly the kind of cost/auth behavior an agent needs beyond the structured hints.

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 dense sentences with no filler; the pricing semantics are front-loaded. Slight deductions for the roundabout opening noun phrase and the repeated 'at the model's price' clause, which make it less scannable than it could be.

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?

With no output schema, the description still conveys the return's essence (dual USDF/USD figures, 4096-token cap) and the pricing model. However, it does not describe the shape of the returned quote or how the two currencies relate, leaving a modest gap for a tool whose whole job is producing a structured price estimate.

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 100% schema coverage the baseline is 3, but the description adds real meaning: 'Pass prompt or messages' clarifies the two mutually optional input paths, and the 'output capped at 4096 tokens' note relates to the token budget. The 4096 cap sits somewhat awkwardly next to the schema's max_tokens default/cap wording, creating mild ambiguity about which budget is meant.

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 defines the tool as 'the hold the chat tool places before running a request' and clarifies 'It is an estimate, not a ceiling', so an agent can infer this returns a pre-flight cost quote in USDF/USD for a chat request. It is distinguishable from siblings like chat, balance and receipt, though the purpose is expressed through a metaphor rather than a direct verb+resource statement.

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?

It states when this applies (before running a request, mirroring the chat flow) and gives input guidance ('Pass prompt or messages', 'No key needed'). It also names the conditions under which special routing pricing applies (attested hardware via ':private' or provider.private, Private-tier keys), but it never explicitly contrasts with an alternative tool or states when not to use it.

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 and openWorldHint=false, so safety is covered; the description adds genuinely new context by stating it performs no side effects ('runs nothing and holds nothing'), that the returned amount is a worst-case hold, and that 'No key needed' (no auth required). That is more than the annotations provide.

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 short sentences with no filler; the output content comes first and the no-side-effects/auth notes follow. The opening clause is syntactically tangled, but the piece is appropriately sized and 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?

With no output schema, the description steps in to describe what is returned (worst-case hold in USDF base units and USD, plus the tool's price), and it resolves the auth and side-effect questions. It does not say what happens when the input fails validation, but nothing else an agent needs to call it is missing.

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 100% with only two parameters, so the schema already documents 'tool' (id from list_tools) and 'input'. The description adds only that the input is checked as the call would be, which is marginal beyond the schema, so baseline 3 applies.

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 makes clear this returns the hold/price a tool call would incur for a given input, in USDF base units and USD, with the tool's price. The garbled first sentence ('The hold a call to a tool takes for this input') is awkward to parse, but the resource and effect are unambiguous and it distinguishes itself from siblings that actually execute (agents_market_call, x402_pay) and from 'receipt'/'balance'.

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?

It implies pre-flight usage by noting it 'checks the input as the call would; runs nothing and holds nothing', which tells the agent to quote before executing. However it never explicitly names an alternative (e.g., use this before agents_market_call) or states when not to use it.

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 and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the auth requirement (Authorization: Bearer sk_...), the two authorization modes, and the settlement-dependent nature of the response (transaction and rows appear once the batch is settled).

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?

Sized reasonably for the information it carries, but it is structured as one long run-on sentence with two parallel colon-lists, making it hard to parse. The keyed-vs-public distinction is buried rather than 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?

With no output schema present, the description usefully compensates by enumerating what the response contains (usage line, payment, settlement, proof URL) and covers both authenticated and public access. It is nearly complete for a one-parameter read tool, lacking only explicit routing to sibling tools.

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 100% and the single required parameter is already documented in the schema, so the baseline is 3. The description adds marginal meaning by tying the id to the endpoint template GET /x402/v1/receipts/{id} ('any request id'), but provides no extra format or sourcing detail.

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 the specific resource (a request's receipt) and enumerates its contents (usage, price sheet version, cost, settlement, transaction, onchain digest), and it distinguishes two modes: keyed vs public receipt. It is clearly more than a restatement of the name, though it never uses a plain verb and leans on heavy jargon.

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?

It implies usage conditions - provide the calling key for your own request's receipt, or omit it to fetch the public receipt of any request id including x402 ones. That conditional is useful, but there is no explicit when-to-use-this-vs-alternatives guidance referencing siblings such as x402_pay or quote.

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?

Goes well beyond the annotations: it discloses the funding mechanism (gateway's USDC float on Base or Solana), the billing model (USDF cost plus at most 5%, no minimum, within key/agent limits), the auth requirement (Bearer sk_...), and the settlement risk model (charged only once the chain shows it; an unsettled payment is free). The readOnlyHint=false annotation is consistent with this spend operation.

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?

Front-loads the core action, then layers in payment, auth, and settlement details. It is information-dense and slightly rambling in its parenthetical asides, but nearly every clause carries distinct behavioral value.

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?

Despite having no output schema, it describes the return value (the seller's answer with the payment and its receipt), covers auth, fee exposure, network selection, and cancellation semantics. Nothing an agent needs to call this financial operation safely is missing.

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 100% schema description coverage, the schema already documents all seven parameters, including quote and max_price. The description corroborates the fee ceiling and network options but adds little parameter meaning beyond what the schema states, so the baseline of 3 applies.

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?

States a specific verb and resource (calls a URL demanding an x402 payment and pays it), naming the capital source, networks, and billing currency. It is clearly separable from siblings like quote, quote_tool, and receipt, and even notes the intra-call escape hatch (quote: true pays nothing).

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?

Gives clear context for when to invoke it (a URL that asks for an x402 payment) and points at list_tools (?source=marketplace) to discover suitable third-party endpoints, plus the quote: true mode for price checks without paying. It stops short of explicitly saying when NOT to use it versus the standalone quote/quote_tool siblings.

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