livedatalink

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

No annotations are provided, so the description carries full burden. It explicitly states the return values (US AQI, PM2.5, etc.) and health category rating, providing sufficient transparency for a read-only query tool without side effects.

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 one sentence that lists the returned data, followed by a list of example queries. It is front-loaded with the tool's purpose and is highly concise with no redundant 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 simplicity (one parameter, no output schema), the description fully covers what the tool does, what data it returns, and when to use it. No additional information is needed.

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 single parameter 'location' is described as 'City, zip code, or place name' in the schema. The description adds value by showing example queries that demonstrate valid inputs, going beyond the schema's bare 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 it retrieves current air quality data for any location, listing specific pollutants and health ratings. It is distinct from siblings which focus on topics like colleges, courts, or weather.

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 list of example queries that indicate when to use this tool (e.g., 'what's the air quality?'). While it does not explicitly state when not to use it or mention alternatives, the examples strongly imply appropriate contexts.

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

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

With no annotations, the description carries full burden. It states 'Returns a monthly time series' and 'Keyless official BLS data', but does not disclose data range, update frequency, or any limitations. Adequate but minimal.

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 plus a list of indicators. Efficient and front-loaded with purpose. Slightly more verbose due to listing indicators, but avoids unnecessary detail.

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 data retrieval tool with 3 parameters and no output schema, the description covers the return type (monthly time series) and data source. Missing details like data start year, but overall adequate for typical 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% with clear descriptions for all three parameters. The description's mention of indicators and suggestion of date range adds little 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 it provides US labor & price statistics from the Bureau of Labor Statistics using friendly names, listing all available indicators and noting it returns monthly time series. This distinguishes it from the sibling bls_series tool which uses series IDs.

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 for common BLS indicators by name, but does not explicitly state when to use this versus bls_series or provide exclusions. The context is adequate but not directive.

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?

No annotations provided, so description must carry full burden. Only states 'Fetch any BLS time series' without disclosing rate limits, error handling, data freshness, or return format. Lacks critical behavioral details.

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, 28 words, no redundancy. Front-loaded with the primary action and includes an example. Highly efficient.

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

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

No output schema; description does not indicate return format (e.g., time series data points). Partially complete for a simple lookup but lacks details on what the response contains. With 3 parameters and no output schema, more context is warranted.

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 all parameters described. Description adds an example series ID and context but does not significantly augment 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?

Clearly states the tool fetches a BLS time series by its raw series ID, with an example (LNS14000000). Distinguishes itself from potential siblings like bls_indicator by specifying usage when the exact ID is known.

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 a usage condition: 'For when you know the exact BLS series ID.' Implies alternative tools for when ID is unknown, but does not explicitly mention siblings or list when-not-to-use 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?

No annotations provided, so description carries full burden. It discloses the fields returned but does not mention error behavior (e.g., when ID not found), rate limits, or whether it is read-only (implied). Basic transparency is present but not exhaustive.

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 of 23 words, front-loaded with purpose, then parenthetical list of fields. No filler, highly efficient.

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

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

Given the tool's simplicity (1 param, no output schema), the description adequately covers what the tool returns. It lists many metadata fields but omits structural details (e.g., types, nesting) and error handling. Still, it is mostly complete for a 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%, so the parameter description in schema already explains 'gutenberg_id'. The tool description repeats 'by its Project Gutenberg id' without adding new semantics. 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 verb 'Get' + resource 'full catalog metadata for a single book by its Project Gutenberg id', listing specific fields (title, authors, etc.). This distinguishes it from sibling tools like book_search (search multiple) and book_get_text (get 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?

Implies usage when you have a Gutenberg ID and need metadata. However, no explicit guidance on when to use this over book_search, book_status, or other book-related tools. Alternatives are not 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?

No annotations are provided, so the description carries full behavioral disclosure burden. It explains the return format (passages with title, author, snippet) and mentions default/max limit, but lacks details on rate limits, error handling, or behavior for missing queries.

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, efficiently conveying the core functionality and optional restriction. It is front-loaded and every sentence adds value, though a bulleted structure could improve scanability. Still, very 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 tool's moderate complexity, the description adequately explains input (query, limit, optional gutenberg_id) and output (passages with metadata). No output schema exists, but the description compensates by stating the return format. Edge cases are not addressed, but overall completeness is high for a search tool.

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

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

The input schema has 100% coverage, but the description adds value by clarifying that query is a phrase or keywords, and that gutenberg_id restricts to a single book. It also explicitly ties parameters to the output (passages with book title, author, snippet), enhancing understanding beyond schema alone.

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

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

The description clearly states that the tool searches inside books for phrases/keywords and returns passages with book title, author, and snippet. It distinguishes itself from sibling tools like book_search (metadata search) and book_get_text (full text) by focusing on internal content search with snippet results.

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 positions this as the 'headline feature' for finding passages across books, but does not explicitly state when to avoid using it or compare with similar sibling tools like paper_fulltext_search or caselaw_opinion_text. Guidance is implied but not comprehensive.

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

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

With no annotations, the description discloses key behaviors: pagination mechanism, fallback URL for unindexed books, and the source (Gutenberg). It does not mention error handling or rate limits, but covers the main operational aspects.

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 succinct sentences deliver all necessary information without repetition. Every word serves a purpose.

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

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

Given no output schema, the description explains the two types of returns (full text or URL). Covers pagination and fallback. Could mention output format but is sufficient 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% with clear descriptions for each parameter. The description reinforces pagination usage but adds little beyond the schema. 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?

Clearly states the tool returns full text of an indexed book by Gutenberg ID with pagination, and specifies fallback behavior for non-indexed books. Distinguishes from sibling tools by focusing on text retrieval rather than metadata or 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?

Provides explicit instructions for pagination using from_seq and max_passages, and explains fallback to a plain-text URL for non-indexed books. While it doesn't explicitly say when not to use, the guidance is clear and actionable.

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

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

With no annotations provided, the description must disclose behavioral traits. It does well by explaining the live nature of the search, ranking by relevance then popularity, and the exact return fields. However, it omits rate limits or authentication requirements, though these are likely not applicable.

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 with four focused sentences. It front-loads the core search capability, then adds ranking and return details, and ends with a usage guideline. No unnecessary 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?

Given no output schema, the description lists return fields (Gutenberg id, title, author(s), language, download count) which is helpful. It also mentions catalog size and live data. It could mention the default limit, but the schema covers that.

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

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

The input schema already provides detailed descriptions for all 5 parameters (100% coverage). The description adds that ranking is by relevance then popularity, which provides context beyond the schema, but does not significantly enhance parameter 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 that this tool searches the full Project Gutenberg catalog live via Gutendex by keyword, with optional filters. It distinguishes itself from the sibling tool book_fulltext_search by explicitly directing users to that tool for full-text 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 explicitly provides guidance on when to use an alternative: 'Use book_fulltext_search to search inside the locally indexed top books.' This helps the agent choose between similar 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?

No annotations exist; description discloses the tool returns catalog source info and corpus counts. However, it doesn't mention performance, freshness, or any side effects. Adequate but not highly transparent.

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, well-structured sentence that front-loads the verb and purpose. No unnecessary 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?

Given no parameters and no output schema, the description adequately explains what the tool returns. Missing output format details, but sufficient for agent understanding.

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

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

The tool has zero parameters; baseline is 4. No additional parameter info needed 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 tool reports the books store status, specifying components (Gutendex catalog and D1 indexed-corpus counts). It distinguishes from sibling tools like book_search or book_details which are for specific book queries.

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?

Usage is implied for status overview, but no explicit when-to-use or alternatives are mentioned. With many sibling tools, more guidance would help.

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?

No annotations are provided, so the description carries the full burden. It mentions 'Keyless' (no auth needed) and lists output fields, but does not explicitly state that the tool is read-only or non-destructive, nor does it discuss rate limits or data freshness. For a simple lookup, the behavioral disclosure is minimal.

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 purpose and key output fields. Every word is necessary; no redundancy or filler. Ideal conciseness.

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 low complexity (1 parameter, no output schema, no nested objects), the description is fairly complete. It lists the expected return fields (version, description, downloads, etc.) which compensates for the missing output schema. Minor gap: no mention of error handling or case sensitivity of the crate name.

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% (the only parameter 'name' is fully described). The description adds no extra meaning beyond the schema—it merely repeats the lookup purpose. Baseline score of 3 is appropriate as the schema already provides adequate parameter documentation.

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 'Look up' and the resource 'Rust crate on crates.io', listing specific fields returned (version, downloads, etc.). It distinguishes itself from sibling package tools like npm_package by explicitly targeting Rust crates.

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 Rust crate lookups but does not provide explicit guidance on when to use this tool versus alternatives (e.g., npm_package, pypi_package). No exclusions or prerequisites 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?

No annotations are provided, so the description must convey behavioral traits. It uses 'Get' which implies a read-only operation, and lists the metadata returned, suggesting no side effects. However, it does not explicitly confirm it is safe, idempotent, or clarify 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 a single, well-structured sentence of about 20 words. It is front-loaded and contains no superfluous information, earning 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 the tool's low complexity (one required parameter, no output schema), the description lists the fields returned and the identifier. It does not specify the format (e.g., JSON) or error conditions, but it is largely sufficient for an agent to understand and invoke the tool.

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

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

The input schema covers the single parameter 'id' with a description and example. The schema description coverage is 100%. The tool description merely reiterates the role of the CAP id and lists return fields, adding minimal 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 states the action ('Get'), the resource ('full metadata for a single case'), and the identifier ('CAP id'). It distinguishes this tool from siblings like caselaw_search or caselaw_opinion_text by focusing on retrieving metadata for a specific case.

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

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

The description implies use when you have a CAP id, but does not explicitly state when not to use it or provide alternatives. It mentions the fields returned, which helps contextualize its use, but lacks direct guidance on tool selection.

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

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

No annotations are provided, so the description carries the full burden. It states it returns case metadata including CAP id but does not disclose error handling, rate limits, or authentication requirements.

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 action and examples, with no redundant information. Every part 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 simple tool with one parameter and no output schema, the description covers the core function and hints at output structure (CAP id). It could mention more about the full return value, but it's sufficient for most use cases.

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% (one parameter described). The description adds example citations and mentions parallel citations, but this adds limited value beyond the schema's 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 reporter citation to its case, with examples of citations. It distinguishes from sibling tools like caselaw_search and caselaw_opinion_text by focusing on citation resolution.

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 (when you have a citation) but does not explicitly state when not to use it or provide alternatives. It lacks explicit guidance on trade-offs.

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?

No annotations are provided, so the description carries the full burden. It discloses that text is retrieved live from a static mirror (not stored) and includes each opinion with author. But it lacks details on error handling, rate limits, or response format, which are important for a read tool with no output 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 is three concise sentences, front-loaded with the core purpose, followed by behavioral and parameter guidance. No extraneous information; 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?

The tool has no output schema and no annotations. The description covers source, content, and max_chars, but does not describe the response format (e.g., plain text vs JSON) or handle edge cases. For a simple retrieval tool, it is adequate but not fully 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 schema coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema, only reiterating the use of max_chars to bound response. No new semantic info is provided.

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 fetches opinion text for a given CAP id, distinguishes from siblings like caselaw_case_details (metadata) and caselaw_search (finding IDs). It is specific and aligned with the tool name.

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

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

The description implies usage when you have a CAP id from caselaw_search or caselaw_citation_lookup and mentions using max_chars to bound response. However, it does not explicitly state when not to use or contrast with siblings, leaving some room for ambiguity.

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?

No annotations are provided, so the description carries the full burden. It discloses the scope limitation (v1 index covers U.S. Reports) but does not cover rate limits, authentication, or details about the return structure beyond metadata.

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 plus a short note, front-loaded with purpose and followed by output and usage guidance. No filler or redundant 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 6 parameters, no required ones, and no output schema, the description adequately explains what it returns (metadata with IDs and citations) and the index scope. It is complete for a search tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds concrete examples (e.g., 'Brown Board Education', 'Supreme Court') and clarifies ISO date format, going 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 searches US court opinions by case name/keyword, court, jurisdiction, and date range, returning metadata with IDs and citations. It distinguishes itself from the sibling caselaw_opinion_text by indicating it returns IDs for 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 advises using caselaw_opinion_text with returned IDs, but does not explicitly contrast with other court search siblings or state when not to use this tool. The scope note (v1 index covers U.S. Reports) provides useful contextual 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?

No annotations are provided, so the description bears the full burden of behavioral disclosure. It mentions the tool accepts a Socrata ID and where-clause but does not indicate whether it is read-only, any rate limits, response size, or query safety. The description is insufficient for safe agent use.

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 and a link, no fluff. The key purpose and fallback role are front-loaded. Very efficient.

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

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

The description explains purpose and usage, but lacks details on return format, parameter defaults, or examples. For a generic query tool with no output schema, more context would be beneficial, but it covers the essentials.

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 has a description. The description adds context for 'dataset' (4x4 Socrata ID) and 'where' (SoQL where clause), but other parameters are only described in the schema. The description adds marginal value beyond the schema.

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

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

The description clearly states it is a generic SoQL query tool for any CDC dataset, and explicitly positions it as a fallback when curated tools don't fit, which distinguishes it from the many sibling 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?

Explicitly states 'Use this when none of the curated tools fit', providing clear context. A link to SoQL reference is included, but there is no direct guidance on when not to use it or mention of alternative 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?

No annotations provided, so description carries full burden. Mentions '12-month rolling counts' as a behavioral trait, but does not disclose whether the tool is read-only, idempotent, or any rate limits. Since it's a data query tool, safety profile is implied but not explicit.

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

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

Three short sentences, each with distinct value: data source, temporal aggregation, and use cases. No fluff, front-loaded with essential info.

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 3 optional params and no output schema, the description covers purpose, key feature (rolling counts), and use cases. Missing details on output format or pagination, but adequate for a simple query 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 clear parameter descriptions. The tool description does not add 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?

Clearly states the tool retrieves CDC drug overdose deaths by state and indicator, with 12-month rolling counts. It differentiates from sibling CDC mortality tools like cdc_leading_causes_of_death by focusing on overdose deaths and mentioning state/indicator filters.

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

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

Provides explicit use cases: opioid/fentanyl/stimulant policy research and treatment-program siting. However, it does not specify when to avoid using this tool or mention alternative tools like cdc_weekly_deaths_by_state.

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

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

With no annotations provided, the description must carry the burden of behavioral transparency. It mentions the tool uses a statistical model to compare expected vs observed deaths, but omits details on data update frequency, authorization requirements, rate limits, or the structure of the output (e.g., columns returned). This leaves the agent with limited understanding of tool behavior.

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, each providing essential information: dataset identifier and purpose. No redundant or unnecessary words. Efficient 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?

Given the absence of output schema, the description does not explain the return format (e.g., columns, structure). While the purpose is clear, the agent lacks information about what data will be returned and how to interpret it. Adequate but incomplete for a data-returning 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 covers 100% of parameters with descriptions. The description adds context that the data is by state and week, but does not significantly enhance the meaning beyond the schema. Baseline is 3 for high coverage, and the description does not justify a higher 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 modeled expected vs observed deaths by state and week, with the purpose of estimating pandemic impact beyond reported COVID deaths. It is specific about the data source (CDC excess deaths dataset xkkf-xrst) and what it does, but does not explicitly differentiate from sibling CDC tools like 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 implies usage for estimating true pandemic impact, but does not provide explicit when-to-use or when-not-to-use conditions, nor does it mention alternative tools. The usage is implied rather than guided.

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?

No annotations are provided, so the description must fully disclose behavioral traits. It states the return of weekly ILI activity levels per state, but fails to mention data update frequency, potential latency, or that the data is provisional. The addition of the dataset ID (vh55-3he6) is helpful but incomplete for full 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, well-structured sentence of 15 words. It front-loads the source name and dataset ID, making it efficient and easy to scan. Every word serves a purpose.

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

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

The tool has three optional parameters and no output schema. The description does not specify what the output contains (e.g., columns like state, week, activity level). While it provides the core purpose, it lacks information about the expected return format, which is important 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?

Schema coverage is 100% with each parameter described in the input schema. The description adds no additional meaning beyond the schema, so the 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 the tool provides CDC FluView state-level influenza surveillance data, specifically weekly ILI activity levels per state. It effectively distinguishes this from other CDC tools like cdc_vaccination_coverage or cdc_weekly_deaths_by_state by naming the exact dataset and data type.

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 weekly ILI activity by state, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The context is clear but lacks directive 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?

No annotations are provided, so the description carries the full burden. It states the tool returns death counts and rates, implying a read operation, but does not explicitly confirm read-only behavior or disclose any other behavioral traits (e.g., data freshness, pagination, permission requirements). For a query tool, this is insufficient 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: two sentences with no waste. The first sentence identifies the data source and identifier, the second explains the output and use case. Information is front-loaded and easy to scan.

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 four parameters (none required) and no output schema, the description covers the key output (deaths and rates) and intended research areas. It is complete enough for a straightforward data retrieval tool, though it could mention defaults (e.g., limit) or output structure.

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 four parameters have descriptions in the schema (100% coverage). The description's phrase 'per cause per state per year' reinforces the parameter roles but does not add new meaning beyond the schema. Baseline 3 is appropriate as the schema already documents the 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 that the tool returns total deaths and age-adjusted death rates by cause, state, and year. It uses specific verbs and identifies the resource (NCHS leading causes of death). While it doesn't explicitly differentiate from sibling CDC tools like cdc_drug_overdose_deaths, the focus on 'leading causes' and 'chronic disease + injury mortality' provides context that distinguishes it.

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 mentions it is 'useful for chronic disease + injury mortality research,' which gives a hint about appropriate use cases. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other CDC mortality tools), and there is no mention of when not to use it or any prerequisites.

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?

