LiveDataLink

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

Annotations already declare read-only, idempotent, safe behavior. Description adds the specific data fields returned (e.g., PM2.5, ozone) and health category rating, providing context beyond annotations. No behavioral contradictions.

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 sentences, front-loaded with core function and return fields, followed by examples. No filler or repetition. Every sentence 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?

Despite no output schema, description lists key return fields (AQI, pollutants, health rating) giving the agent sufficient context. Simple tool with few parameters, so completeness is high.

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%; both parameters (dry_run, location) are described in schema. Description does not add meaning beyond schema, only mentions 'any location' implicitly. 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?

Description clearly states the tool gets current air quality data for any location, listing specific pollutants returned. It distinguishes itself from siblings as the only tool for air quality. The example queries reinforce purpose.

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 lists example use cases and query phrasings, covering a range of common questions. No direct alternatives in siblings, so guidance is complete.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds critical context: the composite nature, graceful degradation of CFPB data, and that it produces a rating. This goes beyond annotations and fully informs the agent of behavioral traits.

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 a single paragraph that efficiently covers purpose, inputs, data sources, output format, limitations, and use cases. It is front-loaded with the core purpose. While dense, every sentence serves a purpose; no 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?

Given no output schema, the description explains the output (rating and numbers) and lists the specific financial metrics and complaint data included. It also notes the best-effort nature of CFPB data. This is sufficient for an agent to understand what the tool returns and the reliability.

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 baseline is 3. The tool description restates parameter inputs (bank name or CERT) but does not add significant new detail beyond the schema. The schema parameter descriptions are already thorough, so the description adds marginal 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 clearly states the tool provides a one-call financial-health read for US banks, combining FDIC and CFPB data into a composite rating (HEALTHY/STABLE/WATCH/FAILED). It specifies valid inputs (bank name or FDIC cert) and distinguishes itself from sibling tools like individual FDIC/CFPB tools by offering a consolidated assessment.

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 lists use cases (sponsor/partner bank selection, treasury checks, deposit-safety) and states it is informational. However, it does not explicitly advise against using this tool when, for example, raw FDIC data is needed, or when CFPB data must be complete. The alternatives are implied but not spelled out.

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 provide readOnlyHint, idempotentHint, openWorldHint. The description adds significant behavioral context: best-effort nature, fallback behavior when GLEIF fails or sanctions binding is unavailable, entity cap of ~15, reliance on self-reported data, and disclaimer about name matches. 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 informative but verbose, containing several clauses and details that could be condensed. It is front-loaded with purpose but includes some extraneous phrases ('keyless CC0 reference data'). Adequate but not optimally concise.

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 complexity of the tool (ownership mapping and sanctions screening), the description covers input options, process, limitations, output structure (ownership structure, per-entity results, overall verdict), and caveats. No output schema exists, so the description's detail on returns is essential and thorough.

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 value by explaining the LEI override behavior and the dry_run preview purpose, beyond the schema descriptions. It provides example LEI and clarifies that company can also be a LEI.

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 ('screens') and resource ('ownership chain'), and immediately distinguishes itself from single-entity screenings by stating it answers the real question about sanctioned ownership chain members. It clearly differentiates from sibling tools like company_trust_check and sanctions_screen_entity.

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 explains when to use this tool (for ownership-chain screening) and mentions the alternative company_trust_check for single-entity screening. However, it does not explicitly state when not to use it (e.g., for a simple name check), though the context implies 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 provide readOnlyHint, idempotentHint, and destructiveHint false. Description adds 'Returns a monthly time series' and 'Keyless', but lacks details on rate limits, caching, or data freshness. Adequate but not enhanced beyond 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?

Description is two concise sentences, front-loaded with purpose. Every sentence adds value. Could be slightly more structured by highlighting key points (e.g., monthly, keyless) but is efficient overall.

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?

Tool has 4 parameters with full schema coverage and no output schema. Description states returns 'monthly time series' but does not specify response format or behavior for start/end year defaults. Adequate for a simple retrieval tool but could be more 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 description coverage is 100%, so the schema already fully documents parameters. The description lists the same indicator names as the schema, adding no new meaning beyond what is in the structured fields.

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 clearly states 'US labor & price statistics from the Bureau of Labor Statistics by friendly name' and lists specific indicators. It distinguishes from sibling tools like bls_series (likely raw series API) and fred_* (FRED data) by being keyless and using friendly names.

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?

Description implies usage for BLS data retrieval with friendly names and mentions 'Keyless official BLS data', but does not explicitly state when to use vs alternatives (e.g., bls_series for custom series IDs). No when-not-to-use 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=true, destructiveHint=false, and idempotentHint=true, so the description doesn't need to cover safety. It adds that the tool fetches time series data, which is a behavioral constraint (time series vs single value). However, no additional details on rate limits or response size are provided, which is acceptable given the annotation coverage.

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

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

The description is two sentences with zero fluff. The first sentence states purpose with an example, and the second clarifies usage context. Every sentence earns its place, making it highly concise 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?

For a tool with 4 parameters and no output schema, the description is adequate. It explains what the tool does, when to use it, and provides an example. It does not describe the response format, which might be a gap, but the tool's simplicity and the annotations partly compensate.

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 adds an example series ID (LNS14000000) which provides concrete context. It does not elaborate on optional parameters like dry_run, start_year, or end_year beyond what the schema already offers, so 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 clearly states the tool fetches any BLS time series by raw series ID and gives a concrete example (LNS14000000 for unemployment rate). It implicitly distinguishes from siblings by specifying 'when you know the exact series ID', which implies alternative tools like bls_indicator exist for when the ID is unknown.

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 says to use this tool when you know the exact BLS series ID, providing clear context. It does not explicitly name alternatives or state when not to use, but the implied guidance is sufficient for most agents.

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 readOnlyHint=true and destructiveHint=false. The description adds value by listing the returned metadata fields (e.g., title, authors, subjects) and specifically noting 'whether its full text is indexed here', which is beyond the annotation coverage.

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 a single sentence that front-loads the verb and resource, lists key fields, and contains no extraneous 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 retrieval tool with good annotations and no output schema, the description covers the essential behavior (fields returned). It lacks mention of error handling or rate limits, but those are low priority for such a 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 description coverage is 100%, so the schema already documents both parameters. The description mentions 'by its Project Gutenberg id' which aligns with gutenberg_id, but adds no additional semantics 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 the verb 'get' and resource 'full catalog metadata for a single book', listing specific fields (title, authors, etc.). It distinguishes from sibling tools like book_search and book_get_text by specifying the input is a Project Gutenberg ID.

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

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

The description implies use when metadata for a single Gutenberg book is needed, but it does not explicitly contrast with alternative tools (e.g., when to use book_fulltext_search instead) or provide exclusion 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by detailing the return format (matching passages with book title, author, snippet) and the corpus scope. It does not contradict 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?

The description is three sentences. The first sentence is information-dense and front-loaded, covering operation and output. The second sentence ('This is the headline feature...') is somewhat redundant with the first but serves to emphasize value. The third sentence adds the optional restriction. Overall, it is concise but not perfectly waste-free.

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?

Without an output schema, the description takes on the burden of explaining return values, which it does by listing book title, author, and snippet. It also covers optional restriction and the scope of the corpus. It lacks details on edge cases (e.g., no matches, pagination) but given the simple search nature and helpful annotations, it is largely 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 description coverage is 100%, so the baseline is 3. The description adds minimal additional meaning beyond the schema: it explains that query accepts 'phrase or keywords' and that gutenberg_id restricts to one book, but these are already stated in the schema descriptions. No new syntax or parameter relationships are introduced.

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

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

