US Economic, SEC EDGAR & On-Chain Data (x402)

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable methodological context: BLS publishes index levels, not rates; the tool computes YoY from NSA data and MoM from SA data. This explains behavior beyond the structured annotations 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 well-organized with clear sections ('When to use', 'When NOT to use', 'Args', 'Returns structuredContent'). Every sentence adds value, and the sample output makes the structure concrete without bloat.

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 lacking an output schema, the description provides a full structuredContent example with field names and sample values, covering asOf, periodName, headline, and core. It explains the data source and the computation method, making it complete for a simple read-only 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?

The tool has zero parameters, so the description appropriately states 'Args: none.' With no parameters to document, the baseline of 4 is met. The description could have added even more context about parameterlessness, but it's already explicit.

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 verb and resource: 'Latest U.S. CPI inflation from the Bureau of Labor Statistics, with the rates already computed.' It specifies exact outputs (headline and core CPI, YoY and MoM) and naturally distinguishes from siblings like macro_pce by mentioning what it does not cover.

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?

Explicitly includes 'When to use' (need current inflation rate, real-vs-nominal adjustment, CPI context) and 'When NOT to use' (PCE, regional/category-level detail, long historical series). Names the alternative (PCE) and clarifies the tool's scope relative to siblings.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description goes far beyond this by disclosing the 13F information table XML discovery, rollup of lots/share classes/put-call splits, the 'most recently filed' semantics, and the historical lag. It also explicitly notes that values are taken directly from the filing. This rich behavioral detail helps the agent understand exactly what happens under the hood.

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 moderately long but every block earns its place: purpose, technical complication (XML table), use cases, exclusions, args, and a full structuredContent example. It is well-organized with headers and front-loaded with the core purpose. No redundant or filler sentences.

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 compensates fully by providing a complete structuredContent example with field names, types, and sample values. It also covers prerequisites (ticker or CIK), constraints (limit range, historical data), and the source URL. For a tool of this complexity, the description is fully self-contained and leaves no critical gap.

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%: both 'ticker' and 'limit' are fully described in the schema, including default and range for limit. The description largely repeats this information (e.g., 'ticker (string, required): the FILER's ticker or its SEC CIK') without adding new meaning beyond the schema. Baseline 3 is appropriate since the schema carries the semantic burden adequately.

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 specific verb+resource: 'Institutional stock holdings for a fund manager, from its latest SEC Form 13F.' It clearly distinguishes this tool from siblings by explaining scope (latest 13F), what it returns (holdings with values, shares, lots), and explicit non-use cases (real-time, shorts, non-U.S. filers). This makes the tool's purpose unmistakable.

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 'When to use' (fund holdings, smart money tracking, portfolio research) and 'When NOT to use' (real-time, shorts, non-U.S. filers) with reasoning (45-day filing lag, no short disclosure). However, it does not name any alternative sibling tools, stopping short of the full 'alternatives' criterion for a 5.

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 declare readOnly/idempotent/destructive=false, and the description adds substantial behavioral detail: newest-first ordering, 8-K item code decoding to plain English, ability to filter by form types, and the structured response shape with a concrete example. No 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?

Well-structured with a clear summary, usage guidance, structured arg list, and return example. The length is justified by the amount of behavioral and parameter context included; no redundant sentences.

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 no output schema, the description includes a detailed return example showing the exact nested structure (cik, entity, filings array, items with code/label, documentUrl). Combined with sibling differentiation and parameter details, it provides all necessary context for an agent to select and invoke correctly.

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%, but the description enriches parameter understanding by adding usage examples ('AAPL' or bare CIK '320193'), clarifying that forms can be a list like ['8-K'], and stating the default and range for limit. This goes beyond the schema descriptions.

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?

Description opens with 'Recent SEC filings for a company, newest first, with 8-K item codes translated to plain English' – a specific verb+resource+scope. It explicitly distinguishes from siblings by listing form types and pointing to edgar_financials and edgar_insider_transactions as alternatives.

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?

Contains explicit 'When to use' and 'When NOT to use' sections, naming alternative tools (edgar_financials for parsed financial content, edgar_insider_transactions for insider trades). This provides clear context for when this tool is appropriate versus alternatives.

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 establish read-only and idempotent behavior. The description goes further, explaining tag-fallback logic for ASC 606, classification by actual duration rather than fiscal-period labels, and returning null instead of fabricated zeros. No contradiction with 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 long but well-structured, starting with the core purpose, then return details, technical nuances, and usage guidance. The extra length is justified by the complexity of XBRL handling and a concrete return example, though it is not as concise as simpler tool descriptions.

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 provides a detailed structuredContent example covering all concepts and period objects, plus behavior for missing concepts. Combined with strong annotations and a single-parameter schema, the agent has everything needed to invoke the tool and interpret results.

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 already provides a full description of the ticker parameter with examples of both ticker and CIK formats, and the description merely restates this. With 100% schema coverage, the baseline of 3 applies; the description adds no new semantic 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 clearly states it returns key financials from SEC XBRL company facts, listing specific metrics (revenue, net income, EPS, etc.). It distinguishes itself from sibling SEC tools by focusing on financial figures versus filings, holdings, or insider transactions.

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?

Explicit 'When to use' and 'When NOT to use' sections provide clear guidance for valuation/screening and exclusions like segment detail or analyst estimates. This gives the agent actionable direction for selecting this tool against alternatives.

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 read-only, idempotent, and non-destructive behavior, and the description adds substantial context: it wraps EDGAR's own index, covers filings since 2001, and explains that totalMatches is a lower bound with totalIsApproximate true once EDGAR's count exceeds 10,000. This goes well beyond the structured 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 effectively structured with a clear definition, usage sections, parameter list, and return example. Every sentence is informative; the included structuredContent example is useful and not redundant. It is detailed yet remains focused.

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?

Even without an output schema, the description fully specifies the return shape with a concrete example, explains the approximate total behavior, and includes the source URL. It covers coverage limits, parameter usage, and result interpretation, making it self-sufficient for agent 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 coverage is 100%, so baseline is 3. The description adds practical usage details such as quoting exact phrases, limiting to form types with examples, and specifying the 1–50 range for limit. While some repetition exists, the consolidated Args section and range clarification provide marginal added value.

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 specific verb and scope: "Full-text search across all SEC EDGAR filings since 2001 for a keyword or phrase." It clearly distinguishes this tool from siblings by noting it covers every filer and form type, and explicitly contrasts with edgar_filings_feed.

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?

Dedicated 'When to use' and 'When NOT to use' sections provide explicit guidance. It names the alternative tool (edgar_filings_feed) and gives concrete scenarios like 'cross-company research' and 'litigation or regulatory tracking', plus a specific exclusion (pre-2001 results).

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?

Discloses important behaviors beyond the read-only/idempotent annotations: individual unparseable filings are skipped, total parse failure errors and is not billed, and the underlying XSL-rendered URL quirk is explained. This gives the agent confidence in edge-case handling.

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 well-structured with clear sections and no filler. The JSON example is lengthy but necessary given there is no output schema, and every sentence serves a purpose.

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 lacking an output schema, the description includes a complete JSON response example, covers error behavior, exclusions, and the data source. It thoroughly equips an agent to use the tool correctly.

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 already provides full descriptions for all three parameters (ticker, limit, forms) with default values and constraints. The description's Args section essentially repeats this information without adding new semantic nuance.

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 it parses SEC Form 4 filings to return insider transactions for a U.S. public company. It explicitly differentiates from sibling tools like edgar_13f_holdings by noting that institutional holdings are NOT the intended use case.

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 includes dedicated 'When to use' and 'When NOT to use' sections, naming Form 13F as the alternative for institutional holdings. This explicitly guides the agent on when to select this tool versus siblings.

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, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds valuable behavioral context by explaining it combines three EIA series into one lookup and includes week-over-week percent changes, plus the data source. No contradictions with 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 well-structured with clear sections for overview, usage, exclusions, and return format. Every sentence adds value, and the example output is front-loaded enough for quick understanding without unnecessary verbosity.

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, the description provides a complete structuredContent example, showing the exact fields and units. It covers data source, frequency, and scope, making the tool's behavior fully understandable without needing additional lookups.

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 has zero parameters, and the description explicitly states 'Args: none,' which is appropriate. With no schema to explain, the description correctly notes the absence of arguments, making parameter semantics self-evident.

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 that the tool retrieves U.S. energy market data (WTI crude price, crude oil inventories, natural gas storage) from the EIA. It explicitly lists the three combined series, distinguishing it from siblings like macro_gdp and macro_jobs by naming specific energy metrics.

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 an explicit 'When to use' section naming energy-sector context, inflation pass-through analysis, and trading around EIA releases. It also includes a 'When NOT to use' section excluding regional breakdowns, refined products, and non-U.S. data, giving clear guidance on alternatives.

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, openWorldHint, idempotentHint, and non-destructive. The description adds valuable context: it is BEA's official lagged percent-change series, requires no math, and includes a source URL. No contradictions with 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?

Well-structured into paragraphs for purpose, usage, exclusions, and return value. Each sentence earns its place, and the example return object is compact yet informative. Nothing is redundant.

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 no output schema, the description provides a full structuredContent example with all field names and sample values, plus source attribution. For a zero-parameter read tool, this is complete and self-sufficient.

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 has zero parameters and the description confirms 'Args: none.' With no parameters to document, the baseline of 4 applies, and the description appropriately notes the absence of arguments.

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 it returns the latest U.S. real GDP growth rate as annualized quarter-over-quarter, plus prior quarters for trend context. It distinguishes itself from sibling macro tools by explicitly excluding dollar levels and expenditure-component details.

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?

Provides explicit 'When to use' and 'When NOT to use' sections with concrete use cases (growth pace, recession-risk context) and exclusions (dollar levels, components, nowcasts). This gives the agent clear decision 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context beyond annotations: data source (Census Bureau), units (thousands of units at SAAR), and the structuredContent return shape with field names. It doesn't contradict annotations, though it omits deeper caveats like data revisions or seasonal adjustment nuances.

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 well-structured with clearly separated sections: purpose, when to use, when not to use, args, return format, and units. Every sentence contributes meaningful information without redundancy or fluff. It is appropriately sized for the tool's complexity.

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 has no parameters and no output schema, the description fully documents the return payload fields (asOf, startsThousands, permitsThousands, startsMomPercent, permitsMomPercent, source), units, source URL, and interpretive context. It leaves no critical gaps for an AI agent to invoke and use the result correctly.

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 has zero parameters, and the description explicitly states 'Args: none.' The input schema confirms an empty object, so there is no additional parameter information needed. The baseline for zero parameters is 4, and the description fully satisfies it.

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 identifies the tool's purpose: providing the latest U.S. housing starts and building permits at a seasonally-adjusted annualized rate. It distinguishes itself from sibling macro tools by focusing specifically on residential construction and even clarifies the leading-indicator relationship between permits and starts.

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 includes explicit 'When to use' and 'When NOT to use' sections with concrete examples (gauging housing-market momentum, leading indicator for construction activity) and exclusions (single-family vs multi-family, regional detail, completions). This provides clear decision guidance for selecting this tool over alternatives.

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 indicate read-only, idempotent, non-destructive. The description adds meaningful behavioral context: seasonally adjusted series, computed month-over-month and year-over-year changes from BLS levels, and units explanation for payrolls. The example output clarifies the return shape. No contradiction with 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?

Front-loaded with a one-line purpose, followed by return details, usage guidance, and an example. Every section serves a clear role; no filler or redundancy. The example JSON and units note add practical value without bloat.

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 no output schema, the description fully documents return values via a concrete JSON example and explains payroll units. It covers usage context, exclusions, and data source, making it self-sufficient for a no-parameter 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?

Tool has zero parameters, and baseline is 4. The description explicitly states 'Args: none,' which is sufficient. No parameter explanations 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 clearly states it provides latest U.S. labour-market data from BLS with computed headline changes, and enumerates the specific metrics returned. It distinguishes itself from siblings via the when-NOT-to-use section explicitly naming state/metro detail, industry breakdowns, and JOLTS.

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?

Explicit 'When to use' and 'When NOT to use' sections provide clear context for labour-market assessment against alternatives. It names exclusions (state/metro, industry, JOLTS) and implies alternatives like macro_gdp or bls_cpi for other macro indicators.

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. The description adds meaningful context: defines core as 'PCE excluding food and energy', explains the Fed's preference for PCE over CPI, and shows the exact return structure in the JSON example. No contradictions with 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 well-organized with a clear lead sentence, contextual explanation, direction on usage, and a compact JSON example. Every sentence adds value, and the structure front-loads the essential definition.

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 parameterless tool with no output schema, the description is fully sufficient. It covers what is returned (headline and core with indices and percent changes), the source URL, and the exact structuredContent format. Sibling differentiation is also addressed. No gaps remain.

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 zero parameters, the baseline is 4. The description explicitly states 'Args: none', confirming no inputs are needed. There is no additional parameter information to provide.

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 identifies the tool as returning PCE price index data (headline and core) with YoY and MoM changes, and explicitly distinguishes it from CPI via the 'When NOT to use' section pointing to bls_cpi. The resource and scope are specific and 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?

Provides explicit 'When to use' and 'When NOT to use' guidance, naming bls_cpi as the alternative for CPI. This gives clear decision criteria for tool 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral context beyond annotations: it sources from BLS schedule, returns only releases on/after today, sorts sooner-first, and provides an output shape example. Slight gap: no mention of rate limits or potential staleness, but the additional behavior is clear.

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 well-structured with a clear lead sentence, explicit use cases, parameter details, and a structuredContent example. Each section earns its place; the content is informative without redundancy.

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?

Even without an output schema, the description provides a complete structuredContent example, covers all parameter behavior, explains the when/why, and lists explicit non-use cases. Combined with rich annotations, the tool is fully specified for an agent to select and invoke correctly.

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% and both parameters have descriptions. The description adds extra semantics by explaining the default limit (10), the case-insensitive substring behavior for filter, and giving concrete examples like 'CPI'. This exceeds the baseline 3 without being verbose.

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 uses a specific verb ('Upcoming... releases') and resource ('BLS news-release schedule'), clearly stating it provides dates and times for future economic data. It distinguishes from siblings by explicitly noting it does not provide release values (like bls_cpi) or Fed/FOMC dates.

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 has explicit 'When to use' and 'When NOT to use' sections, naming alternatives (bls_cpi for CPI) and exclusions (Fed/FOMC, non-U.S. calendars). This fully guides selection among sibling 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 read-only, idempotent, non-destructive behavior, and the description adds contextual transparency by specifying the data is seasonally adjusted, from the Census Bureau's Advance Monthly Retail Trade Survey, and a monthly government release. It does not contradict annotations and provides useful processing details (MoM and YoY calculations).

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 well-organized and concise: first sentence defines the metric, second explains the return, then usage guidance, then args, and a sample output. Every sentence serves a purpose, no wasted words, and it is front-loaded with the most critical 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?

For a simple, zero-parameter tool, the description is fully complete. It explains what is returned (sales total, MoM, YoY, source) and provides an example of the structured content, even without an output schema. It also covers usage context and limitations, making it entirely sufficient for an agent to invoke correctly.

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 has zero parameters, and the description explicitly states 'Args: none.' This is unambiguous and clearly communicates that no input is required. The baseline for 0 params is 4, but the explicit statement earns a 5.

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 provides 'Latest U.S. retail sales, seasonally adjusted, excluding motor vehicles and parts' with a specific scope (ex-autos) and intent (consumer-spending signal). This distinguishes it from other macro tools and establishes the exact resource and output.

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?

Includes explicit 'When to use' and 'When NOT to use' sections, listing appropriate use cases (consumer spending, GDP nowcasting, retail demand) and exclusions (category-level detail, auto-inclusive headline, real-time/weekly data). This provides clear guidance for tool selection versus alternatives.

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 (readOnlyHint, idempotentHint, destructiveHint), the description discloses important failure semantics: 'A chain that could not be read reports failed: true with null balances rather than a misleading 0; if every chain fails the call errors and is not billed.' It also explains the underlying complexity of different contract addresses and the summation behavior, giving the agent a clear mental model of 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?

The description is well-structured with clear sections: overview, supported chains/tokens, use/non-use cases, arguments, and an explicit return example. Every sentence contributes functional information, and the return example is concise and illustrative. It is appropriately sized for a tool with this complexity.

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 lacking an output schema, the description fully compensates by showing a concrete return structure with example data, explaining the meaning of 'failed' chains, and specifying defaults. It also addresses billing behavior, making the tool's side effects and edge cases clear. This is complete for an agent to invoke correctly.

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 already covers all parameters with 100% description coverage, so the baseline is 3. The description adds contextual meaning by explaining why the token parameter matters (different contract addresses per chain) and that chains defaults to all five supported chains, which aids selection. However, the per-parameter details in the description closely mirror the schema, so it doesn't go beyond a 4.

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 specific and complete statement of purpose: 'The same token's balance for one address across multiple EVM chains, in a single call.' This clearly identifies the verb (check balance), resource (token across chains), and scope (multi-chain), and distinguishes it from the sibling onchain_token_balances by explaining that it aggregates multiple chains and sums balances.

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 an explicit 'When to use' and 'When NOT to use' section, naming the alternative tool (onchain_token_balances) and clarifying the trade-off (cheaper for single-chain queries). It also lists supported chains and tokens, giving concrete usage criteria.

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 (read-only, idempotent), the description adds critical behavioral details: parallel RPC reads, unit conversion to gwei, null handling for unreachable chains, and the policy that the call is not billed if all chains fail. This substantially enriches the agent's understanding.

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 well-organized with clear sections (supported chains, when to use, args, returns). It is appropriately detailed—every sentence adds operational value, from the parallel RPC behavior to the failure semantics.

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 fully explains the return format via an example, including a nested 'chains' array and 'source' field. It also covers error behavior and billing, making the tool's behavior clear for an agent.

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 already fully documents the 'chains' parameter (enum + description), so baseline is 3. The description adds the default behavior ('Defaults to all five supported chains') and clarifies the aggregated nature of the call, providing extra value 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 clearly states it returns current gas prices across multiple EVM chains in a single call, with a specific verb ('Reads eth_gasPrice') and resource ('multiple EVM chains'). It distinguishes itself from sibling tools by emphasizing the multi-chain aggregation and unit conversion.

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?

Explicit 'When to use' and 'When NOT to use' sections give concrete use cases (cheapest chain selection, cost estimation, low-gas monitoring) and exclusions (EIP-1559 breakdown, historical data). This provides clear guidance for tool 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description goes further by explaining the tool calls latestRoundData on the feed contract itself, which eliminates API vendor/rate limit/key concerns, and it includes staleness metrics (updatedAt, ageSeconds) so the agent can judge data freshness. No contradictions with 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 long but every section earns its place: intro, mechanism, named pairs, usage guidance, parameters, return structure. It is front-loaded with purpose and structured into scannable paragraphs. There is no filler or redundant restating of the tool name.

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 there is no output schema, the description provides a detailed return example with field names and types, including staleness measures. It also covers the supported chains and the distinction between named pairs and raw addresses. Limitations (no historical prices) are stated. This is complete for an agent to use correctly.

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 descriptions cover both parameters (pair and chain) at 100% coverage, so the baseline is 3. The description adds examples ('ETH/USD', 0x...) and notes that any feed address on supported chains works, but the schema already conveys the core semantics. No additional parameter behavior is introduced beyond what the schema fields express.

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 specific verb-resource combination: 'Read any Chainlink price feed directly on-chain'. It clearly differentiates itself from sibling tools like onchain_portfolio and onchain_gas by targeting Chainlink oracle prices specifically, and gives the exact mechanism (latestRoundData on the feed contract).

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 has explicit 'When to use' and 'When NOT to use' sections. It names alternatives (onchain_portfolio or DEX quote when no Chainlink feed exists) and explicitly excludes historical/point-in-time prices. This is exactly the kind of clear guidance an agent needs.

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 (readOnlyHint, idempotentHint, destructiveHint), the description discloses the on-chain price source (Chainlink, no API key/rate limits), asset coverage, sorting order, block-height stamping, zero-balance handling via emptyAssets, and the billing guarantee on total failure. This is rich added context with no 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 structured logically with clear sections (overview, asset coverage, price source, when-to, args, output example) and front-loaded with the core purpose. While longer than minimal, every section contributes meaningful detail; the output example is especially valuable since there is no output schema.

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 compensates fully by providing a structuredContent example, explaining the meaning of emptyAssets, specifying error behavior when all reads fail, and documenting the exact asset list and price source. It gives an agent everything needed to correctly invoke and interpret the 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?

The input schema already fully describes the single address parameter, including format ('0x + 40 hex') and chain ('on Base'). The description's Args section simply restates 'the wallet address to value' with no additional semantic detail, so it adds no value 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 opens with a clear statement of purpose: 'USD-valued portfolio for a wallet on Base, priced from Chainlink on-chain oracles.' It specifies the exact resources (wallet, ETH, major ERC-20 balances, Chainlink USD aggregators) and distinguishes itself from sibling tools by limiting scope to curated assets and the Base chain.

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 includes explicit 'When to use' and 'When NOT to use' sections, listing use cases like wallet valuation and treasury reporting, and excluding exhaustive token scans, LP positions, NFTs, and other chains. It provides clear criteria for selecting this tool over alternatives.

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 readOnlyHint=true and idempotentHint=true annotations, the description discloses concrete behavioral details: it handles rate limits and partial failures, returns null for failed reads rather than misleading zeros, counts failures, errors if every read fails, and reports the block height of the snapshot. This is exactly the kind of context agents need to interpret results correctly.

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 a front-loaded, high-signal summary. The rest is organized into clear sections (motivation, supported chains, when to use/not use, args, return example) with no redundant padding. Every sentence earns its place, and the length is justified by the tool's complexity.

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 full responsibility for explaining return values; it provides a complete JSON example with all fields, including edge-case behavior (null for individual failures, 'failed' count, error condition for total failure). It also covers defaults, supported chains, and limits, making it fully sufficient for an agent to invoke and interpret this tool correctly.

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 already covers 100% of parameters with descriptions, so the bar is at 3. The description adds extra semantic nuance: 'Duplicates removed, order preserved' for addresses, the exact default token behavior (canonical USDC), and a structured output example that shows how token decimals are scaled to produce clean balances. This extra context earns a 4.

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 'Read an ERC-20 token balance for up to 500 wallet addresses in a SINGLE call', which clearly states the verb (read), the resource (ERC-20 token balance), and a key distinguishing scope (bulk, up to 500 addresses). It also distinguishes from sibling tools like onchain_portfolio or onchain_cross_chain_balances by focusing on ERC-20 balances for a list of holders on a single chain.

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 explicitly provides 'When to use' (portfolio roll-ups, airdrop checks, holder analysis) and 'When NOT to use' (native ETH balances, historical blocks), giving the agent clear selection criteria. It also contrasts with manual eth_call batching, implying this is the efficient bulk 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 read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context: pure deterministic compute with no network/model calls, the specific repairs performed, and the complete return structure including errors and repairs. This goes well beyond the annotations and is fully consistent.

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 well-structured with clear sections: main purpose, list of fixes, usage conditions, arguments, and return schema. Every section adds necessary information with no filler, and the front-loaded purpose statement is immediately actionable.

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 three parameters, full schema coverage, and strong annotations, the description is remarkably complete. It explains the return value in detail, the boundaries of what it can fix, and the deterministic nature of the operation. There are no apparent gaps for an agent to select and invoke this tool correctly.

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 the baseline is 3. The description reinforces the parameters with concrete coercion examples ('36' -> 36, 'true' -> true) and clarifies the schema draft version. While it largely restates the schema, the examples add practical meaning for the coerce parameter, earning a slight bonus.

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 uses a specific verb ('repair') and resource ('messy or invalid JSON') and clearly states the optional schema validation/coercion. It distinguishes itself from sibling tools like tabular_to_json by focusing on repair rather than conversion, and explicitly enumerates the types of malformations it addresses.

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 'When to use' and 'When NOT to use' sections with concrete conditions (JSON.parse fails, schema coercion needed, already-valid JSON not needing checks). This exceeds the 'clear context' bar and includes exclusions, fully guiding an agent on when to select this tool over alternatives.

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 indicate read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context: 'Pure deterministic compute — no network or model calls' and details about handling BOM, ragged rows, quoted fields, and type inference. It also describes the return envelope (ok, format, columns, rows, rowCount, changed, errors, repairs) beyond what 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?

The description is well-structured with sections: summary, What it handles, When to use, When NOT to use, Args, and Returns. It is appropriately detailed for a tool with 5 parameters and a structured output, with the main purpose stated in the first sentence.

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 complexity, the description is thorough. It covers input and output formats, edge cases (quoted commas, BOM, ragged rows), parameter behaviors, and the exact structure of the returned object. There is no gap that would leave an agent uncertain about invocation or results.

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 baseline is 3. The description lists each argument but largely restates the schema descriptions (e.g., format default, inferTypes behavior). It adds no significant semantic nuance beyond what the schema already provides, though it does embed the Args list in a readable format.

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 'Convert messy tabular text into clean, typed JSON rows,' providing a specific verb, resource, and output. It clearly distinguishes itself from siblings by detailing supported formats (CSV/TSV/Markdown) and explicitly stating it is not for pure JSON or binary inputs.

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 includes explicit 'When to use' and 'When NOT to use' sections, naming alternatives like clean JSON and unsupported formats (HTML/xlsx/binary). This provides clear context for choosing this tool over other siblings such as structured_json_repair.

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 annotations (read-only, etc.), the description discloses update frequency (once per business day), data source, and full output structure. It explains the inversion flag and history ordering, providing rich behavioral context.

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 well-structured and front-loaded with the core purpose. The example output is arguably necessary given no output schema, and every section adds 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?

With no output schema, the description compensates fully by showing a concrete structuredContent example, covering the latest and history. It also clarifies use cases and limitations, making it complete for a single-parameter 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 100%, and the Args section merely repeats the schema's description of 'days' including the 1-30 range and default. No new meaning is added, so baseline 3 is appropriate.

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 first sentence clearly states the tool provides U.S. Treasury par yield curve rates with computed spreads. It distinguishes itself from siblings by specifying the exact data (tenors, 2s10s, 3m10y, inversion flag) and the official source.

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?

Explicit 'When to use' and 'When NOT to use' sections give concrete context: use for discounting/curve shape/recession signals, not for intraday quotes or non-U.S. curves. This is strong guidance even without naming sibling tools.

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