No annotations are provided, so the description carries full burden. It does not disclose read-only behavior, pagination, rate limits, or any side effects. The description only lists return fields without behavioral context.

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

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

The description is a single sentence that efficiently conveys the data source, scope, and key fields. It is front-loaded with the source name and ID, and every phrase 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?

The description gives a good overview of return fields but lacks details on how parameters interact (e.g., year vs. state) and any limitations (e.g., maximum rows beyond the default 50). With no output schema or annotations, more context would be helpful.

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 parameter descriptions. The description adds value by listing the return fields (date, state, etiology, etc.), which is not in the schema. However, it does not clarify parameter relationships or constraints 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?

The description clearly states the tool returns CDC NORS foodborne/waterborne/enteric outbreak reports, listing specific fields. It distinguishes itself from sibling CDC tools by focusing on outbreak reports.

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 like cdc_dataset_query or other CDC tools. No exclusions or pre-requisites 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'returns booster + primary series percentages' but does not mention any behavioral traits such as read-only nature, performance, data freshness, or what happens when no data is found. Minimal behavioral context beyond purpose.

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: two short sentences with no wasted words. It front-loads the tool's main purpose and includes a practical 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 could provide more detail on the structure of returned data (e.g., fields, how time is represented). It mentions percentages over time but does not describe the full response format. Adequate but not 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% for all three parameters (limit, recip_state, recip_county). The description adds no additional parameter-specific meaning 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 the tool provides COVID-19 vaccination coverage data by US county, specifying 'booster + primary series percentages over time' and the dataset ID. The purpose is specific and distinguishes from generic CDC query tools, but does not explicitly differentiate 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 mentions it is 'useful for public-health gap analysis,' giving an example use case but not providing explicit guidance on when to use this tool versus alternatives like cdc_dataset_query or other CDC tools. The usage context is implied but no exclusions or alternative recommendations are given.

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?