The description explicitly states the operation ('Search INSIDE the indexed corpus of top public-domain books'), the input ('phrase or keywords'), and the output ('matching passages... book title, author, and a snippet around the match'). This is a specific verb+resource+output combination that clearly distinguishes it from sibling tools like book_search (metadata lookup) and book_get_text (full-text retrieval).

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 clear context: it is a full-text search tool for public-domain books, ideal for finding where passages appear. It also mentions the optional restriction by gutenberg_id. However, it does not explicitly name alternative tools (e.g., book_search, book_details) or state when NOT to use this tool, so it stops short of 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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description discloses key behavioral nuances: for non-indexed books it returns a public gutenberg.org URL instead of text, and it explains the pagination mechanism. This provides valuable context about expected outputs beyond what annotations alone offer.

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

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

The description is two sentences, front-loaded with the primary purpose, and includes practical usage guidance without unnecessary fluff. Every sentence contributes meaning: the first states functionality, the second explains pagination and fallback behavior.

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 read-only tool with a small schema and no output schema, the description covers the essential aspects: what it returns (text or URL), how to page, and when the fallback applies. It could optionally define what a 'passage' is or describe the exact response format, but current detail is 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 schema already describes each parameter with 100% coverage, so the baseline is 3. The description adds value by explicitly linking from_seq and max_passages as a pagination pair, which clarifies their combined intent beyond individual descriptions. It also highlights the required gutenberg_id as the core input.

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 starts with 'Return the full text of an indexed book by Gutenberg id, paginated by passage,' which clearly states the tool's specific action and resource. It also distinguishes itself from siblings like book_fulltext_search by explicitly focusing on retrieving full text rather than searching within it. The fallback behavior for non-indexed books is an additional clarifying detail.

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 clear context for when to use the tool: when you need the full text of a book by Gutenberg ID. It also explains pagination usage with from_seq and max_passages. However, it does not explicitly mention alternatives or when not to use it, such as using book_fulltext_search for snippet-level searches.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context about ranking (by keyword relevance then download popularity), the live external source (Gutendex), and the exact return fields, which goes beyond the annotations. It lacks specifics about rate limits or pagination, but with strong annotation coverage this is sufficient.

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

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

The description is three sentences, front-loaded with the core purpose, and every sentence adds value (scope, ranking, return fields, alternative tool). No filler or repetition.

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

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

For a read-only search tool without an output schema, the description sufficiently covers what the tool does, what it returns, how results are ordered, and provides a clear alternative. Parameter semantics are fully handled by the schema, and the scope is clearly bounded.

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 documents all 6 parameters with 100% description coverage, including examples. The description reiterates the filter options but does not add additional semantics beyond what the schema provides, so a baseline score of 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 description states a specific verb ('Search') with a specific resource ('full Project Gutenberg catalog') and clearly defines the search dimensions (title/author/subject) and return fields. It explicitly distinguishes itself from the sibling book_fulltext_search, making purpose 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?

The description provides an explicit alternative: 'Use book_fulltext_search to search inside the locally indexed top books.' This tells the agent when not to use this tool and points to the appropriate sibling, satisfying the when-to-use criterion.

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

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

The description discloses that the tool queries an external API (Gutendex) and a local database (D1), which adds valuable context beyond the annotations (readOnlyHint, idempotentHint). It does not contradict any annotations and provides a transparent view of data sources and what is reported.

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 a single, front-loaded sentence that conveys all essential information without any wasted words. It efficiently communicates the tool's purpose and scope.

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 simplicity of the tool (one optional parameter, no output schema), the description adequately covers what the tool does. It specifies the data sources and elements reported. While it could describe the output format or structure in more detail, it remains sufficient for an agent to understand the tool's behavior.

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 only parameter is 'dry_run', which is fully described in the input schema (100% coverage). The description does not add any additional context about the parameter beyond what the schema already provides. Baseline 3 is appropriate since the schema carries the full burden.

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 reports the 'books store status' and specifies exactly what it reports: the catalog via Gutendex and local D1 indexed-corpus counts. It uses a specific verb 'Report' and differentiates from siblings like book_search, book_details, etc., which are for retrieving content rather than status.

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 implicitly indicates this tool is for checking system status and data freshness, but it does not explicitly state when to use it versus alternatives. However, given the context of sibling tools (e.g., book_search, book_details), it is clear that this is the only status-reporting tool among them.

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, so the safety profile is known. The description adds rich behavioral context: the signal logic, the per-symbol return fields, tunable thresholds for calibration, and the 'HEURISTIC signal... not investment advice' disclaimer.

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 four sentences, each serving a distinct purpose: what it scans, what it returns, how to calibrate, and a risk disclaimer. It is dense but entirely relevant, with no fluff.

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 supplies the exact return structure per symbol. It also covers the tunable parameters and the heuristic nature of the signal. For a moderately complex scanning tool, this is sufficient 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 covers 100% of parameters with defaults and ranges, so the baseline is 3. The description adds semantic grouping by identifying rsi_threshold, ma_period, proximity_pct, and lookback_days as tunable thresholds for calibration, which clarifies their role beyond individual schema entries.

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 'Screen one or more US tickers for a mean-reversion 'bounce' setup on daily bars', clearly naming the action and resource. It lists concrete criteria (support, moving average, RSI, volume) that distinguish it from sibling tools like stock_quote or candlestick_signals.

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

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

The description clearly implies when to use this tool—when screening tickers for a bounce setup—by specifying the exact strategy and conditions. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough to guide 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?

Adds behavioral context beyond annotations: discloses heuristic detection, conservative thresholds, research-only disclaimer, and describes the return fields ({pattern, date, direction, barIndex}). Annotations already cover read-only/idempotent, so this is additional useful 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?

Three sentences: purpose, return format, and caveat. Every sentence earns its place, with no redundancy and front-loaded with the primary action.

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 moderate tool with 3 params and no output schema, the description covers purpose, output structure, and heuristic caveat. It doesn't discuss edge cases or error behavior, but it is sufficiently complete for an agent to decide whether to use it.

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% for all 3 parameters, so the baseline is 3. The description adds no extra parameter semantics beyond mentioning 'recent daily bars' which maps to lookback_days; it doesn't go beyond what the schema already provides.

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 'Detect classic candlestick patterns on a ticker's recent daily bars' and lists specific patterns (hammer, engulfing, doji, etc.). It uses a specific verb and resource, and differentiates from siblings like stock_quote or stock_history by focusing on pattern detection.

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 clear context: it scans daily bars, is heuristic with conservative defaults, and is for research. It doesn't explicitly name alternatives or exclusions, but the use case is well implied for detecting candlestick patterns.

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 non-destructive behavior. The description adds that it is 'Keyless' and lists return fields, providing some added context but no further behavioral details beyond 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?

Description is a single, front-loaded sentence with no superfluous words. It efficiently communicates purpose and return fields.

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 lookup tool with strong annotations and full schema coverage, the description covers the return fields and lack of authentication. It does not mention error handling for missing crates, but this is a minor gap given the tool's simplicity.

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 clear descriptions. The tool description does not add parameter-specific meaning beyond the schema, so baseline of 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?