No annotations provided, so description must fully convey behavioral traits. Mentions data is 'provisional' but lacks details on update frequency, pagination, rate limits, or authentication requirements. Could add more context about data limitations.

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 tool identity and dataset ID, then return type, then use case. 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?

No output schema, so description should summarize return structure. It states 'returns all-cause and selected-cause death counts per state per ISO week' but lacks column details or pagination info. Adequate but not fully 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% with descriptions for all 4 parameters. Description adds little extra beyond schema, only mentioning 'all-cause and selected-cause' which is already implied by the cause parameter. Baseline 3 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?

Clearly states the tool returns CDC weekly provisional deaths by state and cause, with specific verb 'Returns'. Distinguishes from siblings by specifying weekly provisional deaths and dataset ID. Includes use cases for excess-mortality and respiratory-disease seasonality 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?

Mentions use cases ('useful for excess-mortality and respiratory-disease seasonality analysis') but does not explicitly state when to use vs alternatives like cdc_excess_deaths_covid or cdc_flu_surveillance. No 'when not to use' guidance provided.

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

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

No annotations are provided, so the description must disclose behavioral traits. It accurately describes the output (business data) and the optional filter, but does not explicitly state that it is a read-only query or mention any authentication or rate limits. The description is generally transparent but lacks explicit safety cues.

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 (two sentences) and front-loaded with the core purpose. Every sentence adds value: the first defines the data and source, the second gives use cases. No redundant or vague phrasing.

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 (some conditional) and no output schema or annotations, the description covers the essential data content and use cases but omits behavioral details (e.g., that it is a query-only tool) and does not explain the relationship between parameters (e.g., required fields for different levels). Adequate 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 baseline is 3. The description adds context about the NAICS filter and summarises the data contents, but adds little beyond what the schema descriptions already provide for individual parameters. No parameter-specific enhancements.

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 identifies the tool's data source (County Business Patterns) and its contents (business establishments, employment, annual payroll), and lists specific use cases (industry research, competitive intel, supply chain analysis). This distinguishes it from sibling census tools like census_demographics or census_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 business-related research by mentioning optional NAICS filter and use cases, but does not explicitly guide when to choose this tool over other census tools (e.g., demographics, population). It would benefit from a sentence like 'Use for business statistics; for demographics use census_demographics.'

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?