Description clearly states the tool looks up a Rust crate on crates.io and lists specific return fields (latest version, description, total downloads, repository, homepage). The focus on Rust crates distinguishes it from sibling tools like npm_package or pypi_package.

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 implicitly indicates use for Rust crate lookup and mentions 'Keyless' for no authentication. However, it does not explicitly state when to use or not to use this tool versus siblings, leaving context largely inferred from the tool name.

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 include readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: tool joins multiple data sources, returns a verdict with triggers for NO-GO and CAUTION, and emphasizes it is an analytical aid. 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 moderately long but every sentence adds value: purpose, inputs, data sources, verdict types, triggers, disclaimer. It is front-loaded with the core action ('Vet a US motor carrier...') and structured logically.

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 no output schema, the description adequately explains the output: a GO/CAUTION/NO-GO verdict with reasons and underlying fields. It details triggers for each verdict and data sources, providing sufficient context for an agent to understand what the tool returns.

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% with detailed descriptions for each parameter (dot, mc, name, dry_run). The description adds value by explaining input precedence (prefer DOT number for exact match) and clarifying dry_run behavior ('do not call any upstream data source').

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 purpose: 'Vet a US motor carrier for a freight-brokerage decision' and specifies inputs (USDOT, MC, name) and outputs (GO/CAUTION/NO-GO verdict with reasons). It distinguishes from sibling tools like fmcsa_carrier_lookup by mentioning combined data sources (FMCSA safety data, sanctions, litigation, federal awards), making it unique.

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 identifies the use case ('is this safe and legit to broker a load to?') and includes a disclaimer ('analytical aid, not a substitute for your own carrier-onboarding checks'). While it does not explicitly name alternatives, the comprehensive nature implies it should be used over simpler FMCSA lookups for vetting decisions.

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, covering safety. The description adds behavioral context about the returned metadata fields (name, citations, etc.), which is useful beyond 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?

A single 34-word sentence that front-loads the verb and resource, with no wasted words. Extremely concise.

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

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

The description covers what metadata is returned (name, citations, court, etc.) and mentions the source URL for full text. It lacks details on error handling but is sufficient for a simple retrieval tool with good annotations.

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 parameters are already documented. The description provides an example for the id parameter (Brown v. Board of Education) but adds minimal additional meaning.

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 'Get full metadata for a single case by its CAP id' (verb+resource) and lists specific metadata fields. It implicitly distinguishes from sibling tools like caselaw_search or caselaw_opinion_text.

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

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

The description implies usage for retrieving metadata by CAP id but does not explicitly state when to use this tool over alternatives or provide exclusions.

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 value by specifying that it matches official and parallel citations and returns the CAP id, which goes beyond the annotations' safety profile.

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 extremely concise—just two sentences—and immediately states the action (resolve), avoiding any filler. It is front-loaded with the primary purpose and includes essential examples and output details.

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 tool with only two parameters and no output schema, the description adequately covers functionality (resolution of citations, parallel matching), output (metadata, CAP id), and linkage to a related tool (caselaw_opinion_text). No gaps are evident.

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% with descriptions for both parameters. The description provides example citation formats (e.g., '347 U.S. 483'), which adds practical guidance for the citation parameter beyond the schema. The dry_run parameter is not elaborated in the description, but the schema description is sufficient.

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 resolves reporter citations to cases, provides examples of valid citations, and explicitly mentions that it returns case metadata including the CAP id, distinguishing it from sibling tools like caselaw_search and caselaw_opinion_text.

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 indicates when to use the tool (to resolve a citation) and implies a workflow by mentioning the CAP id for use with caselaw_opinion_text. However, it does not explicitly state when not to use it or list alternative tools for other scenarios.

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

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

The description adds meaningful context beyond the annotations by explaining that text is 'retrieved live from the public-domain CAP static mirror (not stored),' which indicates the data source and lack of caching. It also discloses that the output contains each opinion with its author, giving insight into the response structure. Since annotations already cover read-only and idempotent behavior, this extra detail is valuable, although error handling and response format are not addressed.

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

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

The description is two sentences, front-loaded with the core action and then providing relevant behavioral context and a usage tip. Every sentence adds necessary information without redundancy, making it concise and well-structured.

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

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

Given the lack of an output schema, the description effectively summarizes the return content (opinion text with authors) and the mechanism for bounding response size. It also clarifies the live retrieval nature. However, it does not specify the response format (e.g., plain text vs. structured JSON), error behavior for invalid ids, or default values, leaving some gaps. Overall, it is adequate for a focused 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that max_chars is used to 'bound the response,' which clarifies its purpose beyond the schema's 'maximum total characters.' It also reinforces that the id is a CAP id. Dry_run is not mentioned in the description, but since the schema already documents it, the description sufficiently complements 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 'Fetch the full opinion text of a case on demand by its CAP id,' clearly stating the verb, resource, and required identifier. It further specifies that the response includes each opinion (majority, dissent, concurrence) with its author, distinguishing it from sibling tools that handle case search or metadata. This is specific and not a tautology.

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

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

The phrase 'by its CAP id' establishes a clear prerequisite, implicitly directing the agent to obtain an id from caselaw_search or caselaw_citation_lookup first. It also advises using max_chars to bound the response, which is practical guidance. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of 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 already declare read-only, idempotent, and non-destructive behavior, so the bar for additional disclosure is lower. The description adds valuable context: the index only covers the U.S. Reports reporter, returns metadata (not full text), and the data is public domain. These details are not present in annotations and help the agent anticipate exactly what the tool offers.

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

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

The description is three sentences, each with a distinct purpose: what the tool does, what it returns, and how to proceed plus a coverage caveat. There is no wasted phrasing, and the most critical information (scope and next step) is front-loaded.

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

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

For a search tool with no output schema, the description covers the essential usage context: filters, return type (metadata with CAP ids and citations), and the next-step tool. The coverage limitation is also stated. Minor details like pagination (limit parameter) and dry_run behavior are already documented in the schema, so the description is sufficiently 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?

The input schema covers all 7 parameters with 100% description coverage, including examples and defaults, so the schema carries the primary semantic weight. The description summarizes the main filter axes (case name/keyword, court, jurisdiction, date range) but does not add new syntax or format details. This is at the baseline for a tool with fully documented 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 uses a specific verb ('Search') plus a clear resource ('US court opinions') and enumerates the main filter dimensions (case name/keyword, court, jurisdiction, decision-date range). It also distinguishes itself from its sibling caselaw_opinion_text by stating it returns metadata with CAP ids and citations, making the tool's role clear.

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 tells the agent to use caselaw_opinion_text with a returned id to read full opinions, which is a clear alternative/next-step. It also notes the v1 index coverage limitation (U.S. Reports only), setting expectations for when this tool is appropriate. However, it does not explicitly contrast with other court search siblings like court_opinion_search, so it lacks exhaustive when-not-to-use 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=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds context about being a generic raw query tool and provides a SoQL reference link, but it does not describe the return format, error behavior, or pagination beyond the schema. This is adequate but not rich.

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

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

The description is two sentences plus a reference link, front-loaded with the core purpose. Every sentence adds value: purpose, usage guidance, key parameters, and a documentation reference. There is no wasted text.

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 six parameters and no output schema, the description is somewhat brief. It adequately covers the generic query nature and usage context, but does not explain the return payload or how the output is structured. However, the schema covers parameter semantics, and the SoQL reference helps fill gaps, making it minimally 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 100%, so the schema already documents all six parameters. The description highlights 'a 4x4 Socrata ID and a where-clause,' which maps to the dataset and where parameters, but adds no additional meaning beyond the schema. 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 description clearly states a specific verb and resource: 'Generic SoQL query against any data.cdc.gov dataset.' It distinguishes itself from sibling curated tools with 'Use this when none of the curated tools fit,' making its unique role explicit.

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 usage guidance: 'Use this when none of the curated tools fit.' This tells the agent when to select this tool and implies that curated tools are preferred for their specific datasets. It does not name specific alternative tools, but the sibling list contains many curated CDC tools, making the context clear.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the '12-month rolling counts' detail, which is helpful, but it does not disclose other behavioral traits like pagination, return format, or any access constraints. This is adequate but not rich.

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

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