No annotations are provided, so the description must carry the full burden. It describes the data retrieved but does not disclose behavioral traits such as pagination, response format, or any side effects (e.g., rate limits). For a read-heavy tool, additional transparency on limits or output structure would be beneficial.

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-loading the key functionality and use cases. No unnecessary words 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?

The description covers the core purpose and use cases but lacks detail on return value structure or parameter combinations. Given the tool has 8 parameters and no output schema, more context on expected results would 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 description coverage is 100%, so the baseline is 3. The description adds no new parameter-level details beyond listing the broad data categories, which does not significantly 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 clearly states the tool provides labor force, unemployment, commute times, and other related metrics for US geographies, with specific use cases (site selection, workforce analysis). This sufficiently distinguishes it from sibling census tools like census_demographics or 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 implies usage for workforce and real estate analysis but does not provide explicit guidance on when to use this tool versus alternatives or exclude other tools. No prerequisites or when-not-to-use information is given.

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?

No annotations are provided, so the description carries the full burden. It accurately describes the tool as returning demographic counts and median age, implying a read-only operation. However, it does not disclose potential rate limits, authentication needs, or behavior for missing data. Nonetheless, the description is consistent and factual.

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 (two sentences) with no wasted words. It front-loads the key purpose and follows with supporting details. 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 no output schema, the description should clarify the return format. It lists the fields but does not specify whether the result is a single object or array, nor does it mention default values (e.g., year defaults to 2023). The complexity is moderate, but the description leaves some ambiguity about output structure.

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 already well-documented. The description adds context about the data source (ACS 5-year) and the returned fields, but does not enhance parameter meaning beyond what the schema provides. 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 the tool returns race, ethnicity, and age breakdown for a US geography, listing specific categories (white, black, Asian, etc.) and median age. It distinguishes from sibling tools like census_population which likely returns total counts.

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 specifies the data source and scope (US geography) but does not provide explicit guidance on when to use this tool versus alternatives (e.g., census_population for total counts, census_income_housing for economic data). No exclusions or prerequisites 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?

No annotations are provided, so the description carries the full burden. It mentions lookup behavior and supported query types but does not disclose rate limits, read-only nature, or other traits. Adequate but not exhaustive.

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 resource. No wasted words. Perfectly 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?

For a lookup tool without output schema, the description explains what it returns (FIPS codes) and why it's needed (for other census tools). Complete given the 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%, but the description adds value by explaining how query works: 'state name or 2-letter code, ZIP code (5 digits), and (for state) substring matching.' This enriches 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: 'Look up Census FIPS codes by name.' It specifies supported query types (state name, code, ZIP, substring) and distinguishes from sibling census 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 explicitly says 'Use this to find the FIPS codes needed by other census_* tools,' indicating when to use it. It doesn't specify when not to use, but the context is 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?

No annotations provided. The description implies a read operation but does not disclose behavioral traits such as idempotency, rate limits, or data freshness. Lacks explicit read-only confirmation.

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: first lists returned data fields, second states use cases. No redundancy, well front-loaded.

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

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

With no output schema, the description lists the types of data returned. Lacks details on output format or pagination, but sufficient for a data retrieval tool with 8 parameters.

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 parameter descriptions. The tool description adds overall context but does not enhance individual parameter semantics 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 lists specific data points (median income, housing units, etc.) and states use cases for real estate AI and market analysis. However, it does not explicitly differentiate from sibling tools like census_demographics, though the data types are distinct.

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?

Implies usage from context ('real estate AI, market analysis, location-based pricing') but no explicit when-to-use or when-not-to-use guidance compared 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?

No annotations are provided, so the description must convey behavioral traits. It discloses that data comes from ACS 5-year estimates (via the 'year' parameter) and lists output fields. However, it does not mention rate limits, authentication needs, error handling (e.g., missing geography), or whether the operation is read-only.

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 core purpose and output. Every sentence adds value: first defines functionality, second suggests use cases. No unnecessary words 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?

Given the tool's complexity (8 parameters, multiple geography levels) and full schema coverage, the description adequately covers the main output and use cases. However, it does not explain required parameter combinations or the response format, which would be more helpful.

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 does not add meaning beyond the schema's parameter descriptions; it only restates geography levels and output fields. It does not clarify dependencies or format for parameters like 'tract' or 'msa'.

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 retrieves total population for US geographies, lists specific levels (state, county, ZIP, etc.), and specifies returned fields (total, male, female, median age). It also mentions use cases, distinguishing it from sibling tools like census_demographics which likely provide more detailed 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?

The description gives context for usage ('market sizing, location intelligence, demographic analysis') but does not explicitly compare to sibling tools or state when not to use this tool. No exclusions or alternatives are mentioned, leaving the agent to infer optimal usage.

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

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

With no annotations provided, the description carries full burden. It clearly states the tool aggregates counts by a facet and supports an optional company filter, but lacks details on output format, sorting (likely descending by count), handling of empty results, or potential rate limits. Acceptable but not exhaustive.

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, no filler. First sentence defines the operation with precision, second sentence provides practical applications. 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 the tool's simplicity (2 parameters, no nested objects, no output schema), the description covers the key behavioral aspects. It doesn't specify the exact return format (e.g., list of {facet_value: count}), but for an aggregation tool the implied output is clear. Could mention pagination or limits, but adequate for selection.

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 purpose of the facet parameter (aggregation dimension) and the company filter (to narrow results), plus gives examples of how to use them (e.g., ranking companies). This goes beyond mere parameter names and types.

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 aggregates complaint counts by a single facet, listing all six possible facet values (product, issue, company, state, company_response, submitted_via). It also provides concrete use cases (ranking companies by complaint volume, finding common issue categories), clearly distinguishing it from sibling tools like cfpb_search_complaints or cfpb_complaint_detail which return individual records.

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

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

The description gives clear usage context ('useful for ranking companies by complaint volume') but does not explicitly state when to use this tool versus its alternatives (e.g., cfpb_complaint_trends for time-based aggregation). However, the purpose is sufficiently differentiated from siblings 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?

No annotations provided, so the description carries full burden. It discloses that the full record, including narrative if consented, is returned. This adds useful behavioral context despite no mention of side effects or rate limits.

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

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

The description is a single sentence that front-loads the action and resource, with no wasted words. Ideal conciseness.

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

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

Despite no output schema, the description is complete enough for a simple fetch tool with one parameter. It covers purpose and return behavior, though could mention error handling.

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 a single parameter already described. The description does not add additional meaning beyond what the schema provides, so baseline 3 applies.

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

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

The description clearly states the tool fetches a single CFPB complaint by ID, using a specific verb and resource, and distinguishes it from sibling tools like cfpb_search_complaints.

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 you have a complaint_id, but does not explicitly state when to use it over alternatives or provide exclusions. No explicit guidance on not using with other 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?

Since no annotations are provided, the description carries the burden of behavioral disclosure. It explains the lens options and interval values, and implies read-only operation (trends). However, it does not explicitly state that it is non-destructive, nor does it mention any rate limits, pagination, or data freshness. The coverage 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 highly concise: two sentences with no redundancy. The first sentence states the core purpose, and the second sentence explains the key parameters (lens and interval) efficiently. Every word adds value.

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

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