The description is two sentences long and front-loaded. The first sentence states what the tool provides and includes the dataset ID; the second gives a clear use case. No filler or repetition, every word 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?

The description gives enough context for a simple data-query tool: dataset source, dimensions, rolling-count framing, and a use case. However, with no output schema, it does not describe the expected return fields or row structure. The agent is left to infer the output from the tool name and limited description. Acceptable but with gaps.

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 provides 100% coverage with descriptions for all four parameters (limit, dry_run, indicator, state_name). The description's phrase 'by state and indicator' echoes the schema but adds no additional meaning beyond what is already in the parameter descriptions. 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 description clearly identifies the resource (CDC drug overdose deaths dataset with ID 9j2v-jamp) and the dimensions (by state and indicator), and notes the 12-month rolling counts. It lacks an explicit verb like 'list' or 'get', but the intent to return data is clear and distinguishes it from sibling CDC tools.

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

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

The description provides a useful context ('opioid/fentanyl/stimulant policy research and treatment-program siting') but does not explicitly compare to alternatives or state when not to use this tool. The usage guidance is implied rather than prescriptive, and no exclusions are mentioned.

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 cover read-only, idempotent, and non-destructive behavior. The description adds valuable context by explaining that the data is modeled (expected vs observed), which is crucial for interpreting the numbers as estimates rather than exact counts. 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 two sentences, front-loaded with the dataset identifier and purpose. It is concise, with no redundant filler, and efficiently conveys the core value and use case.

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 lack of an output schema, the description still provides sufficient context: the data source, the modeled nature of the data, the granularity (state and week), and the use case. It doesn't describe the return format, but for a read-only query with well-documented parameters, this is adequate.

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 every parameter has a description in the schema. The description itself does not elaborate on parameter usage beyond mentioning 'by state and week,' which aligns with the state and limit parameters. The baseline of 3 applies since the schema does the heavy lifting and the description adds minimal additional param semantics.

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 providing CDC excess deaths data associated with COVID-19, with modeled expected vs observed deaths by state and week. It distinguishes itself from reported COVID death counts, but lacks an explicit verb like 'query' or 'list' and does not directly compare to sibling tools such as cdc_weekly_deaths_by_state.

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 states its intended use: 'Used to estimate true pandemic impact beyond reported COVID deaths,' which provides clear context. It does not explicitly name alternative tools or exclusionary criteria, but the context is strong enough to guide an agent toward this tool for excess death analysis.

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 non-destructive behavior, lowering the bar. The description adds that data is weekly and state-level, but does not disclose pagination, rate limits, or the existence of the dry_run parameter. 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?

Two focused sentences: the first names the tool and dataset, the second states the return value. No filler or redundancy, and the key information is front-loaded.

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

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

For a read-only data retrieval tool with comprehensive schema descriptions and annotations, the description provides sufficient context about the data source and output. It could mention the season filter or dry_run behavior, but these are already captured in the schema, so the overall completeness is strong.

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% with individual parameter descriptions. The description adds context about state-level granularity and the specific dataset ID, but does not explain parameter semantics beyond the schema. Baseline 3 applies due to high schema coverage.

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

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

The description clearly states the tool returns weekly ILI activity levels per state, using a specific verb and resource. It distinguishes itself from sibling CDC tools by naming the exact data type (influenza-like illness activity) and geographic scope (state-level).

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 provided. The description implies usage for state-level flu surveillance but does not mention alternatives like cdc_outbreak_reports or cdc_vaccination_coverage, leaving selection to inference.

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 convey read-only, open-world, idempotent, and non-destructive behavior. The description adds value beyond those by explaining the exact return contents and citing the source dataset ID (bi63-dtpu), which is especially useful given there is no output schema. It does not detail edge-case behaviors like default filtering or rate limits, but the annotation coverage lowers the burden.

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

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

The description is three sentences with no filler. It front-loads the dataset name and source, then explains the return shape, then gives the primary use case. Every sentence 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?

Given there is no output schema, the description adequately conveys what the tool returns and the domain it supports. However, it omits practical details like available years or how to combine filters, leaving minor gaps for a 5.

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 schema fully documents each parameter with descriptions. The description loosely aligns parameters (cause, state, year) with the data dimensions but adds no new semantics or syntax details, justifying the baseline score of 3.

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 returns NCHS leading causes of death by state, specifying the exact metrics (total deaths and age-adjusted death rates) per cause, state, and year. This distinguishes it from sibling CDC tools like cdc_drug_overdose_deaths or cdc_flu_surveillance.

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 explicitly states the use case 'chronic disease + injury mortality research,' giving clear context on when to use it. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it stops short of 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so safety profile is covered. The description adds the data source and return fields but no additional behavioral context such as data freshness, pagination, or prerequisite conditions. It does not contradict annotations, but offers limited extra transparency.

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 a single sentence that front-loads the core purpose and includes the dataset ID and output fields. Every phrase adds value, with no filler or redundant repetition 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?

For a read-only query tool with well-annotated schema and safety hints, the description is largely complete: it names the source, defines the subject, and lists return fields. However, it omits any mention of filtering capabilities (which the schema provides) and does not clarify how it differs from the generic cdc_dataset_query sibling, leaving a slight gap in selection confidence.

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?

All five parameters have explicit descriptions in the schema (year, limit, state, dry_run, etiology), giving 100% schema coverage. The tool description itself provides no additional parameter meaning, so it meets the baseline but does not enhance 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 specifies the resource ('CDC NORS foodborne / waterborne / enteric outbreak reports') and the dataset identifier (iezt-77pi), which distinguishes it from sibling CDC tools. It also enumerates the return fields (outbreak date, state, etiology, etc.), making its purpose concrete 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?

The description implies usage for outbreak report data but provides no explicit guidance on when to choose this tool over alternatives like cdc_dataset_query or other CDC-specific tools. There are no exclusions or alternative tool references, leaving the agent to infer the appropriate context.

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 that it returns booster and primary series percentages, which explains the output, but does not discuss data freshness, limits, or other behavioral nuances. This meets the baseline for annotation-covered tools.

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

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

The description is two short sentences, front-loaded with the core purpose, and ends with a practical use case. Every word earns its place with no filler.

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 read-only data tool with well-described parameters and thorough annotations, the description provides the essential context: what data is returned and why it might be used. It doesn't need to enumerate parameters since the schema does, making it complete for its 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 every parameter (limit, dry_run, recip_state, recip_county) already has a description. The tool description does not add parameter-specific meaning beyond what the schema provides, maintaining the baseline.

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 'COVID-19 vaccination coverage by US county' and states it 'Returns booster + primary series percentages over time.' This specific verb-resource pairing distinguishes it from sibling tools like cdc_drug_overdose_deaths or cdc_flu_surveillance.

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 notes it is 'Useful for public-health gap analysis,' providing a clear use case. However, it does not name alternative tools or state when not to use it, so it stops short of full 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=true, idempotentHint=true, and destructiveHint=false. The description adds the 'provisional' nature of the data and the dataset source, but does not disclose update cadence, potential data revisions, or pagination. It provides some context beyond annotations but is not rich in behavioral detail.

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 action and data scope, followed by a targeted use case. No filler or redundancy; every word 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?

Despite lacking an output schema, the description clearly communicates the return structure ('death counts per state per ISO week'), identifies the dataset, and mentions practical use cases. All essential information for a read-only data tool is present. The dry_run behavior is documented in the schema, so no gap there.

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?