With 7 parameters (lens, product, sub_lens, trend_depth, trend_interval, date_received_min, date_received_max) and no output schema, the description covers the critical lens and interval parameters but omits mentions of date range, trend_depth, and sub_lens. For a simple trend tool, this is moderately complete but could be more 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% (baseline 3). The description adds meaning by specifying what each lens value represents (e.g., 'overview shows total complaints over time') and that interval can be month, quarter, or year. This provides context beyond the schema's generic descriptions like 'Trend dimension' and 'Time bucket size'.

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 'time-series trends of complaint volume' and enumerates the lens options (overview, product, company, issue). This specifies the verb (trends) and resource (complaint volume) with scope. However, it does not explicitly differentiate from sibling tools like cfpb_complaint_aggregations, which could overlap.

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 no guidance on when to use this tool versus alternatives, such as cfpb_complaint_aggregations or cfpb_search_complaints. It only explains how to use the lens and interval parameters without any context about suitable scenarios 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?

With no annotations, the description carries the burden. It states it returns metadata and narratives, which is helpful, but lacks details on pagination limits (max 100 per schema), rate limits, or any side effects. It is adequate but not exhaustive.

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 parenthetical clarifying the database size. It front-loads the action and lists filters efficiently, wasting no 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?

Given 9 parameters and no output schema, the description mentions it returns metadata and narratives, which is a start. However, it omits details about output structure, pagination specifics (size limit), and error handling, leaving gaps for a complex 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 baseline 3. The description summarizes filters but adds no new details beyond what the schema already provides. It reinforces the purpose but does not enhance semantic understanding.

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

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

The description clearly states the tool searches the CFPB Consumer Complaint Database, a specific resource with 4M+ complaints. It lists key filters and what is returned, making it easy to distinguish from sibling tools like aggregations or 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 explains the tool's function and filters, but does not explicitly guide when to use this tool vs alternatives like cfpb_complaint_aggregations or cfpb_complaint_detail. The usage context is implied but not clearly delineated.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that the tool is read-only, whether it returns all states or only those with complaints, or any rate limits or authentication needs. The description only mentions the output type (counts and percentages) but lacks deeper behavioral context.

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

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

The description consists of two concise sentences. The first states what the tool does, and the second provides a use case. No redundant information, and each sentence earns its place. It is front-loaded with the core functionality.

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 (3 optional parameters, no output schema), the description is minimally adequate. It specifies the output involves 'counts and percentages per US state,' but does not detail the output format (e.g., state names, codes, or total counts). More completeness would be helpful for an agent to understand the return structure.

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 each parameter having a basic description ('Optional product filter,' 'YYYY-MM-DD upper bound,' 'YYYY-MM-DD lower bound'). The tool description adds no additional 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 the tool provides 'complaint counts and percentages per US state' with optional filtering by product and date range. The verb 'complaint counts and percentages' is specific, and the resource 'per US state' distinguishes it from other CFPB tools that focus on individual complaints or time 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 mentions it is 'useful for state-level financial-consumer risk maps,' giving a use case, but it does not explicitly state when not to use this tool or compare it to alternatives like cfpb_complaint_detail or cfpb_complaint_trends. Guidance 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?

No annotations provided. Description discloses the return limit of 10 suggestions but does not cover other behavioral aspects like rate limits, no matches behavior, or data freshness. Given no annotations, more detail would be beneficial but not critically lacking for a simple autocomplete.

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 core action. Every word serves a purpose 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?

Given the simplicity of the tool (one required parameter, no output schema), the description sufficiently covers its use case, output limit, and integration with another tool. No gaps for a basic autocomplete function.

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 one parameter 'text' described as 'Partial company name'. The description adds 'partial input' which overlaps with the schema. No extra syntax, examples, or formatting details 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 tool's function: auto-complete company names, returning up to 10 suggestions. It also distinguishes itself by specifying its use with cfpb_search_complaints' company parameter.

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 states to use the results as exact values for cfpb_search_complaints' company parameter, providing clear usage context. Could mention when not to use it or what scenarios it's meant for, but still strong.

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

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

With no annotations provided, the description carries full burden. It states the tool returns specific fields (name, address, services, quality ratings), implying a read-only operation, but does not disclose authentication needs, rate limits, or any side effects. It is reasonably transparent for a search tool.

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 immediately communicates the tool's purpose and output. No unnecessary words or information, though it could briefly mention search capability.

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

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

Given the tool's simplicity (4 optional parameters, no output schema), the description provides sufficient context: it identifies the data source (CMS Home Health Compare), the entity type, and the return fields. It is complete enough for an agent to understand what the tool does.

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 input schema already explains each parameter (limit, state, offset, name_contains). The description does not add additional meaning beyond the schema, making the baseline score of 3 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 searches for Medicare-certified home health agencies from CMS Home Health Compare, and lists the returned fields (name, address, services, quality ratings). It distinguishes itself from sibling tools that search for other facility types (hospice, hospital, nursing home) through the specific resource type, though it does not explicitly name them.

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 no explicit guidance on when to use this tool versus alternatives (e.g., other CMS search tools). It is implied that this is appropriate for home health agencies, but no conditions or exclusions are stated. This is adequate for a straightforward search 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?

No annotations are provided, so the description carries the burden. It states 'Search' and lists return fields, implying a read operation, but does not disclose potential rate limits, authentication needs, or pagination behavior beyond the schema's limit/offset parameters. Adequate but minimal.

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 purpose and return data. It contains no fluff and is appropriately sized for the tool's complexity.

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

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

Given the absence of an output schema, the description usefully lists the return fields. The schema covers parameters. It does not mention result limits beyond the schema's default or how filters combine, but it is fairly complete for a search tool with moderate 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 description coverage is 100%, so the schema already documents all parameters completely. The tool description adds no additional meaning or context for the parameters beyond what is in the schema. 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 specifies the verb 'Search', the resource 'Medicare-certified hospice agencies from CMS Hospice Compare', and lists the return data (provider name, address, ownership, and quality measures). This distinguishes it from sibling tools like cms_hospital_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 (when hospice agency data is needed) and the context is clear from the tool name, but it lacks explicit when-not-to-use guidance or alternatives. The sibling tools cover other provider types, so it's reasonably 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 disclosure of return fields and filtering is helpful, but it does not mention pagination, default limits, or data freshness. Without annotations, more context on behavior would improve 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?

Two sentences efficiently convey the action, dataset, return fields, and filtering capability. No unnecessary words 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?

The description covers purpose, dataset, return fields, and filters. It lacks details on pagination and result limits, but given the schema parameters, it is fairly complete for a simple search tool.

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

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

The input schema has 100% description coverage for parameters. The description adds little beyond summarizing the filters, so no extra semantic value is provided.

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 and lists return fields. However, it does not explicitly differentiate from sibling CMS tools like cms_home_health_search or cms_nursing_home_search, though the name implies the scope.

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 filter options (state, city, partial name) but provides no guidance on when to use this versus other search tools, nor does it describe any 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?

With no annotations provided, the description carries the full burden. It lists what data is returned (name, address, ownership, etc.) but does not disclose behavioral traits like pagination behavior, data freshness, rate limits, or whether it only returns active homes. The read-only nature is implied but not explicit.

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 immediately states the tool's purpose and what it returns. No unnecessary words; every part 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's simplicity (4 parameters, no output schema), the description adequately covers purpose and output fields. However, it lacks details on result ordering, data coverage, or handling of missing parameters, leaving minor gaps for a search tool.

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

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

Schema coverage is 100% with each parameter described in the input schema. The description does not add additional meaning beyond the schema, such as providing examples or constraints on the parameters.

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

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

The description clearly states the tool searches Medicare-certified nursing homes from CMS Nursing Home Compare, specifying the data source and return fields. It distinguishes itself from sibling tools like cms_hospital_search by targeting nursing homes 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 usage for nursing home searches but does not provide guidance on when to choose this tool over siblings (e.g., cms_home_health_search) or context on alternatives. No explicit when-to-use or when-not-to-use advice.

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?

No annotations provided, so the description must carry the burden. It mentions data source dependency (DAPIP) which adds transparency, but omits details like read-only nature, authentication, or rate limits.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's output.

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 single parameter and no output schema, the description adequately describes the returned data. It mentions conditional availability (DAPIP publication) which adds context. Could be improved by noting the lookup is for a single institution.

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 a clear description for unit_id. The description does not add extra parameter meaning beyond what the schema provides, so baseline score 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 returns current institutional accreditation status, accreditor, last action date, and programmatic accreditations. It distinguishes from sibling tools like college_demographics or college_metrics which cover other aspects.

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. The description does not mention scenarios where other college tools would be more appropriate.

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?

No annotations are provided, so the description must fully disclose behavioral traits. It only mentions the input parameter and general comparison categories. It fails to state that the tool is read-only, what the output format is (e.g., structured data), or any constraints like rate limits or authentication.

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: one sentence explaining purpose plus a short instruction. It is front-loaded with the core action. Every word is necessary 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?

Given no annotations or output schema, the description is incomplete. It explains what the tool does and the required input but does not describe the return format, pagination, or any additional context about how the comparison is presented. A more complete description would briefly outline the output structure.

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 covers the single parameter with a description of 'Array of 2-5 IPEDS UNITIDs.' The description adds 'Pass UNITIDs,' which is redundant. Since schema coverage is 100%, the description adds minimal value beyond restating the parameter's purpose.

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 performs a side-by-side comparison of 2-5 schools across cost, outcomes, and admissions metrics. The verb 'compare' and resource 'schools' are specific. It distinguishes from sibling tools like college_metrics (single school) and college_trends (time series).

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 when to use: when a comparative analysis of multiple schools is needed. It does not explicitly exclude alternatives or specify when not to use, but the context of 'comparison' against siblings like college_search or college_metrics is clear enough for an agent.

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?

No annotations provided, so description carries full burden. It states the tool returns demographics but does not disclose behavioral traits such as read-only nature, data freshness, or any side effects. For a single-school lookup, likely safe, but not explicitly stated.

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 with no unnecessary words. Immediately conveys the tool's purpose and outputs. Highly efficient.

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

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

Given the low complexity and sole parameter, the description adequately covers what the tool does. However, without output schema, it could include a note on return format or that data is for a single school. Mostly 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% for the single required parameter (unit_id). Description adds no additional meaning beyond the schema's 'IPEDS UNITID.' 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?

Clearly states the tool returns student-body demographics for one school, listing specific categories (race/ethnicity, gender, age, geographic origin). Distinguishes from siblings like college_search or college_compare which serve different purposes.

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 for obtaining detailed demographics of a single school, but no explicit guidance on when to use this tool versus siblings like college_metrics or college_outcomes_by_program. No exclusion criteria or alternatives 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?

No annotations are provided, and the description fails to disclose behavioral traits such as data source, update frequency, or limitations (e.g., only public institutions). It assumes read-only context but does not state it.

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

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

Single sentence, front-loaded with verb 'cost and outcome metrics', minimal 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?

Given no output schema, the description lists the metrics returned. However, it does not specify time frame, data vintage, or restrictions (e.g., only institutions in IPEDS), leaving some 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 schema already describes the single parameter (unit_id) as IPEDS UNITID. The description adds no further meaning, but schema coverage is 100%, 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 enumerates specific metrics (tuition, net price, graduation rate, etc.) for a single school, distinguishing it from sibling tools like college_search and college_compare.

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 for one school with a unit_id, but does not provide explicit when/when-not guidance or mention alternatives like college_compare for multiple schools.

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?

No annotations provided, so the description bears full burden. It discloses what data is returned but omits behavioral traits like read-only nature, rate limits, error conditions, or data freshness. The description is minimal for a tool that likely returns multiple records per school.

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 of 21 words, front-loaded with key information. No unnecessary words or repetition. Every word 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's simplicity (one param, no output schema), the description is fairly complete. It specifies the data types returned. However, it could mention that the output likely contains multiple programs and that the data pertains to a specific year or CIP code range.

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% for the single parameter (unit_id). The tool description adds context about the returned data but not about the parameter itself. Baseline 3 is appropriate as schema already documents the parameter adequately.

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

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

The description clearly states it provides program-level outcomes for one school, specifying median earnings, median debt, and award counts. It uses a verb (implied 'get') and resource (program-level outcomes), distinguishing from sibling tools like college_demographics or college_metrics.

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

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

The description implies it is for program-level outcomes per school, but does not explicitly state when to use it versus siblings or provide exclusions. Context signals and sibling names offer implicit distinction, but no direct 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?

No annotations are present, and the description does not disclose any behavioral traits such as data source, freshness, rate limits, or behavior on empty results. For a search tool, this lack of transparency leaves agents uncertain about reliability.

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 well-structured sentences with no wasteful words. It front-loads the main action and then lists filters and return fields efficiently.

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 six optional parameters and lack of output schema, the description provides a solid overview of functionality and return data. It could mention pagination or default behavior, but it is largely sufficient for an agent to understand the tool's purpose.

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 listing the return fields (location, control, etc.) not in the schema, but does not elaborate on parameter semantics 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 it searches US colleges and universities by various filters and lists the return fields. It effectively communicates the core function, though it does not explicitly differentiate from sibling 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?

No guidance is provided on when to use this tool instead of siblings. With many related college tools on the same server, explicit context about when to choose college_search over alternatives would be very helpful.

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

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

With no annotations, the description carries the full burden. It mentions the data source (Urban Institute Education Data Portal) but fails to disclose behavioral traits such as read-only nature, rate limits, data freshness, or whether the tool returns aggregated or per-year data. This is a significant gap for a data retrieval tool.

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, information-dense sentence that front-loads the purpose and essential choices (metric and year range). No unnecessary 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?

The description adequately explains what the tool does but is incomplete regarding the output format. With no output schema, the agent needs to infer that the result is a time-series of the chosen metric. A brief mention of the output structure would 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% with clear descriptions for each parameter. The description adds context by grouping metric choices and implying a year range, but does not provide new information beyond the schema. 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 'Multi-year trend for one school', specifying the source (IPEDS), the metrics (enrollment, graduation_rate, retention, cost), and the year range. This effectively differentiates it from siblings like college_metrics (single-year data) and college_compare (comparison across schools).

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 trend data for a single school over time, but does not explicitly state when to use this tool versus alternatives (e.g., college_metrics for single-year data, college_compare for cross-school comparisons). No exclusions or prerequisites 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?