All 5 parameters have schema descriptions (100% coverage). The description's mention of 'state' and 'cause' aligns with the schema but adds no additional parameter-level semantics beyond what the schema already provides. 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 description uses a specific verb ('Returns') and resource ('CDC weekly provisional deaths by state and cause') with the NCHS dataset identifier. It clearly states the data granularity (death counts per state per ISO week), which distinguishes it from sibling tools like cdc_drug_overdose_deaths or cdc_flu_surveillance.

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 explicit use cases: 'excess-mortality and respiratory-disease seasonality analysis.' This provides clear context for when to use the tool, though it does not explicitly name alternative tools or exclusion 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds minimal context about the optional filter but no additional behavioral traits.

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

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

The description is three sentences long, front-loaded with core information, and every sentence adds value. No redundant or irrelevant content.

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

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

For a tool with 10 parameters and no output schema, the description covers the core purpose, filtering capability, and use cases. It could briefly mention the type of data returned (e.g., yearly totals) but is still complete enough for agent use.

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 each parameter is already described in detail. The description only mentions the NAICS filter, adding no new meaning beyond what the schema provides.

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 retrieves business establishments, employment, and annual payroll from County Business Patterns, with an optional NAICS industry filter. It distinguishes from sibling tools like census_demographics and census_population by specifying business data and use cases.

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 lists use cases (industry research, competitive intel, supply chain analysis) and mentions the optional NAICS filter. However, it does not explicitly state when not to use this tool or provide comparisons 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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description's safety profile is covered. The description adds typical use cases but no additional behavioral traits like pagination, rate limits, or authentication 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?

The description is two sentences, front-loading the metrics and use cases. While concise, it could be more structured by adding a brief usage note or parameter guidance without becoming wordy.

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 9 parameters (though only 1 required) and no output schema, the description is somewhat brief. It does not explain parameter dependencies (e.g., level determines required fields) or overall usage logic. The schema helps, but the description could be more 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 description coverage is 100%, so the schema already documents all 9 parameters. The tool description mentions 'US geography' but does not add per-parameter semantics beyond the schema. 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 description clearly states the specific metrics (labor force, unemployment, commute times, public transit, work-from-home rates) and the intended use cases (site selection, workforce analysis, commercial real estate). This distinguishes it from sibling tools like census_demographics and census_income_housing.

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 context on when to use (site selection, workforce analysis, commercial real estate) but does not explicitly state when not to use or mention alternative tools. It lacks explicit guidance on prerequisites or exclusions.

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 the tool read-only and idempotent. The description adds value by specifying the exact return fields (racial groups, ethnicity, median age) and source (ACS 5-year), going 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 two sentences long, front-loads the purpose, and includes key output details without any extraneous information. Every sentence is necessary.

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

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

The description explains the output fields and source, which is helpful given no output schema. However, for a tool with 9 parameters, more context on typical usage patterns could improve completeness.

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 parameters are well-described in the schema. The description adds no additional meaning to parameters beyond what is in the schema, meeting the baseline expectation.

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 returns race, ethnicity, and age breakdowns for US geographies, listing specific demographic categories. However, it does not explicitly differentiate from sibling census tools like census_population, which also provide demographic data.

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 guidance is provided on when to use this tool versus alternatives. The description does not mention when to choose census_demographics over other census tools or any exclusions.

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 idempotentHint=true, covering safety. The description adds input format nuances (state name/code, ZIP, substring matching) but does not mention return format, ambiguity handling, or upstream call behavior (though dry_run is in schema). This is adequate but not rich.

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

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

The description is two sentences, with the purpose front-loaded and every sentence providing relevant information. No filler or 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?

Given the good annotations and full schema parameter descriptions, the description covers the tool's purpose and usage context. It misses return format and edge-case behavior, but these are less critical for a lookup tool with a clear schema. Overall, it is complete enough 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 descriptions cover 100% of parameters, including examples for query and a clear description for dry_run. The description adds only the substring-matching nuance for states, which is a minor addition. Baseline 3 is appropriate since the schema already explains parameters well.

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 resource ('Census FIPS codes') and the action ('look up by name'), and explicitly distinguishes it from siblings by noting it produces codes needed by other census_* tools. This makes its role 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?

The description provides a clear use case: 'Use this to find the FIPS codes needed by other census_* tools.' It does not name alternatives or exclusions, but the context is sufficiently clear for an agent to know when to invoke this tool.

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 destructiveHint, so the description adds marginal value. It provides context on output fields (income, housing, rent) but does not disclose behavioral traits like pagination, error handling, or data recency beyond the schema.

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 has two succinct sentences. The first lists key data points, the second states use cases. No unnecessary words, and the essential information is front-loaded.

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

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

Given the tool has 9 parameters (most optional) and no output schema, the description covers the returned data and typical use cases. It does not explain geography level selection, but the schema descriptions cover that. It is sufficiently complete for a read-only tool with rich annotations.

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 description does not need to add parameter details. The description lists output fields but does not enhance understanding of parameters beyond the schema. It adds use-case context but not parameter semantics.

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 lists the specific data returned (median income, housing units, rent, etc.) and states the geography scope ('for a US geography'). It also differentiates from sibling census tools by focusing on income and housing, rather than demographics, business, or population.

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

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

The description implies usage for real estate and market analysis, but does not explicitly state when to use this tool vs. alternatives like census_demographics or census_commute_employment. There is no guidance on prerequisites or 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 indicate readOnlyHint, idempotentHint, and non-destructive nature. The description adds that it returns total, male, female, and median age, and mentions usage contexts. No additional behavioral traits beyond annotations, so description adds moderate value.

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 sentences: purpose, output, use cases. Information is front-loaded and concise with no extraneous content. Every sentence 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?

Given the tool has no output schema, the description provides essential information about return fields (total, male, female, median age). Schema covers parameters well. A brief mention of wildcard support would improve completeness, but the description adequately prepares an agent for 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 has 100% description coverage for all 9 parameters. The description lists geography levels and return fields but does not add significant extra meaning beyond the schema's parameter descriptions. 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?

Description clearly states the verb 'Get', the resource 'total population for a US geography', and lists specific geography levels. It returns specific fields (total, male, female, median age) and mentions use cases like market sizing, which distinguishes it from sibling census tools like census_business or census_demographics.

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?

Description explicitly lists when to use the tool (for population data at various geography levels). It provides clear context but does not explicitly state when not to use it or name alternative tools for other census data.

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 the aggregation behavior and facet options but does not disclose additional traits like rate limits or return size. 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 a single concise sentence with a colon separating purpose from examples. No unnecessary words, front-loaded with the main action.

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

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

The description covers the core functionality and provides examples. However, without an output schema, it does not describe the return format. Given the tool's simplicity, the description is largely 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?

Schema description coverage is 100% with each parameter documented. The description adds usage context (e.g., 'ranking companies') but does not enhance the semantic meaning beyond the schema enums and 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?

The description clearly states the tool aggregates complaint counts by a single facet, listing the six allowed fields. Examples of use cases (ranking companies, finding common issues) distinguish it from sibling tools like cfpb_complaint_detail or cfpb_complaint_trends.

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 clear context for when to use this tool (aggregation, ranking) but does not explicitly exclude cases or compare to alternatives. It gives practical examples but lacks 'when not to use' 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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds context about returning the full record including narrative if consented, which is useful but not extensive. No further behavioral details like pagination or rate limits are disclosed.

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 a single sentence of 15 words that front-loads the core action and includes return information. Every word is earned; no unnecessary content.

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 read-only tool with full parameter documentation in schema and annotations covering safety, the description is adequate. It covers purpose and key return behavior, though it does not mention the dry_run parameter or optionality, which are in schema.

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% with clear descriptions for both parameters (complaint_id, dry_run). The tool description mentions complaint_id but adds no new information beyond what the schema already provides. Baseline of 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 description clearly states 'Fetch a single CFPB complaint by complaint_id' with a specific verb and resource, and distinguishes itself from sibling CFPB tools (aggregations, trends, search) by focusing on a single record lookup.

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

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