No annotations are provided, so the description carries the full burden. It details the return fields but does not disclose data freshness, potential delays, or any limitations. The read-only nature is implied but not explicitly stated.

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: first states purpose and lists fields, second gives usage examples. No fluff, front-loaded with purpose, 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?

For a simple one-parameter tool, the description is comprehensive: it describes the purpose, all returned fields, and usage examples. However, it omits error handling (e.g., invalid ticker) and data source, which would complete the picture.

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 'symbol' is fully covered by the schema with a description. The description adds contextual value by clarifying that it's a stock ticker (e.g., AAPL) and linking to company research, going beyond the schema's basic 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 gets a company profile and financial fundamentals, listing many specific fields. It distinguishes from siblings like stock_quote (price only) by focusing on fundamentals. Examples like 'tell me about Apple' clarify the 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 explicitly gives usage examples (e.g., 'tell me about Apple'), which helps the agent know when to invoke it. However, it does not explicitly state when NOT to use it or mention alternatives among the numerous sibling finance 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?

Description indicates a read operation but provides no details on rate limits, authentication needs, error handling, or output structure. With no annotations, the tool's behavioral characteristics are underspecified beyond the basic purpose.

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?

Extremely concise: two sentences with no wasted words. The key action verb 'Get' is front-loaded, and the description efficiently conveys purpose and requirements.

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 simple retrieval tool: mentions the chronological nature and example actions. However, lacks details on return format, pagination, or the effect of the 'limit' parameter, which would enhance completeness given the absence of an output 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 provides 100% description coverage for all four parameters. The description adds marginal value by restating required parameters and the nature of the output, but does not clarify parameter syntax or constraints 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?

Clearly states it retrieves chronological legislative action history for one bill, listing example actions. However, does not differentiate from sibling tools like congress_bill_details or congress_bill_cosponsors, which could also be related to bill information.

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 through required parameters (Congress number, bill type, bill number). No explicit guidance on when to use this tool versus alternatives, such as when only bill details or cosponsors are needed.

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

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

No annotations are provided, so the description carries the full burden. It states what the tool does but does not disclose behavioral traits such as pagination, rate limits, data recency, or potential limitations beyond the limit parameter.

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 with two sentences plus a requirement note, front-loading the primary action and purpose without any 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?

The description mentions output includes party and state but lacks details on output format, pagination behavior, or any additional fields. Given no output schema, the description could provide more completeness for a list 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 descriptions for all parameters. The description adds minimal value beyond naming the output fields (party and state) but does not enhance parameter understanding.

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

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

The description clearly states the tool lists cosponsors of a specific bill, including party and state, which distinguishes it from related bill tools like congress_bill_details, congress_bill_actions, and congress_search_bills.

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 mentions the tool is useful for mapping coalitions and requires congress, bill type, and bill number, but does not provide explicit guidance on when to use it versus alternatives 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?

No annotations are provided, so the description carries the full burden. It identifies the tool as read-only by nature (getting details), but does not mention any behavioral traits such as error handling, data freshness, or rate limits.

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

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

Two concise sentences: the first states purpose and output, the second states requirements with an example. No wasted words; 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 simple, single-resource retrieval task and the absence of an output schema, the description covers the essential inputs and outputs. It could improve by mentioning what happens if the bill doesn't exist, but overall it is 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 description adds value by providing example values (118, 'hr', 3076) and clarifying the real-world meaning of 'bill_type' enum values beyond the schema's minimal 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 uses a specific verb 'Get' and clearly identifies the resource as 'one bill'. It lists the key fields returned, distinguishing it from sibling tools like congress_bill_actions or congress_bill_cosponsors which focus on specific aspects.

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 the required parameters (Congress number, bill type, bill number) and provides an example, but does not explicitly guide when to use this tool versus alternatives (e.g., when to use congress_search_bills instead).

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

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

With no annotations, the description carries full burden. It discloses the output fields but lacks details on ordering, pagination, or sorting. Not misleading but incomplete for a listing tool.

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 fluff, front-loaded with purpose. 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 two optional parameters and no output schema, the description is reasonably complete. It covers what the tool lists and defaults. Could mention ordering but not essential.

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 3. The description adds marginal value by clarifying 'recent' and 'roll-call' but does not significantly enhance parameter 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?

The description clearly states the tool lists recent U.S. House roll-call votes and specifies output fields (vote number, question, result, date). It differentiates from sibling congress tools by targeting House votes 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?

No explicit guidance on when to use this tool vs alternatives like congress_bill_details or congress_search_bills. The description does not mention when not to use or provide context for 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?

No annotations are provided, but the description discloses the type of data returned (party history, terms, leadership roles). It does not mention any behavioral traits beyond that (e.g., rate limits, data freshness), which is acceptable for a read-only tool but leaves room for improvement.

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 is concise and front-loaded with the key information. Every part contributes to clarity without any 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 tool with one parameter and no output schema, the description fully covers the purpose and return content. It is complete given the tool's complexity and the absence of additional structured fields.

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% coverage for the single parameter, and the description adds value by providing an example ('P000197') and specifying the output content (party history, terms, leadership roles), which goes beyond the schema's basic 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 verb 'Get' and the resource 'detailed profile for one member of Congress' along with a specific example bioguide ID. It mentions included data (party history, terms, leadership roles), distinguishing it from sibling tools like congress_search_members.

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 conveys when to use this tool: when you need a detailed profile for a specific member of Congress by bioguide ID. While it doesn't explicitly state when not to use it or name alternatives, the context is clear and sufficient given sibling tool names like congress_search_members.

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

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

With no annotations provided, the description carries the burden for behavioral transparency. It indicates a read-only listing operation but does not disclose ordering, pagination, or result size limitations beyond the schema. Adequate but minimal.

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 with no extraneous information. First sentence states purpose, second clarifies options. 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 listing tool with three optional parameters and no output schema, the description covers core functionality and parameter usage. Could mention return format or sorting but not necessary for basic 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% with descriptions for all three parameters. The description adds context on defaults and law_type enum values, but does not significantly enhance parameter understanding 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 verb 'List' and the resource 'bills that have become public or private law in a given Congress'. It distinguishes from sibling tools like congress_search_bills by focusing specifically on enacted laws.

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 on default Congress and law_type usage, but does not explicitly state when to use this tool versus alternatives like congress_search_bills. The guidance is adequate for an experienced user.

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?

No annotations are provided, so the description must fully disclose behavioral traits. It states the tool returns 'most recently updated bills' but does not clarify if it is read-only, any rate limits, authentication needs, or what happens with empty results. For a search tool, it lacks disclosure about data freshness or pagination behavior beyond what the schema implies.

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, each carrying essential information: first defines the tool, second adds constraints and use case. It is front-loaded, concise, and free of redundancy. 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?

The input schema is well-defined with 5 parameters, all described. No output schema exists, and the description does not explain the return format or fields. For a search tool, this is commonly accepted but could be more explicit. The description is adequate for basic use but lacks details that would fully inform an agent, given the tool's moderate 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 description coverage is 100% (every parameter has a description). The description adds 'optionally scoped to a Congress number or filtered by a free-text query,' which reinforces the purpose of `query` and `congress` parameters but does not provide new semantic meaning beyond the schema. 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 identifies the tool as searching/listing recent U.S. federal bills and resolutions from Congress.gov. It specifies optional filters for Congress number and free-text query, giving a precise verb-resource combination. However, it does not explicitly differentiate from sibling tools like congress_bill_details or congress_search_members, missing a chance to sharpen purpose against alternatives.

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

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