The description implies usage when a complaint_id is known and a single record is needed, but does not explicitly mention alternatives like cfpb_search_complaints or cfpb_complaint_aggregations. Guidance is implicit 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds context about the lens options and interval but doesn't disclose additional behavioral traits such as default date ranges, result format, or pagination. It neither contradicts annotations nor provides rich behavioral detail beyond them.

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

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

The description is two sentences and front-loaded with the core purpose. Each lens mapping is concise and informative, with no wasted words. It efficiently packs the key parameter guidance into a compact structure.

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

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

The description covers the main lens and interval parameters, while the schema handles optional filters like product, sub_lens, and date ranges. There is no output schema, but the tool's purpose as a time-series trends tool makes the expected return type reasonably predictable. It lacks explicit mention of defaults (e.g., trend_depth, date range) but the schema provides those. Overall, it is sufficiently complete for a read-only trends 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 description coverage is 100%, so the baseline is 3. The description adds meaningful value by explaining what each lens shows (total complaints, by product, etc.) and confirming the interval options, which goes beyond the schema's terse 'Trend dimension' and 'Time bucket size'. This helps the agent understand the parameter semantics more concretely.

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 'Time-series trends of complaint volume' with a specific resource and action. It explains the lens options (overview, product, company, issue) which helps distinguish it from other CFPB tools, though it doesn't explicitly name alternatives. The purpose is unambiguous and useful for an agent.

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 guidance is provided on when to use this tool versus sibling tools like cfpb_complaint_aggregations or cfpb_search_complaints. The description only details lens parameter behavior, not the broader context for tool selection. There are no exclusions or alternative recommendations, leaving the agent to infer usage from the name and description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond this: the database size and time range (4M+ since 2011), and the caveat that narratives are public only 'when available,' which is useful behavioral nuance. 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 two sentences, front-loaded with the core action ('Search the CFPB Consumer Complaint Database'), followed by filter types and return value. No redundant words; every word 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?

For a search tool with 10 parameters and no output schema, the description is reasonably complete: it states the dataset scope, filter capabilities, and response nature. It does not explain pagination behavior or the dry_run parameter, but those are covered in the schema. Overall, sufficient but not exhaustive.

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 summarizes filter options but does not add new semantic detail beyond what each parameter's description already provides. It does not clarify relationships between params (e.g., ranges must be YYYY-MM-DD) or mention pagination defaults, which are in 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 the tool searches the CFPB Consumer Complaint Database, names the key filter dimensions (free-text, company, product, state, date range, narrative-presence), and describes the return content (metadata plus public narratives). It is specific in verb and resource, but it does not explicitly contrast with sibling CFPB tools like cfpb_complaint_aggregations or cfpb_complaint_detail.

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

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

The description implies usage for searching/filtering complaints but gives no explicit guidance on when to prefer this tool over siblings (e.g., aggregations, trends, detail, suggest_company). It does not mention exclusions or prerequisites, so it is minimally adequate but lacks clear contextual direction.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that the tool returns counts and percentages, but does not detail output structure or potential limitations like data freshness.

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

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

The description is two sentences: the first states the core functionality, the second provides a practical use case. No extraneous information; every word 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?

Given no output schema, the description explains the return type (counts and percentages per state). It is fairly complete for a simple read-only tool, though it could clarify whether all states are included or only those with complaints.

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% with descriptions for all four parameters. The description only paraphrases 'optional product filter and date range' without adding new semantic information beyond what the schema provides.

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 returns complaint counts and percentages per US state with optional filters, distinguishing it from sibling tools like cfpb_complaint_detail or cfpb_complaint_trends which handle other aggregations or 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?

The description suggests use for state-level risk maps, providing clear context for when to use this tool. However, it does not explicitly exclude other tools or mention 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 indicate read-only, idempotent, non-destructive behavior. The description adds the return limit (up to 10 suggestions) but does not detail the format of suggestions.

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 efficient sentences that front-load the purpose and immediately provide usage context with no waste.

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 autocomplete tool with comprehensive annotations, the description covers purpose, return limit, and usage context. Lacks output format details but adequate.

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. The description adds no additional meaning beyond what the schema already states for 'text' (partial company name) and 'dry_run'.

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 auto-completes company names and returns suggestions, which distinguishes it from sibling tools like cfpb_search_complaints that perform full searches.

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 tells the agent to use the results as exact values for cfpb_search_complaints' company parameter, providing clear when-to-use guidance and a specific 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?

Beyond annotations (readOnly, idempotent, etc.), the description adds value by detailing behavior: it resolves the compound, returns signal word and hazard statements, handles missing data gracefully, and clarifies the data is informational from a free public source. 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 front-loaded with purpose and is efficiently structured. Every sentence adds value, though it could be slightly more concise. Still, no fluff or redundancy, and it fits in a few clear 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?

Given no output schema, the description adequately explains return values (signal word, hazard statements) and error handling (graceful reporting when no classification). It also notes data source and limitations, making it self-contained for a simple lookup 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% with both parameters described. The description adds slight context (e.g., 'chemical name or PubChem CID' for query, and a brief explanation for dry_run) but mostly restates schema info. Baseline 3 is appropriate since schema does heavy lifting.

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 returns GHS hazard classification for a chemical from PubChem, using specific verbs ('Return') and resource ('GHS hazard classification') with data source and purpose. It distinguishes from sibling tools like 'chemical_lookup' by focusing on GHS classification specifically.

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

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

The description implies when to use (given a chemical name or CID) and provides a caveat about verifying against an SDS, but does not explicitly mention when not to use or compare to alternative tools like 'chemical_lookup'. Usage guidance is implicit and lacks exclusionary context.

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

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

The description adds value beyond annotations by specifying the data source (NIH/NLM PubChem) and that it is keyless and public-domain. Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. No contradictions.

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

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

The description is two sentences with no wasted words. It front-loads the action and key outputs, making it efficient and scannable.

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 read-only tool with 2 parameters and no output schema, the description covers purpose, inputs, outputs, data source, and use case. It does not mention pagination or rate limits, but these are not critical given the keyless public data.

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% with descriptions for both parameters. The description adds meaning by explaining that the 'query' can be a chemical name or numeric PubChem CID, and implicitly explains 'dry_run' via its schema description. This goes beyond the schema's built-in description.

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 resolves a chemical name or PubChem CID to core identity and physical properties, listing specific outputs (CID, IUPAC name, molecular formula, molecular weight, SMILES). It distinguishes itself from siblings like 'chemical_hazards' by focusing on identity and properties.

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 states the tool should be used to disambiguate a substance and obtain a stable CID join key for further chemistry or safety lookups. While it doesn't mention when not to use or alternatives, the context is clear and sufficient.

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 (readOnlyHint, etc.), the description details joining three public sources, heuristic specialty mapping with override, graceful degradation, and the return format (readable brief with banding). This provides rich behavioral insight without contradictions.

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 front-loaded with the core purpose in the first sentence. Subsequent sentences add necessary detail without excessive verbosity. A small amount of redundancy could be trimmed, but overall it is well-structured.

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

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

Given no output schema, the description adequately explains the return format (readable brief with trial activity banding and specialist availability) and failure handling. It covers key aspects for an agent to understand tool output and behavior.

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 has 100% description coverage, so baseline 3. The description adds value by explaining that 'condition' maps to specialty heuristically and that 'specialty' overrides it, and that 'dry_run' validates the call. These details enhance understanding 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 explicitly states the tool combines clinical trial activity and specialist availability for a medical condition in a US geography, using a single call. It clearly distinguishes from sibling tools like trials_search or npi_lookup by emphasizing the synthesis of multiple data sources for site-feasibility analysis.

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 defines the target user (trial sponsor, CRO, feasibility analyst) and the question it answers. It explains that sources degrade gracefully and failures are noted. While it doesn't explicitly list when not to use it, the context is clear enough for an agent to infer appropriate scenarios.

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 destructiveHint=false, so the safety profile is well-established. The description adds context about return fields but does not disclose other behaviors like pagination defaults, data freshness, or rate limits. Given annotation coverage, this is adequate but not rich.

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

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

The description is two sentences: the first states the action and target, the second lists the return fields. There is no redundant information, and it front-loads the primary 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?

For a straightforward read-only search tool with complete schema descriptions and safety annotations, the description covers the core functionality and expected output. It does not mention pagination or data source details, but the schema fills those gaps; a slightly richer description could note that data comes from a public CMS dataset, but the current version is functional.

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?

All five parameters (limit, state, offset, dry_run, name_contains) have descriptive schema entries, yielding 100% coverage. The description itself does not add parameter-specific meaning beyond the schema, 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?

The description clearly states the action ('Search') and the specific resource ('Medicare-certified home health agencies') with the authoritative source ('CMS Home Health Compare'). It also enumerates the primary return fields (agency name, address, services, quality ratings), which unambiguously differentiates it from sibling tools like cms_hospital_search or cms_nursing_home_search.

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

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

The description implies when to use the tool by targeting a specific entity type, which contrasts with sibling CMS search tools. However, it does not explicitly name alternatives or state when not to use it, so there is clear context but no explicit exclusions.

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 destructiveHint=false, which covers the safety profile. The description adds what fields are returned but does not disclose behavioral aspects like pagination behavior, rate limits, or data freshness. It does not contradict annotations, and the added context is modest but not rich.

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

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

The description is two sentences long, front-loaded with the primary action and resource, and includes the key return fields without any filler. Every sentence contributes to understanding the tool's 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?

For a simple search tool with good annotations and a fully documented schema, the description adequately covers the core functionality and output categories. It does not detail return structure or pagination, but those are partially visible in the schema and not critical for a read-only lookup tool. Slightly more detail on response shape would improve completeness, but it is 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 input schema has 100% description coverage, with all five parameters individually described (limit, state, offset, dry_run, name_contains). The tool description adds no additional parameter semantics beyond the schema, 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?

The description clearly states the tool searches Medicare-certified hospice agencies from CMS Hospice Compare, which is a specific verb+resource. It also distinguishes from sibling tools by specifying hospice agencies vs. home health, hospital, or nursing home. The return fields (provider name, address, ownership, quality measures) further clarify the purpose.

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 clear context by specifying the data source (CMS Hospice Compare) and the topic (hospice agencies), making it obvious when this tool would be used. However, it does not explicitly mention when not to use it or reference alternative tools like cms_hospital_search, so it stops short of full exclusion/alternative 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 readOnly, openWorld, idempotent, and non-destructive behavior, lowering the burden. The description goes beyond annotations by specifying the returned fields and filter behavior (state, city, partial name match). It does not mention pagination defaults or rate limits, but those are partly covered by schema descriptions.

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 focused sentences, front-loaded with the action and data source, and no filler. Every sentence contributes to understanding the tool's purpose and capabilities.

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 optional-parameter search tool with complete schema coverage and strong annotations, the description is sufficient. It explains what the tool does, what it returns, and how to filter, which is enough for an agent to select and invoke it 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?

All 6 parameters are fully described in the schema (100% coverage), including defaults and semantics of dry_run. The description essentially restates that filtering by state, city, and partial name is possible, adding no new meaning beyond the schema's parameter 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?

The description clearly states the tool searches 'Medicare-certified hospitals from the CMS Hospital General Information dataset' and lists the returned fields (facility name, address, ownership type, emergency-services flag, star rating). This specific verb+resource combination distinguishes it from sibling tools like cms_home_health_search or cms_hospice_search.

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

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

The description clearly implies when to use it (searching for hospitals by state, city, or partial name), but it does not explicitly discuss alternatives or exclusion criteria relative to sibling CMS search tools. The resource specificity makes the context clear, but explicit guidance is missing.

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 mark this as read-only, idempotent, and non-destructive; the description adds behavioral context by enumerating return fields (name, address, ownership, certification status, total beds, quality measures), which helps the agent set expectations. No contradiction detected.

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 concise sentences, front-loaded with the main action, no redundant wording.

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 adequately specifies return content. The optional filter parameters are fully covered in the schema, and the tool's complexity is low. It could mention dry_run/pagination but that is documented in the schema.

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

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

The schema provides 100% coverage with descriptive parameter explanations. The description adds no specific parameter guidance but sets overall context for the search. Baseline of 3 is appropriate given schema completeness.

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 searching for Medicare-certified nursing homes from CMS Nursing Home Compare, with a specific verb and resource. This distinguishes it from sibling CMS search tools (hospital, home health, hospice) by explicitly stating 'nursing homes'.

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

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

The description implies usage for nursing home data, but does not explicitly mention alternatives or exclusions. Still, the domain is clear, giving sufficient context for an agent to select this tool when caring for nursing home information.

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 context about DAPIP publication but doesn't disclose behavior beyond annotations (e.g., no mention of data freshness or pagination).

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?

Single sentence efficiently lists what the tool returns. Front-loaded with 'accreditation status'. Slightly dense but no wasted words.

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 lookup tool with no output schema, the description adequately conveys expected return fields (status, accreditor, last action date, programmatic accreditations). Sufficient for an agent to understand the tool's output.

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% with clear descriptions for both 'dry_run' and 'unit_id'. The description adds no additional parameter meaning 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 specifies the tool provides 'current institutional accreditation status, accreditor, and (when published by DAPIP) last action date and programmatic accreditations.' It distinguishes from sibling college tools by focusing on accreditation 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?

No guidance on when to use this tool versus alternatives (e.g., college_search, college_metrics). No prerequisites or exclusions mentioned; usage context is implied but not 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the requirement to pass UNITIDs and the 2-5 school range, but does not disclose return format, data sources, or other behavioral traits. This is adequate but not rich.

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

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

The description is two short sentences, front-loaded with the core purpose and ending with a direct instruction. Every word earns its place—no redundancy or fluff.

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 comparison tool with strong annotations and a clear description, this is nearly complete. The absence of an output schema is somewhat compensated by the metric categories listed, which imply the return content. A slight gap remains around the exact output structure, but the tool is not complex enough to require more.

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 unit_ids and dry_run both described. The description's 'Pass UNITIDs' simply restates the schema's unit_ids field and adds no new meaning beyond 'cost, outcomes, and admissions metrics,' which describes the comparison scope rather than parameter semantics.

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

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

The description states the tool performs a 'side-by-side comparison of 2-5 schools across cost, outcomes, and admissions metrics,' which is a specific verb+resource+scope. It clearly distinguishes itself from sibling tools like college_metrics or college_search by emphasizing comparison and listing the metric categories.

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 instruction 'Pass UNITIDs' gives a clear prerequisite and the phrase '2-5 schools' indicates the intended use case for multi-school comparisons. However, it does not explicitly name alternatives or when not to use this tool, so it falls short of a full 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 already convey read-only, idempotent, and non-destructive behavior. The description adds that it returns specific demographic categories but does not disclose any additional behavioral aspects such as data source or response structure.

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

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

The description is a single concise sentence that efficiently communicates the tool's purpose and data content without extraneous 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?