The description provides usage guidance: 'Use this to find legislation by topic or to see what is currently moving.' This implies typical use cases but does not state when to avoid this tool (e.g., use congress_bill_details for specific bill details) or mention any prerequisites. No exclusions or alternatives are given, limiting the agent's ability to select appropriately.

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?

No annotations are provided, so the description carries full burden. It describes the return values but does not disclose potential limitations like pagination, default limit behavior, or read-only nature. The description is adequate but not comprehensive.

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: first for purpose and filters, second for return fields and next step. It is concise, front-loaded, and 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?

With no output schema, the description adequately covers purpose, filters, return fields (name, party, chamber, bioguide ID), and links to congress_member_details. It misses mentioning the limit and current_member filters explicitly, but those are 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?

Schema coverage is 100%, so the schema already describes all five parameters. The description adds a summary of key filters but does not provide additional semantic detail beyond what's 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 'Search members of Congress' and lists optional filters, distinguishing it from siblings like congress_member_details. It specifies the resource (members of Congress) and the verb (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 a workflow by mentioning 'use that ID with congress_member_details', providing context on when to use this tool vs. a sibling. However, it does not explicitly state when to use or not use this tool over other congress search 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 discloses that the tool combines findings from five sources, has a weighted metric with an explainable evidence chain, and that sanctions hits override. It also lists return fields. However, it does not mention any rate limits, authentication needs, or performance characteristics, which are unaddressed due to lacking annotations. Still, it provides substantial behavioral context.

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

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

The description is two paragraphs: first paragraph explains what the tool does and how it works, second outlines the return structure. It is well-organized and informative without being verbose, though it could be slightly shorter without losing clarity.

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, composite scoring, no output schema), the description is sufficiently complete. It explains the input, processing, output fields, and edge case (sanctions zeroing). An AI agent can use this description to invoke the tool correctly and interpret results.

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

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

Schema description coverage is 100% with a well-described company_name parameter. The description only reiterates the parameter's purpose with minimal added detail (e.g., examples and normalization), so it adds little 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 tool computes a composite 0-100 risk score for a company name, combining five specific data sources. It lists the return fields (score, risk band, evidence, etc.), making the purpose unmistakable. Among many sibling tools, this is uniquely focused on counterparty risk aggregation.

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 'Use this when you need a single-call counterparty risk verdict instead of stitching five separate queries,' giving clear when-to-use guidance. It also notes that sanctions hits zero the score, which is an important behavioral rule that affects usage.

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

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

With no annotations, the description bears full responsibility for behavioral disclosure. It implies a read-only search operation but does not explicitly state safety traits (e.g., no side effects, no destructive actions). No rate limits or authentication needs are mentioned.

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 consists of two concise sentences: the first explains the purpose and filters, the second describes the output. No unnecessary 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?

Without an output schema, the description should detail the return format more thoroughly. It only mentions 'case summaries with citations,' missing pagination, fields, or result count. The description is adequate but not fully complete for a tool with 7 optional parameters.

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 each parameter has its own description in the schema. The tool description merely lists the search dimensions without adding additional meaning or clarification beyond the schema, so it provides no extra 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 it searches federal and state court opinions by multiple filters and returns summaries with citations. However, it does not differentiate itself from the sibling tool 'court_opinion_search', which may cause confusion.

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 the similar sibling 'court_opinion_search' or any other alternatives. There is no mention of prerequisites or context for 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 provides no behavioral details such as error handling, expected output structure, or whether the operation is read-only. Without annotations, this is a significant gap for a single-purpose tool.

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, concise and front-loaded. However, it could earn its place by adding more useful context, such as expected output format, without becoming 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?

Given the low complexity (1 required parameter) and no output schema, the description should provide what the tool returns (e.g., case details) but does not. This leaves the agent uninformed about the result.

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 a description for the citation parameter. The tool description repeats the example but adds no additional meaning beyond the schema, so the 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 the tool resolves a legal citation to a CourtListener case record, with an example. It differentiates from sibling tools like court_case_search (which searches by other criteria) by specifying the input is a citation string.

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 like court_case_search or court_opinion_search. The description implies usage when a citation string is available, but lacks explicit direction 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?

With no annotations, the description bears the full burden of behavioral disclosure. It states the tool returns party list and recent entries from PACER/RECAP, which adds useful context about data source and output nature. However, it does not mention side effects, error handling, or any constraints (e.g., rate limits, data recency), so transparency is adequate but incomplete.

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, each adding essential information: what the tool does and what it returns. No redundant or filler content. It is efficiently structured and easy to parse.

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

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

Given the tool's simplicity (two parameters, no output schema, no annotations), the description covers the basic functionality and output. However, it lacks contextual details such as when to prefer this tool over siblings, potential error scenarios, or scope limitations (e.g., only federal dockets). This makes it minimally viable but not fully comprehensive for an AI agent.

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

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

Schema coverage is 100%, meaning both parameters are already described in the input schema. The description provides examples (e.g., 'nysd' and '1:23-cv-04567') that add marginal clarity but do not significantly extend beyond the schema's own descriptions. 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 the tool looks up a federal docket by court ID and docket number and specifies it returns party list and recent entries from PACER/RECAP. However, it does not explicitly differentiate from sibling tools like court_case_search or court_opinion_search, which may have overlapping functionality.

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 such as court_case_search or court_opinion_search. There is no mention of prerequisites, limitations, or exclusions, leaving the agent without context for appropriate invocation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool returns (positions, education, bench history) but does not mention whether it is read-only, if it requires authentication, any rate limits, or how it handles partial name matches. This is minimal transparency for a lookup tool.

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, well-structured sentence that efficiently conveys the tool's purpose and output. Every word adds value, and there is 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?

Given the tool's low complexity (1 parameter, no nested objects, no output schema), the description adequately covers what the tool does and what it returns. It is nearly complete, though it might benefit from noting that partial name searches are supported, which the schema already implies.

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% coverage for the single parameter 'name', which is well-described in the schema itself. The description adds no additional semantic information beyond what the schema already 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 clearly states the verb 'look up' and the resource 'judge profile', specifying that it can be done by name or CourtListener person ID. It distinguishes from sibling tools by focusing specifically on judge profiles, unlike other court-related tools that handle cases, dockets, opinions, etc.

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 when seeking a judge's profile, but it provides no explicit guidance on when not to use this tool or mentions alternatives among the many sibling tools. No exclusions or context for optimal use are given.

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

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

With no annotations, the description carries full burden. It only mentions outputs but does not disclose behavioral aspects like search behavior (e.g., fuzzy matching), pagination, authentication requirements, or rate limits.

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

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

A single, well-front-loaded sentence conveys the purpose and key outputs with zero waste. Every word serves a purpose.

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

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

Given a simple 3-parameter tool with no output schema or annotations, the description adequately states purpose and outputs but lacks detail on result ordering, pagination, and expected behavior for edge cases.

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 for all parameters. The description adds no additional meaning beyond the schema, so 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 performs full-text search of court opinions and lists specific outputs (snippets, authors, citations), distinguishing it from sibling tools like court_case_search which likely search case metadata.

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., court_case_search, court_docket_lookup). The description does not provide any context for tool selection.

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