Despite lacking an output schema, the description lists the demographic categories returned, which is reasonably complete for a simple read tool. It could be enhanced by mentioning the format (e.g., counts or percentages).

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% with both parameters described. The description does not add information about parameters beyond the schema, listing only output content. Baseline score of 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 description explicitly states the tool retrieves student-body demographics for one school, listing specific categories (race/ethnicity, gender, age, geographic origin). This clearly distinguishes it from sibling tools like college_metrics or college_accreditation.

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

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

The description implies usage for obtaining demographic breakdowns for a single school based on the listed categories. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusion 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering core behavioral traits. The description adds value by listing specific metrics but does not disclose additional behavioral details like authorization needs or response format.

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 a single concise sentence that front-loads the purpose and lists metrics efficiently. Every word adds value with no 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?

For a straightforward read-only metrics tool with two parameters and annotation coverage, the description adequately covers the output content. However, it lacks details on response format or potential errors, which would enhance completeness.

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 parameters are well-documented structurally. The tool description does not add any additional parameter semantics beyond the schema, maintaining the baseline score.

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 'cost and outcome metrics for one school' and lists specific metrics, making the purpose explicit. However, it does not explicitly differentiate this tool from sibling tools like college_compare or college_demographics, which offer related college data.

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 guidance is provided on when to use this tool versus alternatives. Given many sibling college tools, the description should indicate context for selection, such as comparing multiple schools or demographic focus.

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 mark the tool as readOnly and idempotent. The description adds context about the specific data returned (median earnings, debt, award counts), which is beyond the annotation hints. 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 a single, front-loaded sentence with no wasted words. It efficiently captures the tool's scope and data outputs.

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

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

The description mentions '4-digit CIP code' but the input schema only requires a school ID (unit_id), omitting a CIP code parameter. This mismatch makes the description incomplete. While it does explain return values well (earnings, debt, awards), the missing input parameter is a significant 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%, so both parameters (dry_run, unit_id) are already described. The tool description does not add new meaning beyond the schema. Baseline score of 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 description clearly states it provides program-level outcomes (median earnings, debt, award counts) for one school. This distinguishes it from sibling tools like college_metrics or college_demographics, which cover different scopes. However, the mention of '4-digit CIP code' is ambiguous—it suggests an input parameter that does not exist in the schema, slightly reducing clarity.

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

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

The description implies this tool is for detailed program-level data for a specific school, contrasting with broader tools like college_search or college_trends. It does not explicitly state when to use it over alternatives, but the context of sibling tools makes the scope clear.

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 idempotentHint=true. Description adds return information but no additional behavioral traits like rate limits or error handling. No contradictions.

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 action and searchable fields, then return fields. No extraneous 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?

Adequate for a search tool: describes inputs and outputs. Lacks mention of pagination behavior despite limit parameter, but schema covers that. Without output schema, return fields are listed.

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 detailed parameter descriptions. Description only summarizes searchable fields without adding new meaning beyond 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?

Description uses specific verb 'Search' and resource 'US colleges and universities', listing searchable fields and return fields. It clearly distinguishes from sibling college tools like college_compare or college_demographics.

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?

Implied usage: when searching by criteria. Does not explicitly state when not to use or mention alternative sibling tools like college_compare, college_demographics, etc.

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 show readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the data source (Urban Institute IPEDS) and available metrics, providing useful context beyond 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?

Single sentence, no wasted words. Front-loaded with purpose and key details.

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 high schema coverage, good annotations, and no output schema, the description suffices. It specifies metrics and year range, making the tool's functionality complete for its 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%, with descriptions for all parameters. The description mentions metric and year range but doesn't add meaning beyond the schema. It does clarify the trend concept, but 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 description clearly states it provides multi-year trends for one school from IPEDS, listing specific metrics (enrollment, graduation_rate, retention, cost). This distinguishes it from sibling tools like college_metrics (single-year) or college_compare (comparison).

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 explains the tool is for trend analysis over a year range with chosen metric. While it doesn't explicitly exclude alternatives, the context is clear enough for appropriate use.

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

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

The description adds significant value beyond annotations. It explains the data joining process (College Scorecard + BLS), the nature of the output (rating with itemized evidence), and highlights limitations (data lags, only federally-aided students). No contradiction with annotations (readOnlyHint, etc.).

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 fairly long but well-structured: it starts with the core purpose, then details the data sources, output, and limitations. It is front-loaded and every sentence adds value. Could be slightly more concise, but it earns its length.

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

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

Given the complexity of the tool (multiple data sources, no output schema) the description is complete. It explains the output rating, the evidence breakdown, and the handling of failing sources. Annotations further clarify read-only and idempotent behavior.

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 context by explaining the effect of the optional `program` parameter and the role of `dry_run` for validation. It reinforces parameter purpose but does not add extensive new detail 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?

The description clearly states the tool's purpose as a 'one-call' read assessing whether a US college degree is worth the cost. It specifies the data sources and the output rating (STRONG VALUE, FAIR, etc.), distinguishing it from sibling tools like college_search or college_metrics which likely provide raw data without synthesis.

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 good context on usage: it's a read-only tool for evaluating college value, with optional program-specific analysis. It also warns that it's informational only, not advice. However, it does not explicitly compare to alternatives or specify when not to use it (e.g., for non-US colleges).

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

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

The description discloses behavioral traits beyond annotations: it details the three data sources, specifies that a failed leg is noted but not fatal, describes the returned risk level (LOW/MODERATE/ELEVATED), and states it is informational public-record synthesis, not legal advice. Annotations already mark readOnlyHint=true, and description 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 front-loaded with the main purpose and structured clearly. It is relatively long but each sentence adds value by explaining legs, alternatives, and limitations. Could be slightly more concise, but no extraneous 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?

Given the tool's complexity (multi-source aggregation) and the absence of an output schema, the description fully covers what the tool does, what it returns, when to use alternatives, and limitations. It provides all necessary context for an agent to decide to invoke it.

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 documentation coverage is 100%, so baseline is 3. The description adds context by explaining how parameters like 'since' (for FDA recalls) and 'state' (for CFPB scope) relate to the tool's legs, providing integration-level meaning beyond the schema descriptions. However, dry_run is not elaborated in the description, though the schema description is clear.

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 is a 'CONSUMER-RISK read' for a company or brand, led by the consumer-complaint picture. It explains the three data legs (CFPB, recalls, litigation) and explicitly distinguishes it from sibling tools like product_liability_screen and recall_screen, providing specific differentiation.

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 explicit guidance on when to use this tool (for consumer-complaint-centered risk) and when not to use it (NHTSA vehicle recalls out of scope, directing to recall_screen). It also names an alternative (product_liability_screen) for recall/litigation-centered 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no behavioral details beyond listing return fields, so it provides minimal additional transparency.

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 concise and front-loaded with the purpose, followed by a list of returned data and usage examples. It is effective without being verbose.

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

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

The description enumerates many return fields (sector, industry, revenue, etc.), providing a good understanding of the output. Without an output schema, this is fairly complete for a data retrieval 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 is fully described in the schema itself (100% coverage). The description does not add any new semantic information about the parameters, 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 description clearly states the tool's purpose: 'Get company profile and financial fundamentals.' It lists the specific data returned and provides example queries, making it easy to understand what the tool does.

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 example queries like 'tell me about Apple' and 'company financials', giving clear usage context. However, it does not explicitly state when not to use this tool or mention alternatives 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?

The description thoroughly explains the tool's behavior: lists data sources (OFAC, SEC, USAspending, EPA), describes verdict bands, and clarifies that failures are noted but not fatal. Annotations already mark it as read-only, idempotent, and non-destructive; the description adds rich context beyond 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 moderately long but well-structured, front-loading the purpose and then detailing sources, verdicts, and disclaimers. Each sentence adds value, though some redundancy could be trimmed.

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