Server Quality Checklist

Tool Scores

• congress_crs_reportsC
  2.9/5.0
  Behavior2/5

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

  Annotations declare readOnlyHint=true, but the description adds no behavioral context beyond that. It does not disclose pagination, default limit, response structure, or how date filters behave. The 'gold standard' phrase is about the reports themselves, not 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.

  Conciseness4/5

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

  The description is concise at two sentences, but the second sentence ('gold standard') is somewhat promotional and adds little operational value. Still, it is brief and readable.

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

  Completeness2/5

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

  With no output schema, the description should clarify what the tool returns (e.g., a list of reports with metadata). It fails to mention that it returns multiple reports or that date and limit parameters control the results. This is a significant gap for an effective tool description.

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

  Parameters3/5

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

  The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional parameter 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.

  Purpose4/5

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

  The description clearly states the tool retrieves Congressional Research Service reports, which is a specific verb+resource. However, it does not distinguish this from sibling tools like congress_crs_report_details, nor does it mention whether it lists, searches, or filters reports.

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

  Usage Guidelines2/5

  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 alternatives. It does not mention that date range or limit parameters can be used, nor does it reference sibling tools such as congress_crs_report_details for individual report lookups.

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

• congress_amendment_detailsB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds that the tool returns 'actions/timeline', which is useful behavioral context. However, it doesn't describe response format, pagination, or potential errors. Since annotations cover the read-only aspect, a mid-range score is appropriate.

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

  Conciseness5/5

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

  The description is only two sentences and about 20 words, front-loaded with the action verb 'Get'. Every phrase contributes either to purpose or required inputs. There is no fluff or redundancy, achieving maximum conciseness.

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

  Completeness3/5

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

  For a simple read-only detail lookup with fully required params, this description is minimally adequate. But it doesn't elaborate on what 'detailed information' includes beyond 'actions/timeline', doesn't clarify the omitted suamdt type, and doesn't differentiate from close siblings like congress_amendment_text. Given no output schema, additional context would improve completeness.

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

  Parameters2/5

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

  Schema descriptions are tautological ('Congress number', 'Amendment type', 'Amendment number'), so the description needed to add real value. Instead, it repeats those labels and even omits a valid enum value (suamdt) by listing only 'hamdt/samdt'. It provides no format hints or examples for amendment_number (string vs number), making the parameter information less useful than the schema.

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

  Purpose4/5

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

  The description clearly states a specific verb ('Get') and resource ('detailed information about a specific amendment'), and adds content scope ('including its actions/timeline'). It identifies the required identifiers, distinguishing it from list-style tools like congress_amendments. However, it doesn't explicitly differentiate from sibling detail tools such as congress_amendment_text, so it doesn't earn a 5.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description only restates required parameters, which is schema information. It doesn't name alternative tools (e.g., congress_amendment_text) or give exclusions, leaving the agent to infer usage context from vague wording.

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

• lobbying_registrantsB
  3.2/5.0
  Behavior2/5

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

  The annotations declare readOnlyHint=true, which covers safety, but the description adds no behavioral context. It does not disclose pagination behavior, result format, or any limits beyond what is in the schema. Since the description adds no value beyond the annotation, this is a weak disclosure.

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

  Conciseness5/5

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

  The description is a single, concise sentence that fully conveys the tool's purpose without redundancy. It is front-loaded and every word earns its place.

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

  Completeness4/5

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

  For a simple search tool with two well-documented parameters and a read-only annotation, the description is adequate for an agent to select and invoke it. The absence of an output schema is acceptable, though more detail on result behavior would be helpful in a tool-rich context.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both 'name' and 'page_size' documented. The description adds no parameter-specific meaning beyond the schema, but the schema already provides clear examples (e.g., 'Amazon', 'Pfizer'). This meets the baseline for high coverage, though no extra semantic value is added.

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

  Purpose4/5

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

  The description clearly states the tool's function: 'Search lobbying firms and organizations registered to lobby Congress.' It identifies a specific verb ('search') and resource ('lobbying firms and organizations'), making the purpose unmistakable. However, it does not explicitly distinguish itself from sibling tools like 'lobbying_search' or 'lobbying_lobbyists', though the focus on registrants implies a unique scope.

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

  Usage Guidelines2/5

  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. It does not mention alternative tools, prerequisites, or exclusions. For a domain with many lobbying-related sibling tools (e.g., lobbying_search, lobbying_detail), explicit usage guidance would help.

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

• usgs_water_dataB
  3.2/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares the tool is read-only, and the description adds useful context like station count and parameter codes with units. However, it overstates query capabilities (county/HUC) and does not disclose response format or any rate limits, which matters since there is no output schema. It does not contradict the annotation, but the false capability claim reduces transparency.

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

  Conciseness4/5

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

  The description is three sentences, front-loaded with the primary action, and compact. It includes valuable quick-reference data (station count, parameter codes/units). The third sentence about query methods is efficient but contains an inaccuracy, preventing a perfect score.

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

  Completeness3/5

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

  The tool has 6 optional parameters, a read-only annotation, and no output schema. The description covers data type, station scale, parameter codes, and query entry points, but it omits any indication of what the response looks like (since no output schema exists) and incorrectly lists county/HUC as query options. Given the richness of the schema and the sibling tools, a clearer tie to usgs_daily_water_data would improve completeness.

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

  Parameters3/5

  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 repeats parameter code meanings already present in the schema (00060, 00065, 00010) and adds the 'query by county/HUC' claim, which does not map to any parameter. It provides no additional semantic value for parameters beyond what the schema already documents, and the unsupported query methods could mislead parameter usage.

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

  Purpose4/5

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

  The description clearly states the tool retrieves real-time water data (streamflow, gage height, temperature) from USGS monitoring sites, with a specific verb and resource. It provides enough detail to distinguish it from siblings like usgs_water_sites or usgs_daily_water_data by emphasizing 'real-time', though it does not explicitly name alternatives. The claim about querying by county or HUC is misleading because those params are absent from the schema, slightly detracting from clarity.

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

  Usage Guidelines2/5

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

  The description gives some usage context—'real-time' data, query by site ID/state—but it does not explain when to use this tool versus the closely related usgs_daily_water_data or usgs_water_sites. More problematically, it claims county and HUC queries are supported, but the schema only provides sites and state_cd, which is actively misleading guidance for an agent deciding how to query.

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

• usgs_water_sitesB
  3.2/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint: true, which discloses the read-only safety profile. The description adds context about the search scope (state, county, site type) but does not mention return format, pagination, or any constraints on combining filters. This is adequate but not rich.

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

  Conciseness4/5

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

  The description is concise and front-loaded with the action ('Search for USGS water monitoring sites'). It is two sentences and every sentence earns its place. However, the inclusion of 'hydrologic unit' is an error that detracts from the overall quality, so it loses a point for accuracy.

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

  Completeness3/5

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

  For a simple search tool with 3 optional parameters and no output schema, the description gives a sufficient overview but lacks details about return values, required filter combinations, or pagination. The mismatch about hydrologic unit also leaves the agent uncertain about available query parameters. It is minimal but not fully complete.

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

  Parameters2/5

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

  Schema description coverage is 100%, so typically this would be a baseline 3. However, the description mentions 'hydrologic unit' as a search criterion but no such parameter exists in the schema. This actively misleads by suggesting a filter that is not available, and it adds nothing beyond what the schema already explains for the existing parameters.

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

  Purpose4/5

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

  The description clearly states 'Search for USGS water monitoring sites' with a specific verb and resource, and it distinguishes this from data-retrieval tools like usgs_water_data. However, it mentions searching by 'hydrologic unit' which is not present in the input schema, creating minor ambiguity about the exact capabilities.

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

  Usage Guidelines3/5

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

  The description provides clear context for when to use this tool (searching for monitoring sites by location/type) but does not explicitly name alternatives or state when not to use it. Siblings like usgs_water_data likely retrieve data for a given site, but no explicit differentiation is given.

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

• cdc_disabilityB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the description need not repeat that. It adds a data source ('BRFSS survey') and lists types, but does not disclose behaviors like pagination, return format, or any limitations. Since annotations cover the safety profile, the description's added context is minimal but adequate.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main action, and the list of types is directly useful for parameter selection. No filler or redundancy.

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

  Completeness3/5

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

  With no output schema, the description does not explain the return format or whether data is aggregated by year. However, the tool is a simple filtered lookup with clear inputs, so the description covers the core purpose but leaves some ambiguity about output expectations.

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

  Parameters3/5

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

  Schema description coverage is 100%, with each parameter (limit, state, disability_type) having a description. The description merely repeats the disability_type choices already in the schema, adding no new semantic value beyond what is structured.

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

  Purpose4/5

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

  The description clearly states what the tool does: 'Get disability prevalence by state and type from BRFSS survey.' It uses a specific verb and resource, and enumerates valid disability types. It does not explicitly distinguish this from sibling tools, but the purpose is unambiguous.

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

  Usage Guidelines2/5

  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 vs. alternatives. It does not mention any exclusions, prerequisites, or comparisons to similar CDC tools. There is no context about whether this is the right choice for particular queries.

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

• congress_committee_report_detailsB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description's 'Get detailed information' is consistent with a read-only operation. The description adds context about the returned fields (bills, title, issue date, text versions) but does not disclose potential pitfalls, authentication needs, or response formatting. With annotation coverage, this is adequate but not rich.

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

  Conciseness5/5

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

  The description is a single focused sentence that immediately states the verb and object, with no filler or redundancy. It is front-loaded and easy to parse, earning top marks for conciseness.

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

  Completeness3/5

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

  For a straightforward detail-retrieval tool with three well-documented parameters, the description covers the core purpose and the kind of data returned. However, it leaves ambiguity around 'text versions' (vs. full text) and does not specify any limitations or fallback behavior. Given that there is no output schema, a bit more detail would improve completeness, but the tool is simple enough to remain adequate.

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

  Parameters3/5

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

  All three parameters (congress, report_type, report_number) have descriptions in the schema, so the description adds no additional parameter-level meaning beyond what is already documented. The mention of 'specific committee report' does not elaborate on how these parameters combine, but the high schema coverage justifies the baseline score of 3.

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

  Purpose4/5

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

  The description clearly states the resource (specific committee report) and the type of information returned (associated bills, title, issue date, text versions), making the purpose unambiguous. However, it does not explicitly contrast with sibling tools like congress_committee_reports or congress_committee_report_text, so it lacks full differentiation.

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

  Usage Guidelines2/5

  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, nor any exclusions or prerequisites. The only implicit cue is the word 'specific,' but there is no explicit reference to sibling tools or use cases, leaving the agent without decision support.

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

• naep_achievement_levelsB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, lowering the bar. The description adds an example of the output format and interprets the metric as showing grade-level proficiency, but it does not disclose defaults, edge cases, or other behavioral details beyond what annotations and schema already provide.

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

  Conciseness5/5

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

  Two sentences plus a concrete example, front-loaded with the core purpose. Every sentence carries meaning, and the all-caps emphasis highlights the metric's importance without adding significant fluff.

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

  Completeness3/5

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

  Adequate for basic use, but with many NAEP sibling tools, the description does not clarify when to use this specific tool. The example provides a glimpse of output, while schema covers parameters. Missing discussion of variable and jurisdiction breakdowns relative to alternatives leaves some gaps.

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

  Parameters3/5

  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 parameter-specific meaning; it only clarifies the output nature (percentages per level). Grade and subject constraints are already well documented in the schema.

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

  Purpose4/5

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

  Clearly states it gets the percentage of students at each NAEP achievement level, listing the specific levels and providing a concrete example. However, it does not explicitly differentiate itself from sibling NAEP tools like naep_scores or naep_compare_years, so it falls short of a 5.

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

  Usage Guidelines2/5

  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. It emphasizes being the key metric but does not mention when to prefer it over naep_scores or other NAEP comparison tools, leaving the agent without explicit selection criteria.

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

• nasa_eonetB
  3.3/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the readOnlyHint annotation. It does not disclose response format, pagination behavior, or default status filtering. The annotation covers the read-only safety aspect, but the description fails to provide any additional operational details.

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

  Conciseness5/5

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

  The description is two sentences, with the main purpose clearly front-loaded. The category list is compact and informative. No unnecessary words or fluff.

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

  Completeness3/5

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

  For a simple read-only tool with three optional params, the description is adequate but leaves gaps. Since there is no output schema, the description should explain what the return data looks like or mention default behavior (like status defaulting to 'open'), but it does not. It lists categories but lacks details on response structure or how filters interact.

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

  Parameters3/5

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

  The input schema already provides full descriptions for all three parameters (limit, status, category). The description's category list slightly expands on the schema's examples but adds minimal meaning beyond what the schema already communicates. Baseline of 3 is appropriate given 100% schema coverage.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get Earth natural events from NASA EONET.' It uses a specific verb and resource, and the category list (wildfires, severeStorms, volcanoes, etc.) adds useful scope. It does not explicitly differentiate from sibling NASA tools, but the uniqueness is fairly obvious.

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

  Usage Guidelines3/5

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

  The category list implies when to use the tool (e.g., to retrieve wildfire or earthquake events), but there is no explicit guidance on when to use this over other event sources or what status values mean. No exclusions or alternatives are mentioned.

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

• nws_alerts_activeB
  3.3/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, so the description does not need to state that the operation is read-only. It does add scope information (alert types and filters) but does not disclose other behavioral traits such as default limit, pagination, or response format. This is a moderate addition beyond the annotations.

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

  Conciseness5/5

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

  The description is extremely concise, consisting of two sentences that are both informative. The first sentence states the core function, and the second lists the filter options. Every word earns its place, with no filler or redundancy.

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

  Completeness3/5

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

  Given the full schema coverage and readOnlyHint annotation, the description is adequate for basic invocation. However, it lacks guidance on how this tool relates to the sibling 'nws_alerts_by_state' and does not mention default behavior (e.g., what happens when no filters are provided). This creates a moderate gap in an ecosystem with many similar weather-related tools.

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

  Parameters3/5

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

  Since the input schema has 100% description coverage for all parameters, the baseline is 3. The description merely lists the same filter categories already present in the schema (state, event, severity, urgency, certainty) without adding any additional semantics like value formats, parameter interactions, or default behavior. It adds no substantial value over the schema.

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

  Purpose4/5

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

  The description clearly identifies the tool's function with a specific verb ('Get') and resource ('active weather alerts'), and lists the types of alerts (warnings, watches, advisories) and filter dimensions. However, it does not explicitly differentiate this tool from the sibling tool 'nws_alerts_by_state' or 'nws_alert_detail', so it misses the highest score.

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

  Usage Guidelines2/5

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

  The description provides filter options but gives no explicit guidance on when to use this tool versus alternatives such as 'nws_alerts_by_state' or 'swpc_alerts'. It does not mention default behavior (e.g., no filters returns all active alerts) or any exclusions, leaving the agent without clear selection criteria.

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

• sam_entitiesB
  3.3/5.0
  Behavior2/5

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

  The description simply says 'Search' and lists parameters, which is largely redundant with the schema descriptions. Annotations declare readOnlyHint=true, so the read-only nature is already covered. It adds no behavioral details such as result limits, pagination, what happens when no filters are provided, or any special constraints, thus providing minimal value beyond the structured metadata.

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

  Conciseness5/5

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

  The description is two sentences with zero filler. The first sentence identifies the action and resource, the second lists the available lookup keys. Every word earns its place, making it concise and well-structured.

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

  Completeness3/5

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

  For a simple search tool with complete schema descriptions and a read-only hint, the description is adequate. However, it lacks guidance on parameter combinations, default behavior when no filters are supplied, and return format (since no output schema exists). Given the presence of sibling SAM tools, a pointer to alternatives would improve completeness, but the current description is minimally sufficient.

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

  Parameters3/5

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

  Schema covers all 5 parameters with descriptions (100% coverage), so the baseline is 3. The description repeats four parameter names but adds no new semantic meaning or interaction rules (e.g., whether filters are combinable or mutually exclusive). It neither improves nor degrades the schema information.

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

  Purpose4/5

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

  The description clearly states the tool searches registered entities (businesses/orgs) on SAM.gov, with specific lookup fields (UEI, CAGE code, name, state). It is specific and resource-focused, though it does not explicitly differentiate from sibling tools like sam_opportunities or sam_exclusions.

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

  Usage Guidelines3/5

  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 searching for entity registrations on SAM.gov) but does not provide explicit exclusions or alternatives. It lists valid lookup dimensions but does not explain when to prefer this over sam_opportunities or sam_exclusions, leaving usage guidance implicit.

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

• state_environmentB
  3.3/5.0
  Behavior2/5

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

  Annotations provide readOnlyHint=true, which the description does not contradict, but the description adds little behavioral context. It does not disclose pagination, result formats, rate limits, or that the 'where' parameter implies SoQL filtering. The only added context is the suggestion to cross-reference EPA tools, which is more of a usage note than a behavioral disclosure. With annotations covering safety, the description still fails to enrich the agent's understanding of runtime behavior.

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

  Conciseness5/5

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

  The description is concise (3 sentences) and front-loaded with the primary purpose. It uses a clear verb ('Query') and provides a helpful list of example data types. Every sentence earns its place, and there is no filler or redundancy.

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

  Completeness3/5

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

  Given the tool has 5 parameters, no output schema, and a broad scope, the description is adequate but minimal. It lists content categories and hints at a state-vs-federal context, yet it does not explain how to use filters (q, where, county) beyond what the schema already says, nor does it describe the relationship to sibling environmental tools like epa_facilities. For a query tool with no output schema, more context about expected return shape or dataset source would improve completeness.

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

  Parameters3/5

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

  Schema description coverage is 100%: all parameters (state, q, limit, where, county) have descriptions. The baseline is therefore 3. The tool description does not add any parameter-specific semantics beyond listing data categories, but it does not need to because the schema is thorough. No extra value like examples or parameter interactions is provided.

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

  Purpose4/5

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

  The description clearly states the tool queries environmental data for a US state and lists example content types (air quality violations, water assessments, etc.). It distinguishes from sibling state_* tools (health, education, economy) and mentions cross-referencing with federal EPA tools for national context, which highlights its state-level scope. However, the phrase 'May include' is somewhat open-ended, leaving the exact dataset scope slightly unspecified.

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

  Usage Guidelines3/5

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

  The description implies usage for state-level environmental queries and notes that federal EPA tools should be used for national context, which is a partial distinction. However, it does not explicitly state when to prefer this tool over specific alternatives like epa_facilities or state_query, nor does it mention prerequisites or exclusions. Usage 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.

• usa_agency_overviewB
  3.3/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already indicates a safe read operation. The description adds minimal behavioral context by mentioning 'budgetary resources and obligations' but does not describe response format, data granularity, or any caveats. This is acceptable given the annotation coverage, but no extra transparency is provided.

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

  Conciseness5/5

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

  The description is concise and front-loaded, with a single sentence stating the purpose followed by a helpful list of common codes. No wasted words or redundant information. It is appropriately structured for quick scanning.

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

  Completeness3/5

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

  The description is adequate for a simple 2-parameter read-only tool, but it lacks an explanation of the response structure (since there is no output schema) and does not clarify how this overview differs from other USAspending tools that appear in the sibling list. The mention of 'budgetary resources and obligations' gives a hint, but more context would help.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both agency_code and fiscal_year documented. The description adds a few more common agency codes (e.g., '012', '015') beyond those in the schema, but this is marginal. The fiscal_year parameter is only described in the schema, not in the description, so the description adds little semantic value beyond the schema.

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

  Purpose4/5

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

  The description clearly states the tool's function: 'Get an overview of a federal agency's spending, including budgetary resources and obligations.' The verb 'get an overview' and the resource 'federal agency's spending' are specific. It is somewhat distinct from siblings like usa_spending_by_agency, but the name and title reinforce the purpose.

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

  Usage Guidelines2/5

  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 similar alternatives such as usa_spending_by_agency or usa_spending_over_time. The description only lists common agency codes, which is parameter guidance rather than tool-selection guidance.

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

• congress_committee_detailsB
  3.4/5.0
  Behavior3/5

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

  The annotation readOnlyHint already signals a safe read operation, lowering the bar. The description adds what the tool returns (full history, website URL, subcommittees, bill/report counts, related communications) but does not discuss rate limits, error cases, or data quirks. This is moderately useful 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.

  Conciseness5/5

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

  One well-structured sentence that leads with the purpose and then itemizes the return attributes. No filler or redundancy – every word earns its place.

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

  Completeness4/5

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

  For a simple 2-parameter, read-only tool with full schema coverage and a clear annotation, the description covers the main context: what the tool does and what it returns. It could improve by noting the relationship to sibling committee tools, but overall it is sufficient.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both chamber and committee_code documented, including an enum for chamber and an example for committee_code. The description simply restates 'by chamber and committee code' without adding meaning beyond the schema.

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

  Purpose4/5

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

  The description clearly states 'Get detailed information about a specific congressional committee by chamber and committee code' – a specific verb and resource, with parameters spelled out. It distinguishes from list-style siblings like congress_committees, though not from the more specialized congress_committee_details_by_congress.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool vs. alternatives such as congress_committees, congress_committee_details_by_congress, or congress_committee_full_profile. The context is only implied (use when you have a chamber and committee code).

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

• congress_hearing_detailsB
  3.4/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, so the safety profile is known. The description adds useful context about the returned content (title, date, committees, etc.), but does not disclose any further behavioral traits such as pagination, rate limits, or potential empty results. It neither contradicts nor significantly extends beyond the annotation.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently communicates the tool's purpose and main output fields. Every phrase adds value and there is no redundant information.

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

  Completeness4/5

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

  With no output schema, the description carries the burden of conveying what the tool returns. It lists several key fields ('title, date, committees, associated meeting, citation, and available text formats'), which gives a solid understanding of the response. However, it uses 'including' suggesting a non-exhaustive list and omits any error-condition or edge-case behavior, leaving slight gaps.

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

  Parameters3/5

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

  Schema coverage is 100% with each parameter (chamber, congress, jacket_number) having a description. The tool description does not add extra meaning or clarify parameter formats beyond the schema, so the baseline of 3 applies.

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

  Purpose4/5

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

  The description clearly identifies the tool's purpose: fetching detailed information for a single hearing, with a specific verb ('Get') and resource ('specific hearing'). It lists the included data categories (title, date, committees, etc.), which distinguishes it from list-oriented siblings like congress_hearings, though it doesn't explicitly name an alternative.

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

  Usage Guidelines2/5

  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. It does not mention prerequisites (e.g., needing a jacket number), context for selection, or cases where another tool would be more appropriate, leaving the agent without decision support.

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

• congress_house_communicationsB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint: true annotation already signals the tool is a safe read operation. The description adds a list of communication types, which is more relevant to parameter semantics than to behavioral traits. It does not disclose any additional behaviors such as pagination, default limits, or what happens when no filters are supplied, but no contradiction exists.

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

  Conciseness5/5

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

  Two compact sentences currently lead with the core action ('List House communications') and then clarify the types. No wasted words, and the structure is easy to parse quickly.

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

  Completeness4/5

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

  For a simple read-only list tool with three optional parameters and no output schema, the description provides enough context to understand the tool's purpose and the meaning of the type filters. It could mention the return format or behavior with no parameters, but these are not critical gaps given the schema and annotations.

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

  Parameters3/5

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

  The input schema already covers all three parameters with complete descriptions, including the enum values. The description repeats the enum meanings without adding new information, so it does not materially improve upon the schema. Baseline of 3 is appropriate given the high schema coverage.

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

  Purpose4/5

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

  The description clearly states the tool lists House communications and enumerates the four types. It is specific about the resource and verb, but it does not explicitly distinguish itself from sibling tools like congress_house_communication_details, which likely handles individual communication details.

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

  Usage Guidelines2/5

  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. There is no mention of when not to use it, no indication of preferred scenarios, and no alternative tool names are referenced. For an API with many closely related Congress tools, this omission limits discoverability.

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

• congress_treaty_detailsB
  3.4/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, and the description is consistent with this. The description adds context about the response content (Senate actions) but does not disclose any operational constraints, rate limits, or limitations. This meets the lowered bar set by annotations without going beyond it.

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

  Conciseness5/5

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

  The description is a single, direct sentence that front-loads the verb and resource ('Get detailed information about a specific treaty') and concisely lists the key content included. There is no redundant or verbose language.

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

  Completeness4/5

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

  For a simple two-parameter, read-only details endpoint, the description adequately conveys the purpose and the key content. It does not mention return format or examples, and could clarify its relationship to the full-profile sibling, but overall it is sufficient for an agent to select and invoke the tool.

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

  Parameters3/5

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

  The input schema fully describes both required parameters (congress and treaty_number) with clear descriptions, covering 100% of parameters. The description does not add parameter-level detail, but since the schema already documents them, 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.

  Purpose4/5

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

  The description clearly states the tool retrieves detailed information on a specific treaty and enumerates the Senate actions included. It distinguishes the tool from listing-focused siblings like congress_treaties by focusing on detailed per-treaty info, but does not explicitly differentiate from the similarly named congress_treaty_full_profile.

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

  Usage Guidelines2/5

  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 compared to related congress_treaty_* tools, such as congress_treaty_full_profile or congress_treaty_partitioned_details. There is no mention of selection criteria, alternatives, or exclusions.

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

• eia_electricityB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals a safe read operation, and the description adds useful context about sector codes and data type units. However, it does not disclose default date ranges, pagination behavior, or response structure, which would be valuable beyond the annotations.

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

  Conciseness4/5

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

  The description is concise and front-loaded with the main purpose, followed by two efficient list-like lines for sectors and data types. Every sentence adds value, with no redundant fluff.

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

  Completeness3/5

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

  The tool has 8 optional parameters and no output schema, so the description needs to explain return behavior. It provides sector and data type explanations, but lacks information about response structure, defaults, and pagination. The 'generation' inconsistency also leaves a gap in expected data types.

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

  Parameters3/5

  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 units for revenue (M$), sales (MWh), and customers, and expands sector codes to full names, but it also introduces 'transportation (TRA)' which is not in the schema enum, and 'generation' which is not a data_type option, slightly undermining clarity.

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

  Purpose4/5

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

  The description clearly states the tool retrieves electricity retail prices, generation, or consumption by state and sector, which distinguishes it from sibling EIA tools like eia_petroleum and eia_natural_gas. However, it mentions 'generation' but the data_type schema only supports price, revenue, sales, and customers, creating slight ambiguity.

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

  Usage Guidelines3/5

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

  The description implies usage for electricity data queries by listing sectors and data types, but it does not explicitly state alternatives or when not to use this tool. With siblings like eia_state_energy and eia_total_energy, more explicit guidance would help.

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

• nasa_donkiB
  3.4/5.0
  Behavior2/5

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

  The annotation readOnlyHint=true already covers the safety profile, and the description adds minimal behavioral context. It does not mention response format, pagination, default behavior when parameters are omitted, or any other operational characteristics. Since the annotation already handles the core safety trait, the description contributes little beyond that.

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

  Conciseness5/5

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

  Two short sentences deliver the core purpose and the valid event types. There is no fluff, and the most important information is front-loaded. Every word earns its place.

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

  Completeness3/5

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

  The tool has no output schema, so the description carries the burden of explaining what the response contains, but it does not mention the return shape or default date behavior. It is adequate for a simple query tool with clear parameters, but leaves gaps about expected results and default parameter handling.

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

  Parameters4/5

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

  The schema has 100% coverage with descriptions for all three parameters. The description adds meaningful value by listing the full set of event types (CME, CMEAnalysis, GST, IPS, FLR, SEP, MPC, RBE, HSS, notifications), which is more complete than the schema's type description. This helps the agent understand valid values beyond what the schema provides.

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

  Purpose4/5

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

  The description uses a specific verb+resource ('Get space weather events from NASA DONKI') and lists the supported event types, clearly distinguishing it from other NASA tools like nasa_neo or nasa_mars_photos. It could be more explicit about the response being a list of events, but it is generally clear.

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

  Usage Guidelines3/5

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

  The description implies usage context—it is the tool for NASA DONKI space weather events—but does not explicitly state when to use it over siblings like swpc_alerts or swpc_kp_index. No exclusions or alternative recommendations are provided, leaving the agent to infer from the source name and type list.

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

• ofac_sdn_listB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the read safety is covered. The description adds that it 'returns top entries' and is a 'large list,' providing useful behavioral context about output size, though it leaves 'top' undefined and does not explain ordering or default return count.

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

  Conciseness5/5

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

  Three short, front-loaded sentences with no filler. Each sentence adds distinct information: what it gets, what it returns, and how to control size. The description is efficient and easy to scan.

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

  Completeness3/5

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

  For a one-parameter read-only tool with no output schema, the description is adequate but leaves ambiguity about 'top entries' and lacks comparison to related OFAC tools. It does not clarify whether results are sorted, paginated, or what fields entries include, but the essence is captured.

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

  Parameters4/5

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

  The schema covers the single 'limit' parameter with a clear description, and the description reinforces its purpose by saying the list is large and that limit controls size. This adds meaning beyond the basic schema by explaining why the parameter matters in practice.

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

  Purpose4/5

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

  The description clearly states the action ('Get') and resource ('OFAC SDN list'), and adds context that it is 'primary U.S. sanctions targets.' It does not explicitly contrast with sibling tools like ofac_search or ofac_consolidated_list, but the purpose is specific enough to distinguish the SDN list from other OFAC-related tools.

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

  Usage Guidelines2/5

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

  No when-to-use vs alternatives guidance is provided; there is no mention of ofac_search, ofac_filter, or ofac_consolidated_list. The only usage tip is 'Large list; use limit to control size,' which addresses the limit parameter, not tool selection.

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

• os_industry_totalsB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds context about what the totals include (PACs and individual contributions), which is useful but does not describe output format, limitations, or other behavioral traits. The bar is lower due to annotations, and the description meets it minimally.

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

  Conciseness5/5

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

  Two sentences, no wasted words. The key information (what it does, scope) is front-loaded. Every sentence adds value.

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

  Completeness4/5

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

  For a simple two-parameter tool with readOnlyHint and no output schema, the description explains the purpose and gives a hint about the return structure (per sector, PAC/individual amounts). It is adequate for selection and invocation, though it could mention the granularity (e.g., sectors are grouped by industry) explicitly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameters cid and cycle are already fully documented. The description does not add additional param-level meaning beyond restating that it's for a candidate. Baseline of 3 applies.

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

  Purpose4/5

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

  The description uses a specific verb ('Get') and a clear resource ('industry contribution totals for a candidate'). It adds detail about PACs and individuals, making the tool's scope clear. It does not explicitly name sibling tools to differentiate, but the specificity is sufficient.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives like os_candidate_summary or lobbying_contributions. The description only states what the tool does, without indicating preferred use cases or exclusions.

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

• state_economyB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description adds content scope (GDP, employment, etc.) but no deeper behavioral traits such as whether results are aggregated, the data source vintage, rate limits, or that the 'May include' list is non-exhaustive. The added value is modest beyond the annotation.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the primary purpose, followed by a useful list of data categories and a cross-referencing note. No wasted words or redundant restatements of the name.

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

  Completeness2/5

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

  No output schema exists, and the description does not clarify what the returned records contain, their structure, or how to filter effectively (e.g., time series versus cross-sectional). The vague 'May include' list leaves the agent uncertain about coverage, and the cross-reference note does not compensate for the lack of explanation about the query semantics (q, where filters).

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

  Parameters3/5

  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; all four parameters (q, limit, state, where) have descriptions in the schema. The tool description does not add extra semantic detail about the parameters, only restating 'US state' which aligns with the 'state' parameter.

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

  Purpose4/5

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

  The description clearly states the tool queries economic data for a US state and lists broad categories (GDP, employment, workforce, tax, income) with the verb 'Query' and resource 'economic data for a US state.' However, it does not differentiate itself from sibling tools like bea_gdp_by_state or bls_employment_by_industry, which also provide economic data; the mention of federal tools is for cross-referencing, not distinction.

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

  Usage Guidelines3/5

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

  The description implies usage for state-level economic queries and suggests cross-referencing federal BEA/BLS tools for national context, which provides a partial guideline. However, it does not explicitly state when to choose this tool over the many economic sibling tools (e.g., bea_gdp_by_state) or provide any exclusions or alternative conditions.

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

• census_queryA
  3.5/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already communicates the read-only nature. The description adds context by stating that it returns data for specified variables and geography, and it names supported datasets. It does not disclose response format, pagination, rate limits, or error behavior, which would add further transparency.

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

  Conciseness4/5

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

  The description is compact and front-loaded: the first sentence states the core purpose, and the following list supplies high-value examples without unnecessary filler. It is not as minimal as a two-sentence high benchmark, but every sentence earns its place.

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

  Completeness3/5

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

  With no output schema, the description only minimally states that data is returned for specified variables and geography; it does not clarify the response structure or limits. It does provide enough setup for common queries, but an agent might still be uncertain about multi-geography filters or output parsing for this complex API.

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

  Parameters4/5

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

  The input schema already provides descriptions and examples for all parameters, giving 100% coverage. The description adds valuable domain-specific examples like '2023/acs/acs1' and 'B01001_001E' that go beyond the schema, helping the agent select valid dataset paths and variable codes.

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

  Purpose4/5

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

  The description clearly identifies the tool's resource (U.S. Census Bureau Data API) and action ('Query'), and lists supported datasets and example variable codes, making the purpose concrete. However, it does not explicitly differentiate itself from sibling tools like census_population or census_search_variables, so it stops short of a 5.

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

  Usage Guidelines3/5

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

  The description provides practical usage hints through common dataset paths and variable examples, implying this is the general-purpose Census query tool. It does not explicitly state when to use this tool versus alternatives or when not to use it, so the guidance remains only implicit.

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

• cms_nursing_homesA
  3.5/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint: true, and the description's 'Query' verb aligns with that. The description adds content scope (ratings, quality, deficiencies) and a filtering hint, but it doesn't disclose behavioral traits like pagination, rate limits, or result size. It does not contradict annotations.

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

  Conciseness5/5

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

  A single sentence under 20 words, front-loaded with the verb and resource. Every word is relevant and there is no filler.

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

  Completeness3/5

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

  With no output schema and three optional parameters, the description gives a general overview but doesn't explain how the dataset parameter changes the result shape, whether results are lists or records, or how the listed content areas map to the three dataset enum values. It is adequate but has clear gaps.

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

  Parameters3/5

  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, including an enum for dataset. The description adds a mention of state filtering and a high-level summary of data categories, but that is only marginal value beyond the schema's own descriptions.

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

  Purpose4/5

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

  The description clearly identifies the tool's purpose as querying CMS nursing home data with specific content areas (five-star ratings, quality measures, health deficiencies/citations). It distinguishes the resource from sibling tools like cms_hospitals but does not explicitly name alternatives or contrast with generic cms_search.

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

  Usage Guidelines3/5

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

  The description implies use when nursing home data is needed, but it provides no explicit guidance on when to choose this tool over siblings such as cms_hospitals or cms_search. There are no exclusions or alternative tool references.

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

• congress_treaty_partitioned_detailsA
  3.5/5.0
  Behavior2/5

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

  Annotations provide readOnlyHint=true, so the description does not need to restate read-only behavior. However, it adds no information about return format, error handling, or what 'details' include. The description mainly clarifies the resource type rather than disclosing tool behavior beyond the annotations.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the primary action and followed by a brief clarifying sentence. There is no wasted wording, and it is easy to parse.

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

  Completeness3/5

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

  Given the tool has no output schema, the description could have mentioned what details are returned or any edge cases. It is adequate for a simple read tool with well-described required parameters, but could be more complete with additional context about the output or relationship to other treaty tools.

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

  Parameters3/5

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

  Schema descriptions already cover all three parameters (100% coverage), so the baseline is 3. The description adds context about why suffix is needed (partitioned treaties) but does not provide additional format or semantics beyond what the schema already states.

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

  Purpose5/5

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

  The description clearly states the action ('Get details') and specific resource ('partitioned treaty'), and explains what a partitioned treaty is (one with a suffix letter). This distinguishes it from sibling tools like congress_treaty_details, which presumably handles non-partitioned treaties.

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

  Usage Guidelines3/5

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

  The description implies usage for treaties with suffix letters, but does not explicitly mention when not to use it or recommend alternatives like congress_treaty_details for non-partitioned treaties. The usage context is implied but not clearly stated.

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

• epa_enforcementA
  3.5/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes that this is a safe read operation, and the description adds context about case types and returned fields. However, it does not disclose pagination behavior, rate limits, data freshness, or any side effects, so it provides only moderate additional transparency beyond annotations.

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

  Conciseness4/5

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

  The description is 4 sentences and front-loads the main purpose, with concrete return fields and case types. The cross-reference tip is somewhat tangential but adds useful direction without major bloat.

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

  Completeness4/5

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

  For a read-only search tool with well-documented parameters and a simple schema, the description covers the key aspects: purpose, case types, output fields, and related data sources. No output schema is present, but the description's list of returned fields compensates reasonably.

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

  Parameters3/5

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

  All three parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds some context about case types but does not directly explain the law, state, or limit parameters beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly identifies the tool as searching EPA enforcement cases, specifying civil and criminal actions with penalties, settlements, and outcomes. It lists case types ('JDC' and 'AFR') and distinguishes it from sibling tools like epa_facilities or epa_toxic_releases, which focus on other EPA data.

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

  Usage Guidelines2/5

  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, and does not mention exclusions or prerequisites. It merely describes the tool's capabilities, leaving the agent to infer appropriate usage from the name and schema.

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

• fbi_lesdcA
  3.5/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares the operation is read-only, so the description does not need to restate that. However, the description adds the list of chart types, which clarifies the scope of queries. It does not disclose response format, pagination, or any special constraints beyond the annotation, so it remains at a baseline level.

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

  Conciseness4/5

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

  The description is concise, with a clear first sentence and a useful list of chart types. The list is slightly lengthy but all items are legitimate enum values, so it earns its place. No redundant filler or repetition.

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

  Completeness4/5

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

  For a simple read-only statistics tool with two parameters and no output schema, the description covers the core purpose and parameter domain. It lacks details on return values or example usage, but the provided annotations and schema fill most gaps, making it sufficiently complete for straightforward queries.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both 'year' and 'chart_type' described in the schema. The description reiterates the chart type enum values, which adds no new meaning beyond the schema. The 'year' parameter is not elaborated in the description, so value is minimal; baseline 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool retrieves Law Enforcement Suicide Data Collection (LESDC) statistics, using a specific verb ('Get') and resource. It distinguishes from FBI siblings (fbi_agencies, fbi_crime_summarized) by naming this unique dataset and listing supported chart types, making the purpose unmistakable.

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

  Usage Guidelines2/5

  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. With many FBI sibling tools, the description does not explain when LESDC is appropriate or mention other FBI datasets for different statistics. The only implicit signal is the tool name and dataset name, which is insufficient for tool selection.

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

• fred_release_dataA
  3.5/5.0
  Behavior3/5

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

  With readOnlyHint=true, the description adds 'bulk' to imply multiple series are returned, but it does not describe the output structure, pagination, or limits. The common ID list is operational context, not behavioral, so it adds minimal value beyond annotations.

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

  Conciseness5/5

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

  Two short lines; the first line states the purpose, the second provides relevant examples. No wasted words, front-loaded.

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

  Completeness3/5

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

  For a 2-param tool with no output schema, the description is adequate but doesn't explain what the response contains or how the release relates to series data. It lacks alternative tool guidance and return format, leaving agents to infer behavior.

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

  Parameters3/5

  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 example release IDs (53, 50, 10, 18) beyond the schema's single example, but the 'limit' param semantics ('Max obs') remain ambiguous and the description doesn't clarify.

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

  Purpose4/5

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

  The description states a clear action ('Bulk fetch') and resource ('a FRED release'), with examples of common release IDs. It does not explicitly differentiate from sibling FRED tools like fred_series_data or fred_search, but the resource scope (release vs series) is implicitly clear.

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

  Usage Guidelines3/5

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

  The description implies it's used for fetching all data for a specific release and provides common release IDs, but it doesn't state when to prefer this over fred_search or fred_series_data, nor does it mention any prerequisites like knowing the release ID.

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

• loc_newspaper_titlesA
  3.5/5.0
  Behavior3/5

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

  The annotations include readOnlyHint=true, so the read-only nature is already disclosed. The description adds context that this is a search over Chronicling America, but does not mention behavior like pagination, result formats, or limitations. With annotations covering safety, a 3 is appropriate.

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

  Conciseness5/5

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

  The description is two concise sentences with no wasted words. It fronts the main purpose and immediately elaborates with the search dimensions. Extremely efficient.

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

  Completeness3/5

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

  For a read-only search tool with three optional parameters and no output schema, the description adequately conveys the core function. However, it does not mention what types of results are returned (e.g., full title records, publication details), nor does it clarify interaction with sibling loc tools, leaving a small completeness gap.

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

  Parameters3/5

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

  The input schema already covers 100% of parameters with descriptions ('City name', 'U.S. state name', 'Search terms for newspaper name'). The description restates these via 'by name, state, or city' but adds no extra semantic detail beyond the schema.

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

  Purpose4/5

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

  The description clearly states the tool searches newspaper titles in Chronicling America, and clarifies it finds newspapers by name, state, or city. This distinguishes it from sibling tools like loc_newspaper_search, which likely searches newspaper content, though the differentiation is subtle and not explicitly stated.

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

  Usage Guidelines3/5

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

  The description implies the tool is used when looking up newspapers by name, state, or city. However, it does not explicitly state when to use this tool over alternatives such as loc_newspaper_search or loc_search, nor does it mention any exclusions or prerequisites.

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

• md_bay_latestA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds useful context about the specific measurements returned, but does not disclose units, data freshness, station coverage quirks, or error behavior. It provides some value beyond annotations but not a full behavioral picture.

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

  Conciseness4/5

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

  The description is three sentences: purpose, returned fields, and station list. Each sentence earns its place, and the most important information is front-loaded. The station list is long but necessary for selecting a valid station. Minor structure improvement could be bulleted stations, but it remains concise.

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

  Completeness3/5

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

  For a simple one-parameter read-only tool, the description gives the essential purpose, sample fields, and stations. However, it omits units (e.g., temperature in °C), the meaning of 'latest' (last observation vs. daily summary), and whether all stations report all fields. Without an output schema, these gaps affect usability.

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

  Parameters4/5

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

  The schema documents the single 'station' parameter with an enum of codes. The description enhances this by mapping each code to a human-readable station name (e.g., 'UP' = Upper Potomac), which is crucial for selecting the correct value. This goes beyond the schema's bare 'Station code' description.

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

  Purpose4/5

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

  The description states a clear action ('Get latest readings') and specific resource ('CBIBS buoy station'), and lists the measurements returned. It implicitly distinguishes from siblings like md_bay_stations and md_bay_historical by focusing on 'latest' data, but does not explicitly name alternatives, so it doesn't fully reach the top score.

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

  Usage Guidelines3/5

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

  The description implies usage when current buoy readings are needed, but provides no explicit guidance on when to use this tool vs. alternatives like historical data or station lists. There are no exclusions or conditional use cases mentioned.

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

• naep_scoresA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint: true, so the safety profile is covered. The description adds that it 'Returns average scale scores,' which is a useful behavioral disclosure, but it does not cover data freshness, rate limits, or response structure. The rest of the description focuses on parameter values rather than behavioral traits.

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

  Conciseness5/5

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

  The description is front-loaded with the purpose and then structured using labeled lines for Subjects, Grades, Variables, and Jurisdiction. It is compact, with no redundant prose, and each line provides quick-reference value for the most important parameters.

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

  Completeness3/5

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

  With 8 parameters and no output schema, the description covers the core concepts (subjects, grades, variables, jurisdiction) but omits key parameters such as year, subscale, stat_type, and categoryindex. It also states 'Returns average scale scores' without acknowledging that stat_type can produce other statistics (e.g., row percentages, achievement levels), so the description is not fully complete for the tool's actual capabilities.

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

  Parameters3/5

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

  The input schema has 100% coverage, including detailed descriptions for all 8 parameters. The tool description repeats the subjects, grades, variables, and jurisdiction lists in a condensed cheat-sheet format, but adds no new semantic meaning; it even omits some schema details like the 'XN'/'XC' jurisdiction codes and the stat_type, subscale, and categoryindex parameters, making it less comprehensive than the schema.

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

  Purpose4/5

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

  The description clearly states 'Get NAEP test scores' and specifies that it returns average scale scores by subject, grade, state, and demographic group. This is specific and unambiguous, but it does not explicitly differentiate from sibling NAEP tools like naep_compare_years or naep_achievement_levels, so it falls short of a 5.

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

  Usage Guidelines3/5

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

  The description implies usage by framing this as the go-to tool for retrieving raw test scores, but it never explicitly states when to use this versus alternatives. It lists parameter values and scopes, giving clear context on what the tool accepts, yet offers no exclusions or alternative tool references, so guidance is only implicit.

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

• noaa_locationsA
  3.5/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes that this is a safe read-only operation, and the description's 'Search' aligns with that. However, the description adds little beyond the annotation—no mention of pagination, defaults, or response format—so it provides minimal additional 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.

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the action, resource, examples, and purpose. Every word earns its place.

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

  Completeness3/5

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

  The tool is simple, with rich schema coverage and a read-only annotation, but the description does not mention output format or that calling it without parameters returns all locations. It leaves some context for the agent to infer, but it is adequate for a basic search tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameter descriptions in the schema handle the details for limit, category, and dataset_id. The description adds examples like 'states, cities, countries' that map to category enum values, but no extra 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.

  Purpose4/5

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

  The description clearly states the tool's function: 'Search NOAA location IDs' with examples 'states, cities, countries' and explicitly ties it to 'use with other NOAA tools,' distinguishing it from sibling tools like noaa_stations. It lacks explicit differentiation from all possible alternatives but is specific enough to be more than vague.

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

  Usage Guidelines3/5

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

  The phrase 'for use with other NOAA tools' implies when to use this tool (as a lookup before other NOAA queries) but does not explicitly state when not to use it or name alternatives. No exclusions or alternative tools are mentioned, leaving the guidance at an implied level.

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

• noaa_stationsA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the description is not burdened with safety disclosure. The description adds no extra behavioral context (e.g., pagination, result format, rate limits), but it does not contradict annotations either.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose, followed by a concrete usage example. Every sentence adds value, and there is no unnecessary filler or redundancy.

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

  Completeness3/5

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

  The tool is a simple search with three optional params and no output schema. The description covers the search intent but does not describe return values or clarify that at least one filter (location or dataset) may be needed. Annotations and schema cover safety and params, but the missing output schema leaves some ambiguity.

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

  Parameters3/5

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

  Schema description coverage is 100%, already documenting all three parameters. The description's location ID examples are redundant with the location_id schema description, adding no new semantic information beyond what the schema provides.

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

  Purpose4/5

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

  The description clearly states the action ('Search') and resource ('NOAA weather stations'), with specific examples of location IDs. It distinguishes from siblings like noaa_locations and noaa_datasets, but does not explicitly distinguish from other station search tools (e.g., nws_stations, coops_stations).

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

  Usage Guidelines3/5

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

  The description provides usage examples for location_id format (FIPS:36, CITY:US360019), implying how to use the tool. However, it does not offer explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.

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

• nws_forecast_hourlyA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so no need to restate that. The description adds behavioral context beyond annotations by specifying the return data (hourly periods with temperature, wind, and conditions) and the auto-resolve behavior for lat/lon. However, it does not mention rate limits, error conditions, or other operational nuances, so it 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.

  Conciseness5/5

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

  The description is three sentences, front-loaded with the primary purpose, and each sentence provides necessary information: the type of forecast, the two parameter alternatives, and the return fields. No word is wasted, and it is easy to scan.

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

  Completeness3/5

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

  With no output schema, the description carries the burden of explaining return values. It names the return fields (temperature, wind, conditions) but lacks details like units, timezone, or forecast period count. It also assumes the user knows what a 'point lookup' is, though that is reasonable given the sibling tool nws_point_lookup. Overall, it is functional but leaves some ambiguity.

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

  Parameters3/5

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

  The input schema already describes all 5 parameters with 100% coverage, including clues like 'auto-resolves grid if office not provided.' The description reinforces the EITHER/OR relationship between parameter groups, which is somewhat redundant but helpful. It does not add meaningfully beyond the schema, so a baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool's function: get hourly weather forecast. It specifies the resource (NWS) and the verb (get), and the word 'hourly' distinguishes it from the related nws_forecast tool. However, it does not explicitly name or differentiate from sibling tools like nws_forecast, so it falls short of a 5.

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

  Usage Guidelines3/5

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

  The description provides detailed guidance on how to invoke the tool: either use (office + grid_x + grid_y) from a point lookup, or use (latitude + longitude) to auto-resolve. This is clear invocation context, but it does not discuss when to use this tool versus alternatives (e.g., nws_forecast for non-hourly forecasts). The guidance is implied but not explicit about competition between tools.

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

• regulations_docket_detailA
  3.5/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds no further behavioral context, such as what fields are returned, whether it can fail for invalid IDs, or related constraints. It does not contradict annotations.

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

  Conciseness5/5

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

  A single, front-loaded sentence that immediately states the operation and input. No filler or redundancy.

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

  Completeness3/5

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

  For a simple single-parameter tool, this is minimally sufficient, but it lacks detail about what 'detailed information' includes or how to discover docket IDs if unknown. A short note about the return content would improve completeness.

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

  Parameters3/5

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

  The input schema fully documents docketId with the same example ('EPA-HQ-OAR-2003-0129'). The description adds no semantic value beyond the schema's parameter description.

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

  Purpose5/5

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

  The description uses a specific verb ('Get') and resource ('detailed information for a specific regulatory docket') plus the required identifier ('by its docket ID'). It clearly distinguishes from sibling tools like regulations_document_detail and regulations_search_dockets.

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

  Usage Guidelines3/5

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

  The description implies usage when the agent has a known docket ID, but it does not explicitly state when to use this tool over alternatives, such as searching for dockets first. No exclusions or alternative tool names are mentioned.

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

• scorecard_topA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds context on what each ranking value means (e.g., earnings = median pay 10 years after entry), but does not disclose other behavioral traits like default sorting or result structure.

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

  Conciseness4/5

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

  The description is concise, front-loaded, and uses two sentences effectively. The minor inconsistency between 'lowest cost' and 'expensive' prevents a perfect score.

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

  Completeness3/5

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

  The description is adequate for a simple list tool but does not explain the response format or clarify the 'lowest cost' vs 'expensive' discrepancy. It also does not provide guidance on combining with other scorecard tools.

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

  Parameters4/5

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

  Schema coverage is 100% for all parameters, and the schema describes each field. The description adds valuable semantics for the ranking enum by explaining the meaning of each option, which the schema does not provide.

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

  Purpose4/5

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

  The description clearly states the tool gets top-ranked colleges and explains the ranking metrics, distinguishing it from search/query/compare siblings. However, the phrase 'lowest cost' conflicts with the actual 'expensive' option, causing minor ambiguity.

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

  Usage Guidelines3/5

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

  The description implies usage for retrieving ranked lists and defines the ranking options, but it does not explicitly state when to prefer this over scorecard_search or scorecard_compare, nor does it mention any exclusions.

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

• state_healthA
  3.5/5.0
  Behavior3/5

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

  Annotations include readOnlyHint=true, so the tool is already marked as safe. The description adds useful behavioral context by noting that data 'may include' certain indicators and that 'Data availability varies by state,' which warns the agent about conditional results. However, it does not describe what happens when a state has no data, how to handle pagination, or the structure of the response.

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

  Conciseness5/5

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

  The description is three sentences with no fluff. The first sentence gives the core action, the second clarifies content, and the third warns about variability. Every sentence earns its place, and key information is front-loaded.

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

  Completeness3/5

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

  With no output schema and only high-level categories listed, the description doesn't indicate what a returned row looks like or how data is organized. The readOnlyHint and simple query parameters reduce the need for deep explanation, but the tool still lacks detail about result fields, especially since availability varies by state. It is marginally adequate but leaves the agent guessing about the exact output.

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

  Parameters3/5

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

  Schema description coverage is 100%, so every parameter (state, q, limit, where) is minimally documented in the schema. The tool description does not add any additional meaning or usage examples for the parameters; it relies entirely on the schema. This meets the baseline for high coverage but doesn't enhance it.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Query health indicator data for a US state.' It enumerates example data types (disease rates, overdose deaths, infant mortality, immunization, hospital data), making its scope concrete and distinguishing it from sibling state_* tools like state_crime or state_education.

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

  Usage Guidelines2/5

  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. It doesn't name any sibling tools (e.g., CDC health tools or other state_* categories) or explain when one should be chosen over another. The only caveat, 'Data availability varies by state,' hints at a limitation but does not offer selection advice.

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

• usa_spending_by_awardA
  3.5/5.0
  Behavior3/5

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

  The annotations provide readOnlyHint=true, so the read-only nature is covered. The description adds useful context about award type groups and code mappings, but does not disclose other behavioral traits such as pagination limits, rate limits, or whether results are sorted by default. It neither contradicts annotations nor adds rich behavioral detail.

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

  Conciseness5/5

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

  The description is two short paragraphs: the first states the purpose and main filter dimensions, the second explains award type mappings. It is front-loaded, with no filler or redundant information, and every sentence earns its place.

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

  Completeness4/5

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

  Given 12 parameters, no required fields, and no output schema, the description provides the essential filters and award type mappings. However, it does not describe the response format or pagination behavior, which could be relevant for agents. Overall, it is reasonably complete for a search tool with high schema coverage.

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

  Parameters4/5

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

  The input schema covers all 12 parameters with descriptions (100% coverage), so the baseline is 3. The description adds significant extra value by mapping human-readable award types to their underlying codes (e.g., 'contracts' to 'A,B,C,D'), which is not present in the schema and helps agents construct correct queries.

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

  Purpose4/5

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

  The description clearly states the tool searches federal spending awards and lists the specific award types (contracts, grants, loans, direct payments). The verb 'Search' and resource are explicit, but it does not explicitly contrast with sibling tools like usa_spending_by_agency or usa_spending_by_recipient, leaving some differentiation to the name.

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

  Usage Guidelines2/5

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

  No explicit guidance explains when to use this tool versus the many sibling spending tools. The description mentions filters but does not state that this is for award-level search as opposed to aggregated views, nor does it provide any when-not-to-use or alternative suggestions. Users must infer usage from the tool name.

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

• usda_crop_dataA
  3.5/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes the read-only nature. The description adds the data categories and commodity list, which is useful, but does not disclose response format, pagination, or any default behaviors beyond what the schema states. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is two sentences long and immediately leads with the verb and resource. The commodity list is terse and informative, with no extraneous words.

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

  Completeness4/5

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

  Given the tool has four parameters and no output schema, the description adequately conveys the available crop production categories and commodity scope. It relies on the schema for year/state/category details, which is acceptable. It could be enhanced by noting the default category, but overall it is sufficiently complete for a simple query tool.

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

  Parameters4/5

  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 value by listing SORGHUM as a valid commodity, which is missing from the schema's commodity description, and by reiterating the category options. This extra enumeration helps disambiguate valid values.

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

  Purpose4/5

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

  The description clearly states 'Get crop production data' and enumerates specific metrics (area planted, harvested, production, yield) and commodities, making the tool's purpose unambiguous. It distinguishes from USDA siblings like usda_prices and usda_livestock by focusing on production data, though it does not explicitly reference those alternatives.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus USDA alternatives such as usda_prices, usda_livestock, or usda_ag_query. The description only says what it does, not when it should be preferred over other crop-related tools.

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

• bls_cpi_breakdownA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the bar is lower. The description adds context about component breakdowns and identifying inflation drivers, but doesn't disclose other behavioral traits such as data frequency, geographic scope, or response format.

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

  Conciseness5/5

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

  Two concise sentences with a clear front-loaded action and resource. The dash and examples add useful detail without fluff, making it highly efficient.

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

  Completeness4/5

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

  For a simple read-only lookup with two well-documented parameters and no output schema, the description sufficiently conveys what the tool does and its purpose. It lacks explicit output format details but is adequate for selection and invocation.

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

  Parameters3/5

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

  Schema provides 100% coverage of both parameters (start_year and end_year) with descriptions and defaults. The tool description adds no additional parameter semantics beyond what the schema already specifies.

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

  Purpose4/5

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

  Clearly states it gets a breakdown of Consumer Price Index by component, listing specific categories (food, shelter, energy, etc.). This distinguishes it from generic BLS sibling tools like bls_series_data, though it doesn't explicitly name alternatives.

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

  Usage Guidelines3/5

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

  Implies usage when component-level CPI detail is needed ('Shows which categories are driving inflation'), but provides no explicit when-to-use vs alternatives, nor any exclusion criteria.

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

• congress_amendment_cosponsorsA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes that this is a safe read operation, and the description adds minimal context by noting output fields. However, it does not disclose behaviors like pagination, default limit of 250, or response structure, so it sits at the baseline enabled by the annotation.

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

  Conciseness5/5

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

  The description is two short sentences with no filler. It front-loads the core action ('Get cosponsors of a specific amendment') and then adds a useful output detail, earning a top conciseness score.

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

  Completeness4/5

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

  For a simple, read-only lookup tool with fully documented required parameters and no output schema, the description provides enough for an agent to invoke it correctly. It lacks usage guidance and richer return-value detail, but the schema and readOnlyHint cover most operational needs.

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

  Parameters3/5

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

  Schema description coverage is 100%, with every parameter (congress, amendment_type, amendment_number, limit) having a basic description. The tool description adds no further parameter semantics, so the schema itself carries the weight; no value is added beyond the structured definition.

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

  Purpose5/5

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

  The description clearly states the action ('Get cosponsors') and the specific resource ('of a specific amendment'). It also previews the returned data ('party affiliation and sponsorship details'), which distinguishes it from sibling tools like congress_bill_cosponsors or congress_amendment_details.

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

  Usage Guidelines2/5

  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, nor are any exclusions or prerequisites mentioned. The only implied usage is the need for a specific amendment's identifiers, which is already evident from the required parameters.

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

• congress_amendmentsA
  3.6/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, and the description's 'Search/list' and 'Returns' align with a read operation, so no contradiction. It adds the type code meanings (hamdt = House, etc.) and the output fields, but provides no further behavioral details such as pagination, sorting, or default behavior beyond what the schema already indicates.

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

  Conciseness5/5

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

  The description is just two sentences, front-loaded with the core action and scope, and includes the return fields with no unnecessary words or restating of the tool name.

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

  Completeness4/5

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

  The description adequately covers the purpose, key filters, and return fields, which is sufficient for a read-only search tool with a fully documented schema. However, it could be more complete by naming the appropriate alternative for detailed amendment lookup (e.g., congress_amendment_details) or noting pagination/sorting behavior.

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

  Parameters3/5

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

  All 5 parameters are described in the schema (100% coverage), so the description carries a low burden. It does clarify the meaning of the amendment_type enum values and that congress and type are the primary filters, but it adds no additional syntax or semantics for the date/time parameters or limit.

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

  Purpose4/5

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

  The description clearly states 'Search/list amendments by congress and optional type' with a specific verb and resource, and enumerates the amendment type codes. It also lists the return fields. However, it does not explicitly distinguish itself from sibling tools like congress_bill_amendments or congress_amendment_details, so it lacks explicit sibling differentiation.

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

  Usage Guidelines3/5

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

  The implication that this tool is used to search amendments by congress and type is present, but there is no explicit guidance on when to use it versus alternatives. For example, it does not mention that congress_amendment_details would be used for a specific amendment's full detail or that congress_bill_amendments is for amendments within a specific bill.

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

• congress_bill_detailsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description's 'Get' is consistent. The description adds value by specifying the data content, but does not disclose behavior such as response size, pagination, or error conditions. This is a moderate disclosure level, 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.

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the primary action and resource, then lists the key data elements. Every word earns its place; there is no redundancy or verbosity.

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

  Completeness4/5

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

  Given the moderate complexity of a bill details endpoint and the absence of an output schema, the description adequately conveys what the tool returns by listing major components. It could be more exhaustive, but the enumeration of 'including' components covers the primary use case and is sufficient for an agent to understand the tool's scope.

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

  Parameters3/5

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

  Schema description coverage is 100% with each parameter documented (e.g., congress number examples, bill type enum, bill number examples). The description does not add further semantic meaning beyond stating the tool targets 'a specific bill', so it relies on the schema's already adequate parameter descriptions.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with a specific verb ('Get detailed information') and resource ('a specific bill'), and distinguishes it from sibling tools by enumerating the components it returns (sponsors, cosponsors, actions, committees, status). This differentiates it from more focused congress bill sub-resource tools.

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

  Usage Guidelines2/5

  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 like congress_bill_actions or congress_bill_full_profile. It does not mention any exclusions or prerequisites, leaving the agent to infer usage from the description alone.

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

• congress_committee_print_textA
  3.6/5.0
  Behavior3/5

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

  With readOnlyHint=true already declared in annotations, the description adds some value by specifying the return content (formatted text and PDF URLs). However, it does not disclose any limitations, such as scope of availability, pagination, or potential absence of PDF links.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main action, and contains zero superfluous words. It is concise and well-structured.

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

  Completeness4/5

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

  For a simple read-only tool with three clear parameters and an output description, the description is largely sufficient. It lacks explanation of what a committee print is or any edge cases, but these are arguably unnecessary for an agent with basic domain knowledge.

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

  Parameters3/5

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

  Schema coverage is 100% with basic field descriptions, but the description adds no additional meaning beyond the schema. The term 'jacket_number' is left unexplained, and the description does not clarify how to obtain or format the parameters.

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

  Purpose5/5

  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 ('text versions for a committee print'). It also states the return type ('formatted text and PDF URLs'), making its purpose unambiguous and distinct from sibling tools like congress_committee_print_details.

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

  Usage Guidelines2/5

  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 congress_committee_print_details or congress_committee_report_text. There are no explicit exclusions, prerequisites, or conditions for use.

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

• congress_committee_reportsA
  3.6/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already covers the safety profile. The description adds context about what committee reports are and the filtering options, but it does not disclose behavior such as pagination, default limits (though limit is in the schema), or the shape of the returned data. Since the tool is read-only and the schema covers parameters, this is adequate but not rich.

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

  Conciseness5/5

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

  The description consists of three concise, front-loaded sentences: purpose, filter options, and significance. Every sentence provides value, with no filler or redundancy.

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

  Completeness4/5

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

  For a read-only list tool with complete schema documentation and no output schema, the description adequately covers purpose, filterability, and use case. It could add information about the response format or default behavior, but the absence is not a significant gap given the annotations and schema richness.

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

  Parameters3/5

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

  The input schema has 100% description coverage for all six parameters. The description restates the filter fields (congress, report_type, conference) without adding new meaning beyond what the schema already provides, so it falls at the baseline for well-documented schemas.

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

  Purpose4/5

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

  The description clearly states 'List committee reports' and provides a specific definition ('formal reports accompanying legislation reported out of committee'). It does not explicitly distinguish from sibling tools like congress_committee_reports_for_committee or congress_committee_report_details, but the verb and resource are unambiguous.

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

  Usage Guidelines3/5

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

  Usage context is implied through 'Critical for understanding committee intent and legislative history' and the filter options, but the description does not explicitly state when to use this tool versus alternatives such as congress_committee_reports_for_committee or congress_committee_report_details. No exclusionary guidance is provided.

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

• congress_committeesA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description's 'List' action is consistent with a safe read. The description adds return field detail but does not disclose other behavioral traits such as pagination, default congress behavior, 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.

  Conciseness5/5

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

  Two concise sentences front-load the core purpose and include key filters and return fields without wasted words. It is well-structured for quick parsing by an agent.

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

  Completeness4/5

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

  For a simple read-only list tool, the description covers purpose, filters, and return fields, while the schema and annotations fill in parameter details and safety. It does not point to a specific alternative for committee details, but the basic scope is sufficiently clear.

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

  Parameters3/5

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

  All five parameters have descriptions in the input schema, so the high coverage baseline of 3 applies. The description adds little beyond restating congress/chamber filtering and output fields, not substantially improving parameter understanding.

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

  Purpose4/5

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

  The description clearly states the tool lists congressional committees and specifies filters and return fields. It does not explicitly distinguish this from sibling tools like congress_committee_details, but the verb+resource is unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage by naming filter options (congress, chamber) and return fields, but it provides no explicit when-to-use/when-not-to-use guidance or alternatives. With many sibling congress tools, this leaves the agent to infer boundaries.

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

• congress_congressional_recordA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already covers the safety profile, so the description only needs to add behavioral context beyond that. It adds the date-filtering scope but does not disclose edge cases like missing issues for a date, pagination behavior, or whether multiple issues per day are returned. This is adequate but not rich.

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

  Conciseness5/5

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

  The description is two sentences long: the first clearly states the tool's purpose, and the second briefly explains the filtering capability. Every sentence contributes value, and the verb-first structure makes it immediately scannable.

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

  Completeness4/5

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

  Given the readOnlyHint and complete schema, the description provides enough context for a straightforward lookup tool. However, it lacks any mention of how this tool relates to the daily/bound congressional record siblings, and without an output schema, it does not describe the return format. For a simple retrieval tool, this is mostly complete but could be more precise.

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

  Parameters3/5

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

  The schema already describes all four parameters (day, year, limit, month) with 100% coverage, so the baseline is 3. The description rephrases 'filter by year, month, and day' without adding new meaning beyond the schema, and omits the limit parameter entirely, which is documented only in the schema.

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

  Purpose4/5

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

  The description clearly states the tool retrieves Congressional Record issues, identifying it as the official daily record with date-based filtering. However, it does not differentiate this tool from closely related siblings like 'congress_daily_congressional_record' or 'congress_bound_congressional_record', which weakens its distinctiveness among the congress_* tool family.

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

  Usage Guidelines3/5

  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 need Congressional Record issues by year/month/day) but provides no explicit alternatives or exclusions. With many congress-related siblings, the absence of guidance on choosing between this and the daily/bound variants is a clear gap.

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

• fda_device_enforcementA
  3.6/5.0
  Behavior4/5

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

  The description adds behavioral context beyond the readOnly annotation, such as the note that records before June 2012 may lack fields and the inclusion of count fields (voluntary_mandated.exact, classification.exact, status.exact). These details are useful for setting expectations about data availability and aggregation. The readOnlyHint is consistent with the description, so no contradiction.

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

  Conciseness4/5

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

  The description is well-structured with a clear purpose statement, a useful note, and a list of example searches. It is somewhat longer than necessary but every section adds practical value. The front-loading of the main purpose is effective.

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

  Completeness4/5

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

  For a search tool with only two parameters and rich annotations, the description covers key aspects: purpose, classification system, data caveats, example queries, and count fields. It does not describe the return structure, but no output schema exists, and the provided information is sufficient for basic usage. The lack of explicit alternative tool comparison slightly reduces completeness.

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

  Parameters4/5

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

  Although the schema already describes both parameters (100% coverage), the description enhances the 'search' parameter meaning by providing specific field examples (classification, report_date, recalling_firm) and count fields. This goes beyond the generic schema description and gives actionable query patterns.

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

  Purpose4/5

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

  The description clearly states the verb and resource: 'Search FDA device recall enforcement reports.' This is specific and informative. However, it does not explicitly distinguish itself from the sibling tool fda_device_recalls, relying on the term 'enforcement reports' to suggest a distinct dataset.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives like fda_device_recalls or fda_drug_recalls. The provided examples demonstrate search syntax but do not offer usage context or exclusions. This leaves the agent without clear decision criteria for selecting this tool.

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

• fred_series_dataA
  3.6/5.0
  Behavior2/5

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

  The readOnlyHint annotation already establishes that this is a safe read operation. The description adds no additional behavioral context, such as default sort order, limit handling, frequency conversion behavior, or the shape of returned observations. The popular series examples are illustrative, not behavioral.

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

  Conciseness5/5

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

  The description is two short sentences, with the core purpose front-loaded and the examples immediately following. Every word earns its place; there is no redundant or filler content.

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

  Completeness4/5

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

  For a simple read-only data retrieval tool with a fully described schema and a readOnly annotation, this description is adequate. It could clarify the return format of observations and how to find series IDs via fred_search, but the tool name and examples provide enough context for basic invocation.

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

  Parameters4/5

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

  The input schema provides 100% coverage with descriptions for all six parameters, satisfying the baseline of 3. The description adds value by listing concrete popular series IDs like GDP, UNRATE, and CPIAUCSL, which enriches the otherwise generic 'Series ID' schema description.

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

  Purpose5/5

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

  The description opens with the specific verb-object pair 'Get observations for a FRED series,' clearly identifying the tool as a data retrieval operation for time-series observations. This distinguishes it from sibling FRED tools like fred_series_info (metadata) and fred_search (finding series).

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

  Usage Guidelines2/5

  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 fred_series_info or fred_release_data. The popular series examples imply common usage, but the description does not state exclusions, prerequisites, or alternative tool recommendations.

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

• fr_executive_ordersA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already assures safe read-only behavior. The description adds the useful detail that coverage starts in 1994, which helps calibrate expectations, but does not mention pagination behavior, rate limits, or return format. With annotation support, this is adequate but not rich.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the action and resource, and contains no filler. Every clause ('search', 'filter by...', 'covers since 1994') adds useful information. This is exemplary conciseness.

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

  Completeness4/5

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

  The description is complete for a simple search tool: it defines the primary action, the key filter dimensions, and the data coverage window. Full schema documentation fills in parameter details. The lack of an output schema is fine, and the missing response format is not critical for this read-only look-up use case.

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

  Parameters3/5

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

  The input schema provides full descriptions for all five parameters, covering their meanings and defaults. The description's mention of 'filter by president, year, or keyword' simply restates the schema rather than adding new semantic context. Per the rubric, with 100% schema coverage, baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool searches for presidential executive orders and names three filter dimensions (president, year, keyword) plus a coverage scope (since 1994). It is specific about the resource and action, but doesn't explicitly differentiate it from the sibling fr_presidential_documents, which likely covers the same or overlapping content.

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

  Usage Guidelines3/5

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

  The description conveys obvious usage context: when you want to search executive orders, use this tool. However, it provides no explicit guidance about when NOT to use it or which alternative tools (e.g., fr_presidential_documents, fr_search_rules) might be better suited for broader or more specific document types.

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

• govinfo_searchA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals a safe read operation, and the description aligns with that. The description adds context about the scope and collection codes, but does not disclose additional behavioral traits like result format, pagination, or rate limits. With annotations covering safety, this level of detail is acceptable but not exceptional.

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

  Conciseness5/5

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

  The description is compact and front-loaded, with the main purpose stated in the first sentence and collection abbreviations listed in a follow-up line. Every sentence adds value without fluff or redundancy, making it highly readable and efficient.

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

  Completeness4/5

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

  For a search tool with 4 parameters and no output schema, the description gives essential context about what is searched and available collections. It does not detail response structure or pagination, but the scope and collection list are sufficient for a basic search tool. Given it is not overly complex, this feels fairly complete.

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

  Parameters3/5

  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 repeats the collection codes and their expansions (e.g., 'PLAW (public laws)') which the schema already provides, adding minimal new meaning. No extra parameter semantics beyond what the schema covers are provided.

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

  Purpose4/5

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

  The description clearly states the tool searches across all government publications, listing specific collection types (BILLS, PLAW, CRPT, etc.). This identifies the resource and scope, distinguishing it from most sibling tools. However, it does not explicitly contrast with other govinfo-related tools like govinfo_bill_text.

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

  Usage Guidelines3/5

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

  The description implies broad search use case ('Search across all government publications') and enumerates collections, giving context on when this tool is appropriate. It does not provide explicit when-to-use vs. when-not-to-use guidance or name alternative tools, so usage 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.

• lobbying_contributionsA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already communicates the safe read-only nature, so the description doesn't need to repeat that. It adds useful legal context (LDA disclosure requirement) but doesn't disclose operational details such as pagination defaults or how results are ordered, beyond what the schema already conveys.

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

  Conciseness5/5

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

  The description is two sentences, front-loading the primary action in the first sentence and adding a concise legal note in the second. Every word earns its place with no fluff or redundancy.

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

  Completeness4/5

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

  For a read-only search tool with four optional filters and no output schema, the description covers the core functionality and legal context well. It clarifies what results will show, making the tool understandable even without an explicit return format specification.

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

  Parameters3/5

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

  The input schema provides full descriptions for all four parameters (page_size, filing_year, lobbyist_name, registrant_name). The description adds no extra parameter semantics, which is acceptable given the high schema coverage.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Search campaign contributions made by lobbyists' and specifies what it shows (which lobbyists donated to which politicians). This distinguishes it from sibling lobbying tools by focusing on contributions, but it doesn't explicitly name alternative tools or scenarios.

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

  Usage Guidelines3/5

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

  The description implies the tool is for finding lobbyist political contributions, with the LDA requirement providing context. However, it doesn't explicitly state when to use this tool versus related tools like lobbying_search or control_contributions, nor does it provide exclusion criteria.

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

• nvd_cve_searchA
  3.6/5.0
  Behavior4/5

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

  With readOnlyHint: true, the description adds useful behavioral context by disclosing the return fields (CVE IDs, descriptions, CVSS scores, severity levels, publication dates) and valid severity values. It does not mention rate limits or pagination, but it provides value beyond the annotation.

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

  Conciseness5/5

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

  The description is three concise sentences, front-loaded with the main action. Each sentence contributes useful information (action, return fields, valid severity values) with no redundancy or fluff.

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

  Completeness4/5

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

  Given no output schema, the description appropriately lists return fields. It does not mention default limit behavior or that all parameters are optional, but the schema covers those details. Overall, it is adequately complete for a search tool with 5 optional parameters.

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

  Parameters3/5

  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 repeats the severity enum from the schema and mentions filter types, but does not add additional semantic meaning beyond the schema, such as interactions between parameters (e.g., pubStartDate/pubEndDate pairing).

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

  Purpose4/5

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

  The description clearly states the tool searches CVE vulnerabilities with specific filter criteria (keyword, CVSS severity, date range) and lists return fields. It is a specific verb+resource, but it does not explicitly distinguish from the sibling nvd_cve_detail tool, though the naming implies a search vs. detail relationship.

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

  Usage Guidelines2/5

  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. It does not mention nvd_cve_detail or provide context such as 'use this for broad discovery searches' or 'use nvd_cve_detail for a specific CVE.'

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

• nws_text_productsA
  3.6/5.0
  Behavior2/5

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

  The readOnlyHint annotation already covers the safety profile, and the description adds no behavioral context beyond what the schema provides. It does not disclose return format, pagination, error behavior, or any side effects, so it contributes little beyond the structured annotation.

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

  Conciseness5/5

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

  Two short sentences front-load the core purpose and immediately state the required and optional parameters. No filler or redundancy; each sentence earns its place.

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

  Completeness4/5

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

  For a simple two-parameter tool with strong schema coverage and a read-only annotation, the description is sufficient. It communicates the resource, required input, and optional filter, though it does not describe the return format in 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.

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents both parameters. The description's mention of 'requires a product type code' and 'optionally filter by WFO location' repeats schema information without adding new semantics, though the AFD/HWO examples are mildly helpful.

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

  Purpose5/5

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

  The description uses a specific verb ('Get') and a clear resource ('NWS text products'), with concrete examples (AFD, HWO) that distinguish it from sibling NWS tools like forecasts, alerts, observations, and zones. It also notes the required product type code, making the tool's scope immediately identifiable.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool ('Get NWS text products like AFD, HWO, etc.') and mentions the required type plus optional WFO filter, but it does not explicitly state when not to use it or name alternatives. Usage context is present but not fully articulated.

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

• opm_current_statusA
  3.6/5.0
  Behavior4/5

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

  Annotations include readOnlyHint=true, so safety is covered. The description adds behavioral context by specifying the geographic scope (DC area), the types of events covered (weather closures, emergencies), and the return fields (title, summary, messages, posting date). This goes beyond the annotation without contradiction.

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

  Conciseness5/5

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

  The description is concise and well-structured: a purpose sentence, a return-fields sentence, a scope sentence, and an optional-usage sentence. Every sentence provides useful information without redundancy. It is front-loaded with the core purpose.

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

  Completeness4/5

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

  For a simple read-only tool with two optional parameters and no output schema, the description is quite complete: it explains what the tool does, return contents, coverage, and optional historical query. It lacks mention of the timezone default (handled in schema) and related tools, but overall it is sufficient.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both 'date' and 'useutc' already described in the schema. The description repeats the date format and optional nature, but adds no new parameter-level semantics. Baseline 3 is appropriate since the schema carries the burden.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get the current federal government operating status for the Washington, DC area.' It uses a specific verb and resource, and mentions return contents. However, it does not explicitly differentiate from sibling tools like opm_status_history or opm_status_types, despite the name implying 'current.'

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

  Usage Guidelines2/5

  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. It doesn't mention related tools such as opm_status_history or opm_status_types, nor any exclusions or prerequisites. The only implied usage is 'current status' or optional date query, but no comparison context.

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

• sam_opportunitiesA
  3.6/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. However, the description adds no additional behavioral context such as pagination, rate limits, or whether results are sorted. It only restates the search and filter capabilities, which are already visible in the schema.

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

  Conciseness5/5

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

  The description consists of two short, front-loaded sentences with no redundancy. It efficiently conveys the tool's purpose and key filters, making it easy for an agent to parse quickly.

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

  Completeness4/5

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

  For a straightforward read-only search tool with fully documented optional parameters and a readOnlyHint annotation, the description is adequately complete. It covers the core use case and filter options, though it does not describe the return format; this is acceptable given the absence of an output schema and the simplicity of the tool.

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

  Parameters3/5

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

  The input schema has 100% description coverage, providing clear descriptions for all six parameters (e.g., 'Posted before (MM/DD/YYYY)', 'Set-aside type: SBA, 8A, HUBZone...'). The description merely lists the same filter types without adding extra meaning, so it aligns with the baseline score of 3.

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

  Purpose5/5

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

  The description clearly states 'Search federal contract opportunities on SAM.gov', using a specific verb ('Search') and resource ('federal contract opportunities on SAM.gov'). This distinguishes it from sibling tools like sam_entities and sam_exclusions, which also cover SAM.gov but different data types.

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

  Usage Guidelines3/5

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

  The description implies usage for finding federal contract opportunities but does not explicitly state when to use this tool versus alternatives such as sam_entities or USAspending tools. It offers no exclusions or alternative recommendations, so while the context is clear, guidance is limited.

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

• uspto_application_assignmentsA
  3.6/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already signals a safe read operation. The description adds useful info about the returned fields, but does not disclose pagination, error behavior, or rate limits. This is adequate given the annotation coverage, 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.

  Conciseness5/5

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

  Two concise sentences, front-loaded with the purpose and then outlining the output fields. No redundancy or filler, every word earns its place.

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

  Completeness4/5

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

  For a simple one-parameter read-only lookup with no output schema, the description adequately conveys what the tool does and what it returns. It could mention whether multiple assignments are returned or how dates are formatted, but overall it is sufficiently complete for its complexity.

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

  Parameters3/5

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

  Schema coverage is 100% for the single 'application_number' parameter, but the schema description ('Application number') is minimal. The tool description does not add format, examples, or additional meaning, so it does not exceed the schema baseline.

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

  Purpose4/5

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

  The description states a specific verb ('Get') and resource ('assignment (ownership transfer) records for a patent application'), and lists the key fields returned (conveyance type, assignor, assignee, dates). This clearly distinguishes it from sibling USPTO application tools, though it does not explicitly name an alternative as in the high example.

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

  Usage Guidelines3/5

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

  The description implies usage when assignment/ownership transfer records are needed, but it does not explicitly state when to use this tool versus alternatives, nor mention any exclusions. Context is present but guidance is implicit.

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

• bea_gdp_by_industryA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description adds useful context about table ID variants and the Industry='ALL' behavior. However, it does not disclose other behavioral aspects such as default year range, potential data limitations, quirks with quarterly frequency, or response format details.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core purpose. The TableID bullet list is clearly structured and easy to scan. Every sentence contributes to understanding the tool, with no filler or redundancy beyond slight repetition of schema details.

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

  Completeness3/5

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

  With no output schema, the description should clarify return value structure, but it does not. It covers the available parameters and their meanings, but an agent may not know what data fields or formats to expect in the response. The simple read-only query nature and sibling similarity provide some context, so a minimum viable score of 3 is appropriate.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the schema already documents all parameters (year, industry, table_id, frequency) with detailed enumerations. The description only restates table_id options and adds a note about Industry='ALL', which does not materially extend the schema's semantics.

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

  Purpose5/5

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

  The description explicitly states the function: 'Get GDP contribution by industry sector nationally from BEA GDPbyIndustry dataset.' This is a specific verb+resource and scope, clearly distinguishing it from sibling tools like bea_gdp_national and bea_gdp_by_state. The dataset identifier further disambiguates the exact source.

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

  Usage Guidelines3/5

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

  The description implies usage for industry-level GDP data but does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternatives. It explains parameter options (e.g., TableID choices) but not the broader selection context relative to other BEA tools.

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

• bts_transport_statsA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description supplements this with the monthly time-series nature and the fact that some series go back to 1947. However, it does not disclose other behaviors such as output format, pagination, or rate limits, which would be valuable for a 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.

  Conciseness4/5

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

  The description is well-structured with a lead sentence followed by a categorized bullet list. It front-loads the main purpose and each bullet adds distinct information, avoiding redundancy. It is longer than necessary but remains scannable and information-dense.

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

  Completeness4/5

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

  For a tool with no output schema, the description thoroughly covers the data content (50+ indicators) and temporal range. The input parameters are fully documented in the schema. It lacks an explicit statement about the return format, but the overview is strong enough for an agent to understand the tool's scope.

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

  Parameters3/5

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

  Schema descriptions cover 100% of the parameters (limit, start_date, end_date) with clear definitions. The tool description adds little beyond confirming 'Monthly data', so the baseline score of 3 is appropriate given high schema coverage.

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

  Purpose5/5

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

  The description clearly states 'Get Monthly Transportation Statistics' and enumerates over 50 national indicators across multiple categories (airline, transit, rail, trucking, etc.), making the tool's purpose specific and easily distinguishable from siblings like bts_border_crossings which focuses solely on border data.

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

  Usage Guidelines3/5

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

  The description implies the tool is for broad national transportation statistics and notes monthly data since 1947, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. It does not mention sibling tools like bts_border_crossings or nhtsa_model_years, so usage guidance is only implicit.

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

• congress_house_requirement_matching_communicationsA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the description is not responsible for safety disclosure. It adds useful context that the communications are agency submissions for recurring reporting obligations, but it does not mention pagination, return format, or any limitations beyond what annotations already cover.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and contains no filler. Every word adds value.

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

  Completeness3/5

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

  For a simple query tool with read-only annotation and two parameters, the description is adequate but thin. It does not explain what the communications contain, how matching is performed, or what the response looks like—especially relevant since no output schema exists.

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

  Parameters3/5

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

  Schema coverage is 100%: both limit and requirement_number include descriptions in the input schema. The description adds no additional parameter-level meaning, 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.

  Purpose5/5

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

  The description uses a specific verb ('Get') and resource ('communications that match a specific House requirement'), and further clarifies the domain with 'agency submissions fulfilling a recurring reporting obligation.' This clearly distinguishes it from sibling tools like congress_house_communications or congress_house_requirement_details.

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

  Usage Guidelines3/5

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

  The description implies usage when you have a House requirement number, but it does not explicitly state when to prefer this over alternatives such as congress_house_communications, nor does it explain how to find requirement numbers. Context is present but exclusionary guidance is absent.

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

• coops_tide_predictionsA
  3.7/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a safe read operation, so the description does not need to restate that. The description adds some behavioral details like date format and shortcut usage, but it does not describe return value format, pagination, rate limits, or any other operational caveats. No contradictions with annotations.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose, and every sentence earns its place. It is concise and well-structured with no fluff.

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

  Completeness4/5

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

  For a tool with 8 parameters and no output schema, this description gives a solid quick-start: core inputs, date format, and interval options. It does not mention time zone or datum defaults, but those are documented in the schema enums. It is sufficiently complete for an agent to select and invoke the tool correctly.

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

  Parameters4/5

  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 beyond the schema by clarifying the date range format (YYYYMMDD) and how the date shortcut is an alternative to begin_date/end_date, plus the practical meaning of interval='hilo'. This helpful cross-parameter guidance merits a 4.

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

  Purpose4/5

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

  The description clearly states the verb and resource: 'Get tide predictions for a NOAA CO-OPS station.' It distinguishes from many sibling tools by focusing on tide predictions, but it does not explicitly differentiate from the closely related coops_high_low tool, which also deals with high/low tides.

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

  Usage Guidelines3/5

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

  The description provides clear input requirements (station ID + date range or date shortcut) and a tip for using interval='hilo'. However, it does not explicitly state when to use this tool versus alternatives like coops_high_low or coops_water_level, nor does it give exclusions or alternative tool names.

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

• doe_publicationsA
  3.7/5.0
  Behavior3/5

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

  With readOnlyHint=true already signaling a safe read operation, the description adds useful scope context (covers national labs and universities). However, it does not disclose additional behavioral traits such as pagination, default limits, or the structure of returned results, which would help set agent expectations.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the main action, and immediately conveys what the tool does, what it covers, and its filter capabilities. No extraneous information.

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

  Completeness3/5

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

  For a search tool with 7 optional parameters and no output schema, the description provides a solid overview but does not explain result formats, pagination behavior, or default values. While the schema covers parameters well, the lack of a description for return structure leaves some gaps.

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

  Parameters3/5

  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 lists filter categories (keyword, author, title, subject, date range) that map to the schema properties but does not add extra semantic meaning beyond what the schema already provides, such as format details for date parameters or behavioral nuances of the query.

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

  Purpose5/5

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

  The description clearly states the tool searches for DOE-funded scientific publications and technical reports, with a specific scope (national labs and universities). This uniquely identifies it among sibling tools like pubmed_search and nih_search_publications, making the resource and scope explicit.

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

  Usage Guidelines3/5

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

  The description implies use when searching for DOE-funded research, but it does not explicitly mention when not to use this tool or recommend alternatives. It provides context that distinguishes it from other publication search tools, but lacks direct comparative guidance.

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

• eia_petroleumA
  3.7/5.0
  Behavior2/5

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

  The description is consistent with the readOnlyHint=true annotation, but it adds no behavioral context beyond the data categories. It does not mention pagination, frequency defaults, rate limits, or response structure, all of which would be valuable for an agent invoking this tool.

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

  Conciseness5/5

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

  The description is compact and front-loaded, with a clear opening sentence followed by a scannable product-code list. Every line provides actionable information; there is no redundancy or filler.

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

  Completeness3/5

  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 the description does not explain the return format or expected data structure. However, it does enumerate available series and clearly defines the data domain. With 100% schema parameter coverage and the readOnly annotation, the description is serviceable but leaves room for improvement in setting expectations about the response.

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

  Parameters4/5

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

  The input schema already covers all six parameters, but the description enriches the 'product' parameter by providing specific EIA series IDs and their human-readable meanings (e.g., EPCBRENT, EMM_EPMRU_PTE_NUS_DPG). This goes beyond the schema's generic description and aids correct selection.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with a specific verb and resource: 'Get petroleum/oil prices' and enumerates exact price categories (crude spot, retail gasoline, diesel, heating oil). This distinguishes it from sibling EIA tools like eia_electricity and eia_natural_gas.

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

  Usage Guidelines3/5

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

  The description implies usage by listing the data available, but it does not explicitly state when to use this tool over alternatives or when not to use it. It lacks exclusion guidance or comparisons with sibling tools, so the context is inferred rather than explicit.

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

• epa_facilitiesA
  3.7/5.0
  Behavior3/5

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

  The readOnlyHint annotation already covers safety. The description adds useful context about the ECHO source and that results include permit violations, inspections, and enforcement actions. However, it does not disclose pagination, default filters (major_only/active_only are in schema), or response format, so transparency 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.

  Conciseness5/5

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

  Three sentences, front-loaded with the primary action. Each sentence adds value: the first states the core search purpose, the second defines what results contain, and the third explains media type options. No filler or redundancy.

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

  Completeness3/5

  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 the description does not detail the response structure or fields beyond mentioning facilities with violations/inspections/enforcement. It also lacks guidance on how this relates to the sibling 'epa_facility_detail'. For a moderately complex search tool with one required parameter and filters, the description is functional but not fully complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameters are already well-documented. The description's media type explanation duplicates the schema's media_type description and adds little new meaning. No additional semantics for state, limit, major_only, or active_only are provided beyond what the schema states.

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

  Purpose5/5

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

  The description states a specific verb ('Search'), a clear resource ('EPA-regulated facilities'), and the purpose (environmental compliance and violations via ECHO). It also distinguishes itself from the sibling 'epa_facility_detail' by focusing on search/filtering, and clarifies scope with air/water media types.

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

  Usage Guidelines3/5

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

  The description provides clear context that this is for searching facilities by state and media, but it does not explicitly state when to use this versus sibling tools like 'epa_facility_detail' or 'epa_enforcement'. No exclusions or alternative recommendations are given, so usage guidance is implied rather than explicit.

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

• fbi_expanded_homicideA
  3.7/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds useful context about data content and level availability, but it does not disclose additional behavioral traits such as response format, default level when no parameters are provided, or any limitations. It does not contradict the annotations.

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

  Conciseness5/5

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

  The description is three concise sentences that immediately state the purpose, data contents, and levels. There is no filler, and every sentence earns its place.

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

  Completeness3/5

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

  Given the tool has 5 optional parameters and no output schema, the description covers the high-level purpose and data content but does not clarify important operational aspects like the difference between 'counts' and 'totals' (the type parameter), how to request national-level data (since no parameters are required), or potential parameter combinations. Annotations and schema fill some gaps, so 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.

  Parameters3/5

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

  Schema description coverage is 100%, so all 5 parameters are already described in the input schema. The description adds no specifics about parameters beyond mentioning available levels, which somewhat echoes the state and ori fields. With full schema coverage, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb and resource: 'Get expanded homicide (Supplementary Homicide Report) data from the FBI.' It also lists the content coverage (victim/offender demographics, weapons, circumstances) and available aggregation levels, which distinguishes it from sibling FBI tools like fbi_crime_summarized or fbi_expanded_property.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (for expanded homicide/SHR data) and mentions available levels (national, state, agency), but it does not explicitly name alternatives or provide when-not guidance. It also does not explain how to select each level via parameters, leaving the usage context mostly implicit.

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

• fbi_law_enforcement_employeesA
  3.7/5.0
  Behavior3/5

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

  The readOnlyHint annotation already covers safety, and the description adds that it shows staffing levels over time and includes sworn/civilian counts. However, it does not disclose important behaviors like what happens with no parameters (presumably national totals), output format, or mutual exclusivity of ori/state.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core action, and every word adds informational value. No fluff or repetition.

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

  Completeness3/5

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

  Reasonable for a read-only data lookup with rich schemas, but gaps remain: no output schema and no description of default scope, column details, or parameter interaction (e.g., ori requiring state). This leaves an agent uncertain about the result structure and about forming valid queries without further assumptions.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description reinforces the param semantics by mapping national/state/agency levels to the query dimensions and time to year fields, but it does not add meaning beyond the schema's own parameter descriptions.

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

  Purpose5/5

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

  The description uses a specific action ('Get') with a clear resource ('law enforcement employee data'), names the data categories (sworn officers, civilian employees), and specifies aggregation levels (national, state, agency). This differentiates it from sibling FBI tools like fbi_arrest_data or fbi_hate_crime.

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

  Usage Guidelines3/5

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

  It implies when to use the tool (for employee staffing data over time) and at which levels, but does not explicitly state when not to use it or name alternatives. The absence of an explicit national-vs-state selection rule leaves some usage ambiguity.

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

• fda_uniiA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description does not contradict this. The description adds value by explaining the domain (ingredient identifiers) and providing example query syntax, which goes beyond the annotation. It does not disclose return format or pagination behavior, but for a read-only search tool with annotations, this is acceptable.

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

  Conciseness5/5

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

  The description is concise and well-structured: a one-sentence purpose followed by two illustrative examples. No fluff; every line adds value. It is front-loaded with the core purpose.

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

  Completeness4/5

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

  Given the tool's simplicity (2 optional params, full schema coverage, read-only annotation, no output schema), the description is largely complete. It provides query examples and the concept of UNII. A mention of result structure or pagination could improve it, but it's not strictly necessary for this tool's complexity.

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

  Parameters4/5

  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 concrete query syntax examples ('unii:"L7V4I673D2"' and 'substance_name:"ASPIRIN"') that are not present in the schema, demonstrating how to use the search parameter effectively. This exceeds the baseline.

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

  Purpose4/5

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

  The description clearly states the tool searches UNII (Unique Ingredient Identifiers) and links ingredient names to chemical IDs. The verb 'Search' plus the resource 'UNII' makes the purpose specific. It doesn't explicitly distinguish from sibling FDA tools like fda_substance, so it doesn't earn a 5.

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

  Usage Guidelines3/5

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

  Example searches provide clear usage context for querying by UNII code or substance name. However, the description does not mention when to prefer this tool over other similar FDA tools (e.g., fda_substance), nor does it provide any exclusions or alternative guidance.

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

• fr_search_rulesA
  3.7/5.0
  Behavior2/5

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

  With readOnlyHint=true already provided in annotations, the description adds no further behavioral context such as pagination behavior, result ordering, rate limits, or any limitations. It merely restates the search scope, which is already captured by the schema's doc_type enum. Thus, the description fails to add meaningful transparency beyond the annotation.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main action and followed by a practical use case. Every word earns its place, with no redundancy or filler.

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

  Completeness3/5

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

  The tool has 7 optional parameters and no output schema, meaning the description should clarify what the response contains. It does not mention return format, default behavior, or any constraints. While the purpose is clear, the coverage of runtime behavior is incomplete for a tool of this complexity.

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

  Parameters3/5

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

  The schema has 100% description coverage for all 7 parameters, so the baseline is 3. The description does not add any extra parameter semantics beyond the schema, but given the schema is thorough, no additional explanation is necessary.

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

  Purpose5/5

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

  The description clearly states the tool searches for proposed rules, final rules, and agency notices in the Federal Register, using a specific verb and resource. It distinguishes itself from sibling tools like fr_executive_orders and fr_presidential_documents by covering the core regulatory document types.

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

  Usage Guidelines4/5

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

  The description provides a clear use case: 'Use to track regulatory activity by agencies.' This gives context for when to use the tool, though it does not explicitly mention alternatives or exclusions like 'for executive orders, use fr_executive_orders instead.'

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

• lobbying_lobbyistsA
  3.7/5.0
  Behavior3/5

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

  The annotations already establish readOnlyHint=true, so no additional safety disclosure is needed. The description adds minimal behavioral context beyond the basic purpose, such as indicating results include the lobbyist's firm, but it does not disclose pagination behavior, partial-match rules, or response structure. This is acceptable given the annotations but not enriched.

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

  Conciseness4/5

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

  The description is two short sentences and is front-loaded with the core action. The second sentence adds contextual detail but is somewhat redundant with the first, repeating the idea of searching by name/firm.

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

  Completeness4/5

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

  For a simple read-only search with three optional parameters and full schema coverage, the description covers the main purpose and primary search keys. However, it does not explain whether at least one parameter is required, how parameters combine, or what the response contains, leaving minor gaps given the lack of an output schema.

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

  Parameters3/5

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

  The input schema has 100% coverage, with descriptions for firm, name, and page_size. The description only rephrases the name/firm search keys and adds no extra detail about parameter format, constraints, or interaction behavior.

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

  Purpose5/5

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

  The description uses the specific verb 'Search' and clearly identifies the resource as 'individual lobbyists,' with scope limited by name or firm. It further states the purpose: 'Find specific people who lobby Congress and which firms they work for,' which distinguishes it from sibling lobbying tools focused on registrants or contributions.

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

  Usage Guidelines3/5

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

  The description implies use when the agent needs to find lobbyists by name or firm, providing general context. However, it does not explicitly state when to prefer this tool over alternatives such as lobbying_search or lobbying_registrants, nor does it mention exclusions or specific use cases.

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

• nws_aviation_sigmetsA
  3.7/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, and the description adds value by specifying the return content (active SIGMETs with phenomenon type, timing, affected areas), which is beyond the annotation. No contradictions, but it omits details like data source scope or update frequency.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the core action in the first sentence, and the second sentence adds necessary return details. No redundancy or extraneous content.

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

  Completeness4/5

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

  With zero parameters, read-only annotation, and no output schema, the description explains the core purpose and return fields, which is largely complete. However, given the close sibling faa_sigmet, a brief note about data source or temporal scope would enhance completeness.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema description coverage is 100% (empty schema). The description does not need to explain parameters, and the baseline of 4 applies since there are no parameters to describe.

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

  Purpose4/5

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

  The description clearly states the tool retrieves current aviation SIGMETs, expands the acronym, and lists return fields (phenomenon type, timing, affected areas). It is specific about the resource and action, though it does not explicitly differentiate from the similar sibling tool faa_sigmet.

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

  Usage Guidelines2/5

  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 like faa_sigmet or nws_alerts_active. It implies usage for current SIGMET retrieval but lacks explicit exclusions, prerequisites, or alternative references.

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

• ofac_consolidated_listA
  3.7/5.0
  Behavior2/5

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

  The description does not disclose behavioral traits beyond the readOnlyHint annotation. It fails to mention pagination, default limit, filtering limitations, or update frequency, which would help the agent understand what to expect when invoking the tool.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that conveys the core purpose without unnecessary words. It is concise and well-structured.

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

  Completeness3/5

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

  The description adequately explains what data the tool returns, but it lacks details on response format, how the limit parameter behaves, and how it compares to ofac_sdn_list beyond 'non-SDN'. This leaves some contextual gaps for a complete understanding.

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

  Parameters3/5

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

  The schema fully documents the 'limit' parameter with its description and default value, so the description adds no additional parameter meaning. This aligns with the baseline score of 3 for high schema coverage.

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

  Purpose5/5

  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 the consolidated non-SDN sanctions list. By specifying 'non-SDN' and providing examples (sectoral sanctions, foreign sanctions evaders), it distinguishes this tool from siblings like ofac_sdn_list.

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

  Usage Guidelines4/5

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

  The description conveys clear context about the tool's content, implicitly differentiating it from alternatives by highlighting 'non-SDN'. However, it does not explicitly name alternative tools or state when not to use this tool, leaving some guidance implied.

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

• regulations_search_docketsA
  3.7/5.0
  Behavior3/5

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

  The annotations declare readOnlyHint=true, and the description aligns with a read-only search operation. However, the description adds little behavioral context beyond the annotation. It does mention dockets represent rulemaking or non-rulemaking actions and includes a sort option, but does not disclose potential pagination behavior, result size limits, or any other operational details beyond what the schema provides.

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

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: one sentence for the tool's purpose, one sentence for context, and a final line for sort options. Every sentence adds information and there is no fluff or repetition of the input schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description does not explain what results look like, but this may be acceptable for a search tool. The description covers the domain concept (dockets) and mentions sort options, but does not provide usage examples, agency restrictions, or guidance on how to construct queries. Given the relatively simple search nature and complete schema, a 3 is reasonable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, meaning all six parameters have descriptions in the schema. The description does not add additional meaning beyond the schema, except for mentioning dockets represent rulemaking or non-rulemaking actions, which mirrors the docketType enum. The sort parameter examples ('title', '-title') are already implied by the enum values, so the description adds no significant semantic value. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as searching for regulatory dockets and defines them as organizational folders containing related rules, comments, and documents. It distinctly explains what a docket is, which differentiates it from a general document search and sibling tools like regulations_search_documents or regulations_search_comments.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains what dockets are but does not provide explicit guidance on when to use this tool versus alternatives. There is no mention of when to use regulations_search_dockets over regulations_search_documents or regulations_search_comments, nor any exclusions or prerequisites. The use case is implied by the docket definition but not explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scorecard_queryA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already covers safety, and the description adds useful context about filter syntax and range operations. Beyond that, it doesn't disclose additional behaviors like pagination, default limits, or response structure, but given the annotation coverage, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-sentence main description followed by four focused, annotated examples. Every element earns its place, with no redundant information or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and the absence of an output schema, the description addresses the core query syntax thoroughly. It would benefit from a brief note on the return format or expected response, but the current examples and schema together provide a solid foundation for invoking the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers all parameters with descriptions and examples for filters and sort. The description adds significant value by providing four additional filter examples demonstrating the __range suffix and exact-match syntax, which clarifies how to construct complex queries beyond the schema's single example.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it's an 'Advanced College Scorecard query' with custom field filters and ranges, which conveys the tool's purpose and scope. The 'Advanced' label and filter examples distinguish it from sibling tools like scorecard_search and scorecard_compare, though it doesn't 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for advanced querying via filter examples, showing when to use range and equality filters. However, it does not explicitly state when to prefer this tool over siblings or provide exclusions, leaving usage guidance mostly implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_educationA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already states this is a safe read operation. The description adds context about the type of data (education metrics) and available filters, but does not disclose return format, pagination limits, or other behavioral traits beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with the core purpose, then supported by examples and filter options. Every sentence earns its place with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and a generic description, the tool does not fully specify what the response contains or how results are structured. The described data categories give a broad idea, but the absence of return format details and the minimal guidance on SoQL usage make it less complete than it could be.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all 6 parameters, so the schema already explains each parameter well. The description reinforces filtering by county, year, or keyword, but adds no new parameter-specific meaning beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it queries education data for a US state, with concrete examples like school enrollment, assessment scores, graduation rates, and demographics. This distinguishes it from sibling tools like state_crime, state_health, and other state_* services.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the domain (education data for a US state) and the available filters (county, year, keyword). However, it does not explicitly say when to use this instead of other education-related tools or state_* sibling tools, nor does it mention any exclusions or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_propertyA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so the description does not need to reassert read-only behavior. The description adds modest value by noting 'May include' to warn that data fields vary, but it does not disclose response format, pagination, or potential data gaps by state. This leaves some behavioral uncertainty unaddressed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loads the primary purpose, and uses no filler. Every clause adds meaningful information about scope or filtering, making it efficiently compact.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description gives a solid overview of the tool's purpose and data fields, but with no output schema, it does not explain the return structure. It also lacks guidance on which of the many sibling state_* tools to use for related queries, leaving moderate gaps for an agent navigating a large toolbox.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already well-described. The description adds a useful summary of filtering capabilities (county, city, ZIP, address/owner search) but does not provide deeper detail beyond the schema, so it does not significantly enhance parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('Query') and resource ('property assessment/tax data for a US state'), and lists example data types (assessed values, owner info, property details, land use codes). This distinguishes it well from other state_* data tools, which focus on different domains like crime, health, or GIS.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by listing filter options (county, city, ZIP, address/owner search), but it does not explicitly compare to sibling tools like state_gis_parcels or mention when to choose this tool over alternatives. No exclusions or when-not-to-use guidance is provided, so usage guidance is implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_solar_cycleA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the tool is known to be a safe read operation. The description adds context about what data is shown (observed and predicted sunspot numbers and F10.7 flux) but does not disclose other behavioral aspects such as update frequency or data source. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary action ('Get predicted solar cycle progression') and adds necessary detail in the second sentence. No extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no parameters and a simple read-only purpose, the description is complete enough to inform an agent. It clearly states what data is returned, though it doesn't mention data source or update frequency, which would be nice but not essential for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so parameter semantics are trivially satisfied. The description explains the tool's output scope, which is helpful given no parameters exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving solar cycle progression data, including observed and predicted sunspot numbers and F10.7 flux. It is specific enough to distinguish it from generic sunspot or flux tools, though it doesn't explicitly name alternative tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for current solar cycle data retrieval, but it does not provide explicit guidance on when to use this tool versus related SWPC tools like swpc_sunspots or swpc_solar_flux. No alternatives or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• transit_arrivalsA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safe-read behavior is covered. The description adds useful context about system-specific station IDs and real-time data, but does not describe return format, error behavior, or rate limits. This is moderate extra value beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loads the action, lists systems in a compact list, and ends with a valuable note on station IDs. No redundant or wasteful text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has only two parameters and the schema covers them well, but there is no output schema and the description does not explain what the returned arrivals data looks like or how to resolve station IDs for systems not given examples. This is adequate but has clear gaps for a complete picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, giving baseline 3. The description adds concrete examples of station ID formats (BART: EMBR, WMATA: A01, CTA: 40380), which helps the agent understand the system-specific nature beyond the generic schema text.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get real-time arrivals/predictions for any of 12 US transit systems,' with an explicit list of supported systems. This specific verb+resource+scope distinguishes it from single-system siblings like cta_train_arrivals or mbta_predictions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for the listed systems but provides no guidance on when to prefer this tool over dedicated per-system siblings (e.g., trimet_arrivals, path_arrivals). It also does not mention how to discover system-specific station IDs, which is a key prerequisite.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usa_spending_by_recipientA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations include readOnlyHint=true, which already communicate that the operation is safe/read-only. The description adds that the tool returns top recipients and supports state/agency filtering, but it does not disclose behavioral details such as default sorting, pagination behavior, or what metric determines 'top' (e.g., total award amount). This is acceptable but not rich; the description adds some context beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the primary function. Every clause earns its place: it states the action, the resource, and the main filtering options. No wasted words or tangential information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with 5 optional parameters and no output schema, the description is adequate but incomplete. It communicates what the tool returns and suggests filters, but it does not clarify the meaning of 'top' (e.g., by total dollars) or describe the response structure. Since no output schema exists, the description could do more to set expectations about return values and ordering.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all 5 parameters, so the baseline is 3. The description only reiterates that state and agency filters can narrow results, which adds little beyond the schema's own field descriptions. No additional parameter semantics (e.g., format, defaults, interactions) are introduced.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get the top recipients (companies, organizations) of federal spending.' It uses a specific verb (Get), identifies the resource (top recipients), and clarifies the domain (federal spending). This distinguishes it from sibling tools like usa_spending_by_award or usa_spending_by_agency which focus on different dimensions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description suggests 'Use state and agency filters to narrow results,' which implies usage context for narrowing queries. However, it does not explicitly mention when to use this tool versus alternatives (e.g., usa_spending_by_agency for agency-level totals or usa_spending_by_award for individual awards), nor does it provide exclusions or conditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wmata_train_positionsA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates a safe read operation. The description adds that the tool returns real-time positions for all WMATA trains system-wide, which is useful scope context. However, it does not describe the response structure (e.g., coordinates, train IDs, line designations) or any refresh/update behavior. With annotations present, this is acceptable but not particularly rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that conveys the essential purpose without any fluff or repetition. It is well-structured and front-loaded with the action verb.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple zero-parameter tool, and the description clearly states its scope (all WMATA trains, real-time positions). However, there is no output schema and the description does not explain what 'positions' means concretely (e.g., lat/long, station-to-station progress) or what fields will be returned. This is a moderate gap for an agent that might need to interpret the data.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the input schema fully covers parameter semantics. The baseline score of 4 is appropriate because there is nothing to document beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a clear active verb ('Get') with a specific resource ('real-time positions of all WMATA Metro trains on the system'). This distinguishes it from sibling tools like wmata_train_predictions (predictions) and wmata_bus_predictions (buses), as well as other transit systems (SEPTA, BART, etc.).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. For example, it does not mention wmata_train_predictions for train arrival predictions, nor does it clarify whether this tool is for geographic positions vs. arrival times. There are no exclusions or alternative tool recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bls_employment_by_industryA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile. The description adds minimal behavioral context (e.g., that it can show growth/shrinkage), but does not disclose details like response format, data source, or historical depth 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core function, and every word adds value. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with only two optional parameters and no output schema, the description provides sufficient context to select and invoke it. It could benefit from mentioning return values or how growth/shrinkage is derived, but the schema covers the main parameters and the readOnlyHint covers safety.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both start_year and end_year having descriptions. The tool description itself adds no additional parameter context, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Get') and resource ('employment numbers broken down by major industry sector'). It also adds insight ('Shows which sectors are growing or shrinking') and is easily distinguishable from sibling BLS tools like bls_cpi_breakdown or bls_series_data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its use for industry employment data, but it does not explicitly state when to use it versus other BLS or economic data tools. No alternatives or exclusions are mentioned, leaving some ambiguity for the agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_nutrition_obesityA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, and the description does not contradict this. The description adds useful context about the data source and available breakdowns (state, race, age, income, education), but does not disclose return format, pagination, or other 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short, front-loaded sentences with no filler. The first sentence states the purpose, the second lists exact topic values, and the third summarizes data dimensions. Efficient and well structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only query tool with well-documented optional parameters, the description provides the source, topics, and stratifications. There is no output schema, but the data dimensions are clearly implied. A brief note on return shape would make it complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all three parameters with high coverage. The description adds little beyond listing topic values already present in the schema; the demographic context is informative but does not change parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('adult obesity, physical inactivity, and fruit/vegetable consumption by state from BRFSS'). It clearly differentiates this tool from sibling CDC tools by naming the specific health indicators and the BRFSS data source.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative guidance is provided, but the description implies its use for BRFSS nutrition/obesity data by listing the topics and stratifications. It does not state exclusions or refer to sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clinical_trials_field_sizesA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds transparency by specifying the output includes min/max/top sizes for array fields. It clearly communicates that the tool returns aggregate statistics rather than raw data. No contradiction with annotations; the description complements them with useful behavioral detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences, each contributing useful information: what it does, what it shows, and why it's useful. There is no fluff, redundancy, or irrelevant detail. It is front-loaded with the primary purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity and lack of output schema, the description adequately explains the return value (min/max/top sizes) and provides context (database and example fields). It covers the essential aspects for an agent to decide whether to use it. However, it does not mention any potential limitations or default behavior beyond what is in the schema, so there is slight room for improvement.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the 'fields' parameter with format and default behavior ('Omit for all'), so the description adds no additional parameter semantics. The description's examples (Condition, Intervention, Phase) mirror the schema's description, providing no extra value. With 100% schema coverage, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets statistics on list/array field sizes in ClinicalTrials.gov, using specific verbs and resource. It mentions example fields and output format, making the purpose clear. However, it does not explicitly differentiate from the sibling tool 'clinical_trials_size_stats', so it falls short of a perfect score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a general use case ('useful for understanding data distribution') which implies when the tool might be used, but it does not explicitly state when to use this tool over alternatives or provide any exclusions. There is no mention of sibling tools or conditions under which another tool would be preferred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_amendment_amendmentsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds a small clarification that the returned amendments 'modify the parent amendment,' but it does not disclose additional behavioral traits such as pagination, rate limits, or return format. Since annotations already declare readOnlyHint=true, the safety profile is covered, so the description need not explain that it's 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no waste. It front-loads the core purpose ('Get sub-amendments') and then clarifies the relationship in a second short sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple (4 params, no output schema). The description provides the essential context—what the tool returns and how it relates to a parent amendment. However, it doesn't specify the output structure or pagination behavior, which would be helpful 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for all four parameters (limit, congress, amendment_type, amendment_number). The description does not add parameter-specific details beyond the schema, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' and names the resource 'sub-amendments to a specific amendment,' clarifying that it returns amendments that modify a parent amendment. This distinguishes it from sibling tools like congress_amendments and congress_amendment_details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when needing sub-amendments for a given amendment, but it doesn't explicitly state when to use it instead of alternatives, nor does it mention any exclusions or references to comparable tools. The context is derived from the purpose rather than explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bill_committeesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the description does not need to repeat that. It adds useful context about what data is returned (dates and actions), but does not cover potential limitations such as whether subcommittees are included, pagination, or empty results. This is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no redundant information. The first sentence front-loads the core action and resource, and the second adds relevant detail about scope and actions. Every word contributes value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with three clearly defined parameters and no output schema, the description sufficiently explains the tool's behavior and return content. It could go slightly further by noting whether subcommittees are included or what date format is used, but overall it is complete enough for a simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes all three parameters with 100% coverage (congress, bill_type, bill_number). The description does not add any 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves committees a bill was referred to, with activity dates and actions taken (referral, hearings, markup, reporting). This specific verb+resource combination distinguishes it from sibling tools like congress_bill_actions or congress_committee_bills.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when committee referral info is needed, but it does not explicitly state when to use this tool over alternatives like congress_bill_actions or congress_committee_bills. There is no mention of exclusions or alternative tool names, so the guidance is implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_house_communicationsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds no additional behavioral details such as pagination, defaults, or response structure. It does not contradict the annotation, but provides no extra transparency value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence (10 words) that front-loads the verb and resource. There is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only query with two well-documented parameters and a readOnlyHint, the description covers the essential use case. However, with no output schema, a brief note on the return format would make it more complete, though this is not a significant deficiency.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both committee_code and limit documented. The description adds no new parameter information; linking 'specific House committee' to committee_code is inherent to the purpose and does not explain format or constraints beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 ('House communications'), and the scope ('referred to a specific House committee'). This distinguishes it from sibling tools like congress_house_communications (which lists all House communications) and congress_committee_senate_communications (which handles Senate communications).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need House communications for a particular committee, but it does not explicitly recommend alternatives or state exclusions (e.g., 'for all House communications use congress_house_communications'). No clear usage guidance beyond the basic purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_meeting_detailsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful return-content context (title, committees, witnesses, etc.) but does not disclose additional behavioral traits such as pagination, error conditions, or whether a single object is returned. It does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the purpose and lists the key returned fields without any extraneous content. Every word earns its place, making it highly efficient and clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, so the description must convey return values. It lists several important fields (title, committees, witnesses, documents, related bills, video links) but omits other possible details like meeting date/location or the fact that it returns a single object. Given the moderate complexity and sibling context, the description is reasonably complete but not exhaustive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with basic descriptions for each parameter. The tool description adds context that event_id identifies a specific meeting and hints at what data is returned, but it does not explain parameter derivation, formatting, or relationships (e.g., how to obtain event_id). The schema already carries the main burden, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get detailed information about a specific committee meeting' and enumerates key content (title, committees, witnesses, documents, bills, video links). It clearly distinguishes itself from the sibling list tool 'congress_committee_meetings' by emphasizing 'specific' and 'detailed'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when detailed information about a meeting is needed, but it does not explicitly state when to use this tool versus alternatives such as congress_committee_meetings for listing, nor does it mention prerequisites like needing an event_id from a prior list call. The usage context is only implied, not explicitly clarified.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_report_textA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is established. The description adds value by disclosing the return format (formatted text and PDF URLs), but no other behavioral traits (e.g., pagination, error scenarios) are mentioned. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with no filler. It front-loads the action and resource, then states the return format. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple retrieval tool with 100% schema coverage and a readOnly annotation, the description is largely sufficient, clearly stating the return format. However, it lacks context on how this tool fits with related congress tools (e.g., whether users need to first obtain committee report details), which slightly reduces completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all three parameters, with report_type having an enum and clear descriptions. The description does not add any parameter-specific detail beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('Get') and resource ('text versions for a committee report'), and explicitly mentions the output ('Returns formatted text and PDF URLs'). This distinguishes it from sibling tools like congress_committee_reports (listing) and congress_committee_report_details (metadata).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied by the description ('Get text versions'), but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of when not to use it. Sibling tools like congress_committee_report_details could be confused, and no differentiation is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_hearingsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, so the read-only nature is covered. The description adds contextual definition and filter options but does not disclose potential behavioral traits like pagination limits, ordering, or response scope. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, no wasted words. The first sentence states the core purpose, the second covers filters and gives a brief definition. Highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with 3 optional parameters and no output schema, the description covers the essentials: what it does and key filters. It does not describe return fields or ordering, but these are not critical for a straightforward list endpoint. Adequate context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with each parameter described. The description merely restates that congress and chamber are filters, adding no new semantic nuance beyond what the schema already provides. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('List congressional hearings') with a clear resource. It also mentions filtering by congress and chamber, which distinguishes it from detail-focused tools like congress_hearing_details. The verb+resource is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by saying 'Filter by congress and chamber' and defines hearings, but it does not provide explicit guidance on when to use this over sibling tools (e.g., for listings vs. details). No exclusions or alternative tool mentions are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_house_communication_detailsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, so the read-only nature is known. The description adds some context about the returned fields but does not disclose error behavior, authentication needs, rate limits, or other behavioral traits. It provides minimal added value beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that gets directly to the point. Every word earns its place, and there is no redundant or extraneous content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, full schema coverage, and readOnlyHint annotation, the description is sufficiently complete. It explains the purpose, identifies key return fields, and is backed by a well-documented schema. It could mention prerequisites or relationship to other congress tools, but that is not essential for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes all three parameters with 100% coverage, so the baseline is 3. The description does not add additional parameter-specific meaning, though it does mention what information will be returned (abstract, committees, etc.). No conflicts or gaps exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed information about a specific House communication'), and lists distinguishing content fields (abstract, committees, submitting agency, legal authority). This differentiates it from sibling tools like congress_house_communications and other detail tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving detailed information on a specific House communication, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. There is no guidance on when to use the list tool first.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_nomination_hearingsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation already declares readOnlyHint=true, so the description is not required to restate safety. It adds the behavioral detail that the tool returns hearing dates, citations, and chambers, but does not disclose other traits like pagination, data source, or what 'printed' means. The description provides some value beyond the annotations but lacks depth.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence that front-loads the action and resource. It contains no filler or redundant details, earning its place with relevant output information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with two well-described parameters, and the description explains the return content, which is crucial given there is no output schema. It is complete enough for an agent to select and invoke correctly, though it could mention how to obtain the nomination number if not already known.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema descriptions cover 100% of the parameters, providing 'Congress number' and 'Nomination number' directly. The description adds no additional meaning beyond the schema, so it meets the baseline for high coverage but does not enhance parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 ('printed hearings associated with a nomination'). It also lists the key output fields ('hearing dates, citations, and chambers'), making its purpose unambiguous and distinct from sibling tools like congress_nomination_details or congress_hearings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for nomination-related hearings but does not explicitly state when to use this tool over alternatives. It does not mention exclusions or point to other tools for non-nomination hearings, so guidance is inferred rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_nominationsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is disclosed. The description adds that it shows nominee name, position, organization, and confirmation status, which is helpful, but doesn't disclose pagination, filtering behavior, or any other operational traits. It doesn't contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the main action, no unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a listing tool with 4 documented parameters and no output schema, the description provides the essential return field expectations. It doesn't mention default behavior, but that's covered by schema defaults. Sibling differentiation is minimal, but that's a usage guideline issue.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, the baseline is 3. The description doesn't add any parameter-level meaning beyond the schema's descriptions of limit, congress, and date filters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' with resource 'presidential nominations to federal offices' and enumerates example offices (judges, cabinet, ambassadors, agency heads), plus the fields shown. This clearly distinguishes it from related congress_nomination_details or congress_nomination_committees tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool vs alternatives, nor does it mention exclusions. However, it is clear it's for listing nominations, which implies use for overviews. There's no explicit alternative named, so it's not a 4.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_senate_communication_detailsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that it returns abstract, committees, and congressional record date, but does not disclose other behavioral traits such as error handling, pagination, or required authority.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that front-loads the verb and resource, and each detail (abstract, committees, congressional record date) adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple detail-retrieval tool with a read-only annotation and three fully documented parameters, the description adequately covers the core purpose and return content. It could mention the relationship to congress_senate_communications for discoverability, but that is not essential for this tool's use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all three parameters, including an enum for communication_type. With 100% schema coverage, the description does not need to add parameter details; the baseline of 3 applies since it neither enhances nor conflicts with schema semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('Get'), a specific resource ('detailed information about a specific Senate communication'), and enumerates three concrete content areas (abstract, committees, congressional record date). This differentiates it from sibling tools like congress_senate_communications (list) and congress_house_communication_details (House variant).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies that this tool is for retrieving details of a single, known Senate communication, but it does not explicitly state when to use it vs. the list tool or mention any exclusions/alternatives. No guidance is provided on prerequisites like needing the communication number beforehand.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_senate_communicationsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint: true already establishes the read-only nature, so the description's 'List' is consistent. The description adds minor context about the types being 'referred to Senate committees', but does not disclose additional behaviors like pagination, response format, or any potential limitations. With annotations covering the safety profile, the description contributes modest additional value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states the action and resource, the second enumerates the type codes with expansions. Every word earns its place; it is front-loaded with the verb and provides high-level context without redundancy. Even though the type list is also in the schema, it serves a quick-reference purpose in the description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward read-only list tool with no output schema, the description covers the essential aspects: what is listed and the three types. It is sufficient for an agent to invoke it correctly given the simple parameters. It does not describe the return structure, but the absence of an output schema lowers the expectation, and the description is complete enough for the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: limit, congress, and communication_type all have descriptions in the schema. The description repeats the type codes and their meanings, which is already in the schema, but does not add new meaning beyond that. The schema carries the full burden, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb 'List' and clearly identifies the resource as 'Senate communications', further specifying three subcategories (executive communications, presidential messages, petitions/memorials). This clearly distinguishes it from sibling tools like congress_senate_communication_details (which implies detail lookup) and congress_house_communications (which covers the House).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for listing Senate communications, but does not explicitly mention alternatives or exclusions such as using congress_senate_communication_details for individual records. The presence of sibling tools with similar naming suggests differentiation, but the description itself provides no explicit when/when-not guidance beyond the verb 'List' and the type enumeration.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_treatiesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safe read-only nature, and the description adds useful scope and output-field context (topic, date transmitted, ratification status). However, it does not disclose pagination behavior, response format, or any rate limits, so the added transparency beyond annotations is moderate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the primary action ('List treaties submitted to the Senate') and then the key output fields. Every word earns its place, and there is no redundant filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with four well-documented parameters and a read-only annotation, the description covers purpose and output fields adequately. It could be more complete by mentioning pagination or the default limit, but the schema covers limits, and the tool is not highly complex, so a score of 4 is justified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and all four parameters (limit, congress, toDateTime, fromDateTime) already have descriptive text. The tool description adds no additional parameter-level meaning beyond clarifying the output fields, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') with a clear resource ('treaties submitted to the Senate') and scope ('submitted to the Senate'). It also names the displayed fields (topic, date transmitted, ratification status), distinguishing this list tool from sibling tools like congress_treaty_details or congress_treaty_full_profile.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies use for retrieving a list of treaties, but provides no explicit when-to-use vs. alternatives or when-not-to-use guidance. Sibling tool names like congress_treaty_details suggest alternatives, but the description itself does not mention them or any exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_treaty_committeesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the description is not required to restate that. It adds the behavioral note that the result typically includes the Senate Foreign Relations Committee, which is useful context. However, it does not disclose other behaviors such as pagination or potential multiple committees.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with no filler words. The first sentence states the core purpose, and the second provides useful domain context about the typical committee.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool, the description covers the purpose and the schema covers all parameters, and the annotation covers read-only behavior. There is no output schema, but the description's 'Get committees' implies the return value, making it sufficient for an agent to invoke correctly. Could mention response format but is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides complete descriptions for both parameters (congress and treaty_number), with 100% coverage. The tool description adds no additional parameter semantics beyond what the schema already documents, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb+resource: 'Get committees associated with a treaty.' This directly distinguishes it from sibling tools like congress_treaties or congress_treaty_details, and the added context about the Senate Foreign Relations Committee reinforces the specific domain.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving treaty committees, but does not explicitly state when to use it versus alternatives or provide exclusions. The context is clear enough for the tool's purpose, but no explicit guidance on alternatives is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• coops_air_gapA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include readOnlyHint=true, so no contradiction. The description adds a helpful definition of air gap but does not disclose behavioral details such as response format, availability per station, or date-handling quirks. Value beyond annotations 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the action verb 'Get', and no wasted words. The definition of air gap is concise and informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, but the description conveys the core purpose and measurement definition. It does not describe the output structure or units, but the schema covers input validation. Adequate for a simple data retrieval tool, though a bit more detail on return shape would strengthen it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all six parameters individually described. The tool description itself adds no parameter semantics, but the baseline of 3 applies because the schema fully documents parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool gets air gap (bridge clearance) data from a NOAA CO-OPS station and defines what air gap measures. This specific verb+resource combination distinguishes it from sibling coops_* tools like water level, tides, and currents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear (use for bridge clearance data), but there is no explicit when-to-use guidance or mention of alternatives. Given the large number of CO-OPS sibling tools, it would benefit from a note like 'use instead of water level for bridge clearance data.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• coops_currentsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the description does not need to restate that it is a safe read operation. The description adds the requirement that the station must support currents, which is useful context. However, it does not disclose any additional behavior like default date ranges or how missing data is handled, though some defaults are present in the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, directly answers what the tool does, and front-loads the key purpose. Every word earns its place with no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with a fully described schema and read-only annotation, the description covers the essential context: purpose and station requirement. It lacks explicit return-format guidance, but the absence of an output schema and the straightforward nature of the tool make the description sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already described in the schema. The description adds no extra parameter semantics beyond what the schema provides, hence the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('current speed/direction observations from a NOAA CO-OPS station'), clearly distinguishing it from sibling tools like coops_current_predictions. The scoping to 'observations' and the station requirement make the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides one essential usage prerequisite ('Requires a currents-capable station') but does not explicitly state when to use this tool versus alternatives such as coops_current_predictions or coops_water_level. It offers no when-not or alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• coops_meteorologicalA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile, so the description's contribution is limited to enumerating product types. It does not disclose additional behavioral traits like date-range restrictions, default units/timezone, or output format, which would enrich transparency. The description is consistent with the annotation, adding minimal extra context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the action verb 'Get', and zero filler. The product list is brief and directly supports the tool's purpose. Both sentences contribute useful information without unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich input schema (100% coverage, enums, defaults), the description is nearly sufficient on its own. It lacks details on return values (no output schema) and does not explain date shortcut semantics, but the schema already documents defaults. The description is complete enough for an agent to invoke the tool correctly for known station IDs and products.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema descriptions cover 100% of the 7 parameters, including enums and examples, so the schema does the heavy lifting. The description's product list merely repeats the 'product' enum values without adding new semantics. It does not clarify parameter interactions (e.g., date vs begin_date/end_date), but that gap is acceptable since the schema already provides individual descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and names both the data source ('NOAA CO-OPS station') and the product categories, making it clear which resource is accessed. The product list distinguishes it from sibling CO-OPS tools (e.g., coops_water_level, coops_tide_predictions) that target non-meteorological data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for station-based meteorological products by listing them, but it does not explicitly state when to use it versus alternatives such as NWS observation tools or other CO-OPS endpoints. There are no exclusions or alternative tool mentions, so the guidance is indirect rather than direct.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dol_whd_enforcementA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description doesn't need to repeat that. It adds useful context about the types of data returned (back wages, penalties, violation counts) and data availability since FY2005, but does not describe response format, pagination, or rate limits. This is a moderate addition beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, each earning its place: purpose, key data fields, laws enforced, and data coverage. It is front-loaded with the main action and stays focused without redundant or vague filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with 7 parameters, no output schema, and minimal annotations, the description provides a solid overview of the domain, laws, and data scope. It does not explicitly mention pagination or return fields, but the schema covers parameters and the description lists key data elements. This is reasonably complete, though it could mention limits or common use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the description adds little beyond parameter syntax. It does provide domain context (e.g., 'back wages' helps interpret bw_atp_amt), but the schema already explains each parameter clearly. Baseline 3 is appropriate since the description doesn't need to compensate for schema gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches WHD enforcement cases, specifically covering wage theft investigations with back wages, penalties, and violation counts. It names distinct laws (FLSA, FMLA, Davis-Bacon, SCA), which distinguishes it from other DOL tools like dol_osha_inspections.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for WHD enforcement queries and lists covered topics, but it does not explicitly state when to use this tool versus alternatives (e.g., dol_osha_violations for OSHA). No exclusion criteria or alternative tool names are mentioned, so guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• epa_air_qualityA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, and the description is consistent with that (no contradiction). Beyond the annotation, it adds valuable behavioral context: mandatory auth credentials with signup URL, the same-year date constraint, zero-padded FIPS codes, and what kind of data is returned. It does not cover pagination, rate limits, or error modes, but with the read-only annotation covering the safety profile, the added context earns a 4.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense, front-loaded paragraph with no filler, but roughly half of it duplicates the input schema: the parameter code list, the service list, and the FIPS examples all appear again in the property descriptions. The auth and date-constraint sentences earn their place, but the redundancy keeps it from being zero-waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 6 parameters, no output schema, and nontrivial service options, the description covers all major decision points: which service to select, which pollutant code to pass, date formatting and same-year restriction, and required credentials. It partially states what is returned ('county-level monitor readings') but omits pagination, response structure, and failure behavior, leaving it just short of a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and each property is already richly documented — param codes with pollutant names, date format and same-year rule, FIPS examples, service list with defaults, and county examples. The description largely restates this schema content rather than adding new meaning, so it stays at the baseline 3; the only genuinely new information (API key/email requirement) is tool-level, not parameter-level.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource pair — 'Get air quality data from EPA's Air Quality System (AQS)' — and further clarifies scope with 'county-level monitor readings for criteria pollutants' plus the service list. It does not explicitly distinguish itself from sibling `epa_aqs_daily`, and the first sentence's 'annual summary data' slightly undercuts the wider service range (daily/quarterly/sample), so it misses the top score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete when/how-to-use guidance: it explains how to choose among annual, daily, quarterly, and raw sample services; states that bdate/edate must be in the same year in YYYYMMDD format; documents 2-digit FIPS state codes with named examples; and flags the AQS_API_KEY/AQS_EMAIL credential requirement with a signup link. It does not mention when NOT to use it or name alternatives, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• epa_aqs_dailyA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the read-only nature is already known. The description adds value beyond annotations by outlining the output fields ('daily mean, max, and observation count per monitor') and explicitly stating the required authentication credentials. No contradiction with annotations is present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is mostly concise and front-loaded, but the parameter list duplicates the schema's parameter descriptions almost verbatim. While not overly verbose, this redundancy means some content does not earn its place, though the overall structure is still clear and readable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only data retrieval tool with no output schema, the description is reasonably complete: it explains the purpose, the output summary fields, the required parameters, and authentication needs. It lacks explicit mention of pagination or error behavior, but these are not critical for a straightforward daily data query tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema coverage is 100%, with each parameter already described. The description repeats the parameter code mappings found in the schema, adding little new semantic detail. It provides no extra explanation of format, defaults, or optionality beyond what the schema contains, so it stays at the baseline for high coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get daily air quality summary data from EPA AQS' and specifies the returned metrics ('daily mean, max, and observation count per monitor'). This is a specific verb+resource pairing that distinguishes it from sibling tools like epa_aqs_monitors, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context for use: 'Useful for tracking day-to-day pollution levels' and suggests 'Cross-reference with CDC health data.' It also notes the credential requirement (AQS_API_KEY and AQS_EMAIL). However, it offers no explicit when-not-to-use guidance or alternatives compared to sibling EPA tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ercot_grid_conditionsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds context about weather-zone granularity and included metrics, but does not disclose behavioral nuances such as the ability to query historical dates (despite schema allowing it) or pagination behavior. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with purpose, followed by brief ERCOT background. No redundant wording, each sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, but the description enumerates the key data fields returned. It does not clarify the 'current' vs. historical capability implied by date parameters, but the schema covers the parameters. Overall adequate for a read-only grid data tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of parameters, so the description adds little beyond what the schema already provides. The data fields mentioned (load, capacity, generation) relate to output, not to parameter semantics. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('Texas (ERCOT) grid conditions'), then enumerates the data types (load forecasts, total system load, capacity, wind/solar generation). It distinguishes from sibling tools like ercot_prices by focusing on grid conditions rather than pricing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for anyone seeking ERCOT grid data but does not explicitly state when to use it versus alternative energy tools (e.g., ercot_prices, isone_load). It provides context about the Texas grid but lacks exclusions or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• faa_metarA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description supplements the readOnlyHint annotation by specifying what data is returned (temperature, dewpoint, wind, visibility, ceiling, flight category), the station ID format (ICAO codes), and the ability to query multiple stations comma-separated. This adds meaningful context beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise with three short sentences, each providing necessary information: the primary action, returned fields, and input format rules. No redundant wording exists.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple read-only nature, no output schema, and full schema parameter coverage, the description adequately covers the tool's core behavior and return values. It could mention the optional 'hours' parameter's effect, but the schema covers that, and the description sufficiently describes the default behavior ('current conditions').

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 repeats the schema's explanation for 'ids' (ICAO codes, comma-separated) but adds no new semantic meaning beyond the schema. It does not mention the 'hours' parameter, but the schema already documents it fully.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific action verb 'Get' combined with a specific resource 'METAR weather observations for airports', and clearly distinguishes from sibling weather tools like faa_taf or faa_sigmet by naming the METAR product and the returned fields (temperature, dewpoint, wind, etc.).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not mention when to use this tool versus alternatives such as faa_taf or nws_observation_latest, nor does it provide exclusions or when-not scenarios. It only provides operational details (ICAO codes, comma-separated stations), which is usage how-to, not usage selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fcc_broadband_providersA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by specifying the return content (ISP names, technology types, advertised speeds) and filtering behavior, but it does not enrich the behavioral context with pagination, default limits, or rate limits, which would warrant a higher score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences long, with the first sentence stating the action, the second listing return fields, and the third providing usage instructions. It is efficient, front-loaded, and contains no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 covers the essential return fields and filter options, making the tool usable. It does not explicitly describe default behavior when no filters are provided, but the schema and existing descriptions mitigate that gap, so a 4 is appropriate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, so all five parameters are already documented. The description reinforces that state and coordinates act as filters but does not introduce any parameter semantics beyond the schema, matching the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool searches broadband providers by location or state and identifies the return fields (ISP names, technology types, speeds). However, it does not explicitly differentiate itself from the sibling tool fcc_broadband_coverage, which likely focuses on coverage areas rather than provider details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit usage guidance: provide a state code, latitude/longitude, or both to filter results. This tells the agent what inputs to supply, but it does not mention alternative tools or when not to use this tool, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fec_top_candidatesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation is consistent with the 'Get' verb, so there is no contradiction. Beyond annotations, the description adds that results are ranked by total money raised, but it does not disclose defaults like per_page=20, the 50-item maximum, or response structure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that leads with the action and key concept 'top candidates'. Every word contributes meaning, with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a straightforward ranked list with clear purpose, and the description covers the core behavior of ranking by fundraising for a given office/cycle. However, with no output schema, details about result fields or pagination are absent, though the simplicity makes this largely sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are fully described in the schema. The description only references office and election cycle, adding no additional meaning about optional state or per_page beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get', the resource 'top candidates', and the ranking criterion 'ranked by total money raised'. It also specifies the scope 'for a given office and election cycle', which distinguishes it from sibling tools like fec_search_candidates and fec_candidate_financials.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use cases (when you want top fundraising candidates for an office/cycle) but provides no explicit guidance on when to choose this tool over alternatives like fec_search_candidates or fec_candidate_financials. There are no exclusions or comparisons.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fr_document_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, so the agent knows this is a safe read operation. The description adds useful context by enumerating the return fields, but it does not discuss response format, potential errors, or any rate limiting. This adds some value beyond annotations, but not a lot, aligning with the get_calls calibration example.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences. It leads with the primary action and resource, then lists key return fields. Every word contributes to the agent's understanding; there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a single parameter, no output schema, and minimal annotations. The description lists several return fields and states the input requirement, which is sufficient for a simple detail-fetch operation. It could be more complete by mentioning error handling (e.g., document not found), but for the tool's simplicity, the description covers the essential information.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage: document_number includes a clear type and example ('2024-00001'). The description merely repeats 'by document number' without adding new meaning. Since the baseline for high schema coverage is 3, and the description provides no extra semantic detail, a 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get full details for a specific Federal Register document by document number.' It clearly distinguishes this from sibling tools like fr_search_rules or regulations_document_detail by focusing on fetching details for a specific document. The list of returned fields (title, abstract, full text URL, agencies, CFR references) further clarifies its scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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 document number and need full details), but it does not explicitly mention how it differs from nearby tools such as fr_search_rules or fr_presidential_documents, nor does it state any prerequisites or exclusions. Usage guidance is therefore only implicit, not fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fred_series_infoA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  readOnlyHint already indicates a safe read operation. The description adds the specific metadata fields returned, which is helpful since no output schema exists. There is no mention of rate limits or other behavior, but the annotation covers the primary safety concern.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and return content. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for a simple metadata lookup tool, covering the key return fields. It omits details like return format or error behavior, but given the tool's simplicity and the presence of readOnlyHint, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents the sole parameter series_id with examples. The description adds no additional parameter semantics, but since schema coverage is 100%, the 3 baseline applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns metadata for a FRED series, listing specific fields (title, units, frequency, range, notes). This differentiates it from siblings like fred_series_data (which likely retrieves time series values) and fred_search (which searches for series).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when one needs metadata for a known FRED series ID, but does not explicitly mention alternatives or exclusions. It does not state when to use fred_series_info versus fred_series_data, so guidance is inferred rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ftc_dnc_complaintsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation, and the description's 'Search' aligns. It adds value by indicating return fields (phone numbers, dates, violation details) but does not cover pagination behavior, data quirks, or any special access requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences plus an example, front-loading the action and resource. Every sentence adds value, and the example concretely shows parameter usage without any wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only search tool with fully documented parameters, the description covers the domain, return fields, and a representative query. Minor gaps include pagination behavior and any data limitations, but the simplicity of the tool makes it adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All six parameters have detailed descriptions in the schema, so the baseline is 3. The description reinforces the main filters and gives a concrete example, but does not add deeper 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'Search FTC Do Not Call (DNC) telemarketing complaints,' specifying a clear verb, resource, and scope. This clearly distinguishes it from sibling complaint tools like CFPB or NHTSA complaints.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides filter criteria and an example, which implies typical usage patterns. However, it does not explicitly mention when to prefer this tool over alternatives or when not to use it, leaving usage guidance slightly implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hmda_filtered_aggregationsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, so the safe-read nature is known. The description adds the filter scope and the recommendation to use filters, but does not disclose what happens with no filters, response format, or other behavioral details. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences with front-loaded purpose. The filter list and recommendation are each useful and there is no redundant repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is moderately complex with 8 parameters and no output schema. The description covers the data type and main filter categories, but omits details about response shape and fails to reconcile the county mention with the actual schemas. It is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with each parameter described, so the baseline is 3. However, the description mentions a 'county' filter that is not present in the schema (parameters include states, msamds, leis, but no county). This introduces confusion. The FIPS code guidance for 'states' adds value, but the misleading county reference lowers the score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 'mortgage lending aggregation data' with an explicit scope 'filtered by geography or institution'. It distinguishes itself from the sibling 'hmda_nationwide_aggregations' by emphasizing filtering and noting 'Same demographic filters as nationwide'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear recommendation: 'At least one geographic or institution filter recommended.' It also implies an alternative via 'Same demographic filters as nationwide,' which hints at the nationwide sibling tool, but does not explicitly state when to use one over the other.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ita_trade_eventsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this a safe read operation, and the description's verbs ('search', 'find') are consistent with that. It adds the behavioral detail that events are 'upcoming' but does not disclose pagination, sorting, or output structure, leaving some 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no filler: the first states the resource and scope, the second gives search criteria and purpose. It is front-loaded and every clause earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only search tool with three optional parameters and no output schema, the description covers the essential aspects: what is searched, how to filter, and the intended benefit. It could mention what the results contain, but the current level is adequate for a simple search operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All three parameters (limit, query, country) are fully described in the schema with 100% coverage, so the description adds little beyond confirming keyword and country as search dimensions. The phrase 'by keyword or country' maps to query and country but does not enhance syntax or format details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches international trade events, specifying types (trade shows, missions, seminars) and the main filter dimensions (keyword, country). It also names the target audience (U.S. businesses), making its purpose distinct from unrelated siblings like ita_tariff_rates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case—finding upcoming trade events by keyword or country—but does not explicitly mention when to use this tool over alternatives. There are no exclusions or comparisons to other trade-related tools, so guidance is only implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• la_metro_vehiclesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is safe to call. The description adds that it returns real-time positions for all active vehicles and lists the included data fields (GPS coordinates, route, trip, stop, status), which provides some behavioral context beyond the annotation. However, it does not disclose any potential limitations such as pagination, latency, or data availability, so it only partially goes beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, with the first sentence stating the primary purpose and the second listing the return fields. It is front-loaded, concise, and contains no superfluous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and no parameters, the description must convey what the agent can expect. It lists the key return elements (GPS coordinates, route, trip, stop, status) and specifies that it covers both buses and rail. It could be slightly more complete by describing the response format (e.g., list of vehicles), but it is sufficient for a simple no-parameter tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema is empty. The description correctly implies that no arguments are needed by stating it returns data for 'all active vehicles'. Since there are no parameters to explain, this dimension gets a baseline of 4, and the description handles it well without adding unnecessary parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Get real-time bus and rail vehicle positions') and the target resource ('for LA Metro (Los Angeles)'). It distinguishes from sibling tools like la_metro_routes and la_metro_stops by focusing on vehicle positions, and from other transit tools by naming LA Metro.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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. It does not mention any exclusions, prerequisites, or comparisons to related tools like la_metro_routes or mbta_vehicles. The only implicit hint is that it is for real-time positions, but no explicit usage context is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• loc_browse_formatA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations include readOnlyHint: true, which already communicates that this is a safe read operation. The description adds no additional behavioral context such as pagination behavior, rate limits, or return format. It only reiterates the browse-by-format scope, which is largely semantic rather than behavioral. Since annotations cover safety, a score of 3 (baseline with annotations) is appropriate, but no extra credit is earned.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long and front-loaded: it states the primary action and resource first, then provides the list of accepted formats in a compact, scannable line. Every word earns its place with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (3 parameters, one required enum, no output schema), the description plus schema fully covers the inputs and purpose. It doesn't explain return values, but for a list-browsing tool with readOnlyHint, that's a minor omission. The format list and clear action provide sufficient context for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with all parameters described: format (enum), q (search within format), and page (page number). The description lists the enum values again, but this is redundant with the schema. It adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Browse Library of Congress items by format/media type.' It uses a specific verb ('Browse') and resource ('Library of Congress items') and lists the exact formats accepted. While it doesn't explicitly name sibling tools like loc_search or loc_collection_browse, the format-scoped browsing distinguishes it from general search or collection browsing, making the purpose clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: this tool is for browsing by format/media type, implying use when a user wants to explore items within a specific format rather than searching across all collections. It doesn't mention alternatives or exclusions, but the context is unambiguous due to the format list, so no further guidance is needed for basic usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• loc_collection_browseA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds no extra behavioral context beyond that, such as pagination behavior, result format, or any quirks. With annotations present, the bar is lower, but the description still adds minimal value beyond what annotations convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loaded with the core purpose, and the second sentence provides a practical prerequisite. Every word earns its place, with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only browse tool with one required parameter and no output schema, the description is fairly complete. It states the purpose, provides a workflow for getting the required slug, and is backed by good annotations. It could optionally mention that 'q' and 'page' are optional filters, but the schema already documents these, so this is not a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all 3 parameters with descriptions, including examples for 'slug' (e.g., 'civil-war-maps'). Since schema coverage is 100%, the baseline is 3. The description adds the contextual hint that slugs come from loc_collections, but this does not add meaning beyond the schema's parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Browse a specific Library of Congress collection.' The verb 'browse' and resource 'specific Library of Congress collection' are specific and unambiguous. It does not explicitly distinguish this from sibling tools like loc_search or loc_browse_format, but the focus on a specific collection is clear enough.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear workflow directive: 'Use loc_collections first to find collection slugs.' This tells the agent how to obtain the required slug parameter, but it does not mention when to choose this tool over alternatives like loc_search or loc_browse_format. It offers clear context without exclusions, so it earns a 4.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• loc_item_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds a list of returned fields but does not disclose potential error behavior, response format, or rate limits. Since the annotation covers the core behavior, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the core purpose and followed by a useful list of return contents. Every word contributes meaningful information with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter detail retrieval tool with readOnly annotations, the description sufficiently covers what the tool returns. It lists the key metadata types not obvious from the tool name, though it omits details about error conditions or response structure, which is not critical given the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the single 'id' parameter with a description ('Item identifier (from search results)'), giving 100% coverage. The tool description does not add extra meaning beyond that, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Get full metadata') on a specific resource ('Library of Congress item'), and names the major return fields. This distinguishes it from search-oriented siblings like loc_search, which are about discovery rather than retrieving a single item's details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage after obtaining an identifier, and the schema parameter notes 'from search results', but the description itself does not explicitly state when to use this tool versus alternatives or mention any exclusions. It provides only implied context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nws_zone_forecastA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, and the description is consistent with a read operation. However, the description adds no additional behavioral context beyond that, such as return format or rate limits, but for this simple tool the annotation covers the key trait.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two sentences, with the purpose front-loaded and a helpful second sentence providing a concrete example of a zone ID. There is no unnecessary verbosity or wasted content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, the description adequately covers the purpose and parameter format. It could mention alternatives or output details, but these are not critical for such a straightforward tool. The coverage is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage, describing zone_id with the same example format ('NYZ072', 'CAZ006'). The tool description repeats this example, adding no extra semantic value beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get text forecast for a specific NWS forecast zone', which is a specific verb+resource+scope. It distinguishes from sibling forecast tools like nws_forecast_hourly and nws_alerts_active by focusing on text forecasts for a specific zone.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a specific NWS zone ID is known, but it does not explicitly explain when to use this tool versus alternatives such as nws_point_lookup or nws_forecast. No exclusionary guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ofac_searchA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the behavioral detail of case-insensitive substring matching, which goes beyond the annotations (readOnlyHint). It also clarifies the search scope ('SDN sanctions list') and by 'name or entity', providing useful context. However, it does not mention result format or pagination, but annotations cover the read-only nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one sentence, front-loaded with the verb 'Search', and contains no filler. It conveys the essential scope and behavior without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter search tool with no output schema, the description provides enough context about what it searches and how matching works. It could mention what the response contains, but given the simplicity and schema coverage, it is largely complete. The lack of differentiation from sibling search tools is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes both parameters with 100% coverage. The tool description adds a bit of semantic value by clarifying that 'name' accepts both names and entities and that matching is case-insensitive, but this is a modest supplement to the schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches the OFAC SDN sanctions list by name or entity, specifying the match behavior as case-insensitive substring. This is a specific verb-resource pair, but it doesn't explicitly differentiate from sibling tools like ofac_sdn_list or ofac_filter, though the SDN list specification helps.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for name/entity searches against the SDN list, but provides no explicit guidance on when to prefer it over alternatives like ofac_consolidated_list or ofac_filter. There are no exclusions or alternative tool mentions, leaving some ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• open_payments_by_companyA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description does not need to state safety. It adds useful behavioral context like 'all years combined' and what fields are shown. However, it does not describe pagination, default behavior, or any potential edge cases, which would be valuable for a complete picture.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the main action and grouping, followed by a clear summary of output. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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, read-only annotation, and no output schema, the description covers the essential purpose and output well. It lacks details about pagination or limit defaults, but the schema fills that gap. Overall, it is complete enough for an agent to decide usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single 'limit' parameter is well-described in the schema. The description itself does not add any extra meaning about the parameter, but the schema already handles it completely, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns payment summary data grouped by pharmaceutical/device company, with specific details about output ('total amounts and number of payments'). It distinguishes from sibling tools like open_payments_by_physician, open_payments_by_hospital, and open_payments_by_specialty by explicitly focusing on companies.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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 company-level aggregated data is needed, all years combined) but does not explicitly mention alternatives, exclusions, or when not to use it. It provides context but lacks clear guidance relative to the many sibling Open Payments tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• open_payments_searchA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide readOnlyHint, so the description adds value by disclosing that the tool returns exact dollar amounts, payment type, doctor name/specialty, and involved drugs/devices. It also gives a sense of data scale (15M+ records per year). This goes beyond the annotation but does not cover rate limits, pagination, or result ordering, keeping it below a 5.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the core purpose. The second sentence provides scale, the third lists output fields and cross-reference ideas. Every sentence earns its place with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description helps by listing what the results show, which is important for an agent. It also mentions data scale and cross-referencing opportunities, enriching context. However, it omits details like default year behavior (though in schema), pagination, or how to combine filters, making it not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 extra meaning to the parameters beyond what the schema already includes (e.g., examples of partial matches in the schema). It mentions doctor name/specialty and drugs/devices, but these are already implied by the schema parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches CMS Open Payments data and describes its content (payments to doctors, details). It uses a specific verb ('Search') and resource, but does not explicitly distinguish from sibling open_payments tools like open_payments_by_physician or open_payments_top, so it scores a 4 rather than a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives context about the data (15M+ records) and suggests cross-referencing with FDA, lobbying, and clinical trials, which implies usage scenarios. However, it does not explicitly state when to use this tool versus alternatives, or provide exclusions or prerequisites, so it only meets the 'implied usage' level.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• query_fiscal_dataA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds useful syntax details but does not disclose rate limits, authentication, or response format. It doesn't contradict annotations, but beyond the basic read-only trait, behavioral disclosure is limited.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded: a one-sentence summary, supported operations, then concrete examples. Each sentence earns its place, and the examples are practical and immediately usable without verbose explanations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a required 'endpoint' parameter, but the description provides no guidance on valid endpoint paths, which is a notable usability gap. It also doesn't mention response format or pagination defaults beyond what the schema already provides. For a query tool with 6 parameters, this 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.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 6 parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds meaningful value by explaining filter operators, sort syntax, and multi-filter formatting, which goes beyond the schema's static descriptions and clarifies usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool queries the U.S. Treasury Fiscal Data API with a specific verb and resource. It doesn't explicitly compare to sibling tools, but the resource is unique among siblings, so the purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use this tool (for querying Treasury Fiscal Data) and what operations it supports. It doesn't list exclusions or alternative tools, but no sibling duplicates this API, so the guidance is sufficient for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• regulations_document_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint: true, so the safety profile is covered. The description adds the ID example and the notion of 'detailed information', but does not disclose output structure, pagination, or any other behavioral traits. It neither contradicts annotations nor goes beyond the baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one sentence, front-loaded with the action and resource, and every word earns its place. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter detail lookup with readOnlyHint, the description is adequate. It lacks output format details, but the tool's simplicity and the clear ID example make it sufficiently complete. Slightly more detail on what 'detailed information' includes could push it to 5, but it is not a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter documentId is fully described in the schema with an example, and the description repeats that example. With 100% schema coverage, the description adds little beyond what the schema already provides, 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.

  Purpose5/5

  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 ('detailed information for a specific regulatory document') with a concrete ID format and example. This distinguishes it from sibling search tools like regulations_search_documents and docket-level tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: use this tool when you have a document ID and need full details. It does not explicitly name alternatives or state when not to use it, though the ID-scoped nature is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• regulations_search_commentsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile, and the description adds the sort behavior and the nature of results (public comments). However, it does not disclose pagination, rate limits, default limits, or response format beyond what the schema provides, so additional behavioral context is limited.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: three sentences covering purpose, filters, and sort. It is front-loaded with the main purpose and contains no fluff or redundant phrases.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with 8 optional parameters and no output schema, the description provides a clear overview of functionality, filters, and sort. It could be more explicit about pagination or the response structure, but the schema already covers parameter details and the tool is relatively straightforward.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 8 parameters have schema descriptions (100% coverage), so the baseline is 3. The description merely summarizes the filter categories (keyword, agency, docket, date) and sort options, which repeats schema information without adding meaningful new semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches for public comments on federal regulations, distinguishing it from sibling tools like document or docket searches. It also notes filters by keyword, agency, docket, or date, which further clarifies its specific scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for finding comments on proposed rules but does not explicitly mention alternatives like regulations_comment_detail or when not to use it. It provides useful filter and sort guidance, so the context is clear, but explicit exclusions or alternative references are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sam_exclusionsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations declare readOnlyHint=true, so the safe-read nature is already known. The description adds the semantic context of debarments/suspensions and the business purpose, but it does not disclose additional behavioral traits such as whether results are limited to active exclusions, default result limits, pagination, or time-to-live of data. With annotations covering safety, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the verb and resource, and zero filler. Every word earns its place: 'Search', 'SAM.gov exclusions', 'debarments/suspensions', and the purpose statement. This is exemplary conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only search tool with no output schema and 4 optional parameters, the description covers the core purpose adequately. The title and annotation add minimal extra context. However, it omits any hint about the response shape (e.g., a list of exclusion records) and does not mention that at least one search criterion is typically needed, though the schema's optionality is clear. Still, the overall context is sufficient for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 parameter-specific meaning beyond the schema; it mentions 'entity' which maps to the uei/name fields, but does not clarify how parameters combine (e.g., whether both uei and name can be used together). No extra value is provided beyond structured definitions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Search'), names a concrete resource ('SAM.gov exclusions'), and clarifies the purpose ('Check if an entity is excluded from federal contracting'). This clearly differentiates it from sibling tools like sam_entities or sam_opportunities, which serve different registration/opportunity use cases.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool ('Check if an entity is excluded from federal contracting') but does not explicitly mention alternatives or when not to use it. It lacks guidance on choosing between this and related tools (e.g., ofac_sdn_list for sanctions, or sam_entities for active registrations), which would help an agent avoid mis-selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scorecard_searchA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes the safety profile. The description adds the returned fields (tuition, admission rate, etc.) and search/sort capabilities, but does not disclose behavioral details such as pagination behavior, API limitations, or result ordering nuances beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, each providing unique value: purpose, returned fields, search dimensions, and sort options. It is front-loaded with the primary action and contains no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description covers the key return values (tuition, admission rate, graduation rate, median earnings, student debt) and states search/sort options. It lacks explicit notes on pagination or response structure, but the schema documents per_page. Overall, it is complete enough for a straightforward search tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are already documented. The description adds conceptual grouping ('Search by name, state, or school type' maps to name, state, ownership) and 'Sort by cost, earnings, or graduation rate' maps to sort, but does not add syntax or format details 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description specifies a clear verb and resource: 'Search U.S. colleges and universities from the College Scorecard.' It lists returned fields and supports search/sort criteria. However, it does not explicitly differentiate from sibling tools like scorecard_compare or scorecard_top, so it lacks sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context on how to use the tool: 'Search by name, state, or school type. Sort by cost, earnings, or graduation rate.' It implies when to use it but does not state explicit exclusions or alternatives (e.g., when to use scorecard_compare instead).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_businessesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this is a safe read operation. The description adds a brief scope ('may include counts, registrations, licenses, industry breakdowns') but does not disclose other behavioral traits like pagination behavior, return format, or whether data is aggregated. With annotations covering safety, the added value is moderate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, direct, and front-loaded. The first sentence states the core purpose, and the second provides useful categories without redundancy. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only query tool with 100% schema description coverage and no output schema, the description plus annotations is mostly complete. However, the phrase 'May include' is vague about whether results are individual records or aggregates, and the description does not explain how to choose between q and where filters. This leaves some ambiguity about the exact return shape.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all four parameters (q, limit, state, where) already described in the input schema. The description does not add parameter-level meaning beyond that, so the baseline of 3 applies. The 'may include' list refers to output fields, not parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Query') and resource ('business data for a US state'), and the 'may include' list (counts, registrations, licenses, industry breakdowns) distinguishes it from sibling state_* tools focused on crime, health, education, etc. This is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: use when business data for a US state is needed. However, there is no explicit mention of alternatives (e.g., state_query or other state_* tools) or exclusions (e.g., 'for crime data use state_crime'), leaving the agent to infer the tool's role among many siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_gis_parcelsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so safety is already disclosed. The description adds context about the data source (ArcGIS), the return fields (parcel ID, owner name, address, land area, use codes), and filtering capabilities. However, it does not disclose behavioral traits like pagination, rate limits, or default response size beyond what the schema states for the limit parameter. This is consistent with annotations, so no contradiction, and adds modest value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences with no filler. It opens with the primary action and resource, followed by return fields and filter options. Every sentence contributes useful information, making it appropriately sized and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a query tool with no output schema, the description lists the key return fields and explains the filtering mechanism. It lacks information on result ordering, pagination, or error handling, but the presence of a 'limit' parameter in the schema mitigates the pagination gap. Given the moderate complexity and that annotations already cover read-only safety, the description is fairly complete, though a note on large-result UX would push it higher.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are well-documented. The description goes further by specifying that the 'where' clause can filter by county, owner name, address, or ZIP, providing concrete examples of usage that the schema's generic example ('COUNTY = 'MONTGOMERY'') only hints at. This adds meaningful semantics beyond the schema, earning a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource: 'Query property parcel boundaries for a US state via ArcGIS.' It clearly identifies the data type (property parcels) and differentiates from sibling tools like state_gis_boundaries or state_gis_query by focusing on parcel boundaries. The statement 'Returns parcel ID, owner name, address, land area, and use codes' further specifies the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 sibling GIS tools or alternatives. It does not mention 'use this for parcel data, use state_gis_query for other data.' The filtering instructions apply within the tool but do not aid in tool selection. This is a clear gap given the numerous sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• trimet_arrivalsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description is consistent with that, adding return value details (estimated/scheduled times, route info, vehicle status). No additional behavioral traits such as authentication, rate limits, or data freshness are disclosed, but the read-only context is adequately covered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary action and scope, and includes relevant return details without extraneous text. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, the description covers the agency, location, mode, stop requirement, and returned data. It could optionally mention timezone or how to find stop IDs, but these are minor gaps for this category of tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single parameter stop_id with an example ('8989' for Pioneer Square). The description adds no additional semantics beyond what the schema already provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves real-time arrival predictions for TriMet buses and MAX light rail at a specific stop, with a specific verb ('Get') and resource. It distinguishes from sibling transit tools by explicitly naming TriMet and Portland, OR.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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 TriMet arrivals at a stop are needed) but provides no explicit comparisons or exclusions relative to sibling tools like cta_train_arrivals or marta_train_arrivals. The agency and stop-based scope give context, but no alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usace_levelsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true already conveying safety, the description adds behavioral value by stating what the tool returns (level IDs, dates, constant values, units) and mentioning wildcard filtering. It does not contradict annotations and provides reasonable output expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each earning its place: purpose, return contents, and filtering usage. No fluff or redundancy. It is appropriately sized and front-loaded with the primary action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given a simple read-only tool with two optional parameters and no output schema, the description covers the essential context: what it does, what it returns, and how to filter. Minor gaps like the meaning of 'constant values' or the exact role of the office parameter are not critical for basic use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so both parameters are already well documented. The description's mention of 'level-id-mask pattern' reiterates the schema's level_id_mask description without adding new semantics. Baseline of 3 applies since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get water level data for USACE locations', which is a specific verb+resource. It also lists returned elements (level IDs, dates, constant values, units), making the tool's purpose concrete. However, it does not explicitly distinguish itself from sibling tools like usace_locations or usace_timeseries, so it falls short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving water level data and provides a usage hint ('Use a level-id-mask pattern to filter'), but it gives no explicit guidance on when to choose this tool over alternatives or any exclusions. The use case is clear from context but not contrasted with siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usace_timeseriesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the agent knows it is a safe read operation. The description adds the naming format and prerequisite, but does not disclose response format, pagination, rate limits, or any side effects. With annotations covering safety, the added value is moderate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three compact sentences: the purpose is front-loaded, followed by the essential naming format and a cross-tool pointer. No filler or redundant words; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the core purpose, naming convention, and required upstream tool. It lacks explicit return format or default behavior, but given the absence of an output schema and the presence of good annotations, this is reasonably complete for a data retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter individually documented (e.g., name example 'Keys.Flow.Inst.1Hour.0.Ccp-Rev', begin/end ISO 8601 formats). The description adds the overarching naming pattern but does not provide param-specific semantics beyond what the schema already gives, so it meets the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Get' and identifies resource as 'USACE time-series data' with data types (water level, flow, storage, precipitation). It explains the naming format and references usace_locations, but does not explicitly distinguish from sibling tool usace_levels, so it lacks full differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides a clear prerequisite: 'Use usace_locations first to find location names.' This tells the agent when to use the tool (after obtaining location names) and gives a workflow hint. However, it does not mention when not to use it or alternatives like usace_levels, so no explicit exclusions are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usajobs_searchA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes the tool as read-only. The description adds useful context by listing the returned fields (position titles, agencies, locations, salary ranges, application deadlines), which helps the agent understand the output shape despite the absence of an output schema. No additional behavioral traits like pagination or rate limits are disclosed, but the description aligns with the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences that front-load the purpose and then state the return fields. It is efficient, with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose, filters, and return values. Since there is no output schema, listing the returned fields is essential and it does so. It does not mention optional implementation details like the limit parameter's default or pagination, but these are available in the schema and not critical for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all six parameters are individually documented in the schema. The tool description summarizes the main filter types (keyword, location, agency, salary range) but adds no new syntax or format details beyond the schema. This meets the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Search') and resource ('federal job listings on USAJobs.gov'), and lists the key filter dimensions (keyword, location, agency, salary range). It clearly distinguishes the tool from siblings like usajobs_detail by focusing on search behavior.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no information about when to use this tool versus alternatives such as usajobs_detail. There are no explicit use cases, exclusions, or references to sibling tools, leaving the agent to infer appropriateness from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usa_spending_by_agencyA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, so the description's read operation aligns. The description adds the behavior of breaking down by agency and highlighting top agencies, but does not disclose other traits like sorting, pagination, or default limits. With annotations covering the safety profile, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with the primary action front-loaded. The second sentence reinforces the purpose without redundancy. No unnecessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with a fully descriptive schema and annotations, the description is adequate. It explains the core functionality and scope, though it could optionally mention supported filters or output ordering, but these are covered by the schema and not critical for this simple aggregation tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 parameter-specific detail beyond indicating the data is by agency, meaning it does not enrich the 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it gets total federal spending broken down by awarding agency, which is a specific verb+resource combination. It also adds the context that it shows which agencies are spending the most, distinguishing it from sibling tools like usa_spending_by_state or usa_spending_by_recipient.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for agency-level spending analysis but does not explicitly mention when to use this tool versus alternatives like usa_spending_by_state or usa_spending_by_award. It offers no exclusion criteria or alternative tool references, but the agency focus is clear enough for basic guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usda_livestockA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, covering the safety profile. The description adds the type of data returned (inventory, slaughter, production) but does not disclose other behavioral aspects such as pagination, output format, or rate limits. With annotations present, this is adequate but not richly transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two short sentences that front-load the core purpose and immediately list the allowed commodities. Every word earns its place without unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple filtered data retrieval tool with full schema coverage and a read-only annotation, the description is mostly sufficient. The main gap is the unresolved discrepancy between the mentioned 'slaughter' and the category enum's 'SALES', plus lack of note about output format, but the essential contexts (commodities, data types) are present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 reiterates the commodity list and adds 'slaughter', but the category schema enum is INVENTORY, PRODUCTION, SALES, making 'slaughter' a potential mismatch. It does not clarify parameter formats such as state codes or year ranges beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('Get') and resource ('livestock data'), enumerates the data types (inventory, slaughter, production), and lists the supported commodities (CATTLE, HOGS, CHICKENS, MILK, EGGS). This distinguishes it from sibling tools like usda_crop_data or usda_prices.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for any livestock-specific data retrieval but does not explicitly state when to prefer this tool over alternatives or mention exclusions. There is no direct guidance on when not to use it (e.g., for crop data use usda_crop_data), leaving usage context mostly inferred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• uspto_application_continuityA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond the readOnlyHint by clarifying the content scope (parent and child applications with types like continuations, divisionals, CIPs). However, it does not disclose details about output structure, empty results, or any special handling of application number formats, so it stays at a baseline-plus level.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the core action and immediately followed by the key output details. Every word contributes; no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple one-parameter, read-only tool with no output schema. The description explains the high-level output (parent/child applications) and the data types shown, which covers most use cases. It lacks explicit mention of result structure or potential error cases but is adequate for the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (the application_number parameter is simply described as 'Application number'), so the baseline is 3. The description does not add further meaning such as expected format or examples, leaving the parameter semantics to the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('continuity data for a patent application'), then elaborates with the exact types of data ('parent applications (continuations, divisionals, CIPs) and child applications'). This clearly distinguishes it from sibling tools like uspto_application_details and uspto_application_assignments.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context—any time continuity (parent/child relationships) is needed—but it does not explicitly mention when not to use it or point to alternative tools for other application data. Given the large sibling set, explicit alternatives would improve selection accuracy.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• uspto_application_transactionsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes the tool as safe, and the description adds context about the returned event types and dates. However, it does not disclose any additional behavioral traits such as pagination, ordering, date range limitations, or error conditions, so while not contradictory, the added behavioral transparency 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary verb and action, and contains no redundant information. Every word adds value, directly stating the tool's purpose and the kind of data returned.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one parameter and no output schema, the description adequately conveys what it returns and its domain. It lacks explicit details on application_number format and response structure, but given the low complexity and the readOnlyHint, the description is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% because the parameter 'application_number' has a description ('Application number'), but that description is generic. The tool description does not add format or syntax guidance (e.g., whether it needs leading zeros, serial numbers, or publication numbers). Since schema coverage is high, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' with the resource 'patent application' and specifies 'transaction (prosecution history) events', which is a distinct domain. It enumerates example event types (office actions, responses, examiner actions, status changes with dates), making its purpose unambiguous and distinguishing it from sibling tools like uspto_application_documents or uspto_application_continuity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving prosecution history but does not explicitly state when to prefer it over alternatives or provide any exclusion criteria. No reference to sibling tools or contextual conditions is made, leaving the agent to infer the appropriate use case from the 'prosecution history' phrase.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wmata_train_predictionsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds modest context by clarifying that omitting the station parameter returns predictions for all stations, but it does not disclose data freshness, prediction horizon, or rate limits. This is acceptable with the annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no redundant content. The first sentence states the core function, and the second provides essential station code examples and default behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has a single optional parameter and no output schema, the description covers the main usage scenarios: requesting predictions for a specific station or all stations. It could optionally describe the structure of the returned predictions, but the basic purpose and station specification are clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents the 'station' property with 'Station code (e.g., 'A01') or 'All' for all stations' (100% coverage). The description adds value by providing concrete station code mappings ('A01=Metro Center, B01=Gallery Place') and explicitly stating that omitting the parameter is equivalent to 'All'. This goes beyond the schema's brief example.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get next train arrival predictions at a WMATA Metro station' – a specific verb and resource. This clearly distinguishes it from sibling tools like wmata_train_positions and wmata_bus_predictions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 is provided. The description only gives station code usage instructions ('Use 'All' or omit for all stations'), but does not mention related tools like wmata_train_positions or transit_arrivals. The agent must infer selection from the tool name and sibling context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wqp_resultsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, so the description need not restate safety. It adds useful context by listing common parameter names, but does not disclose behavioral details such as pagination behavior, default limits (though schema has it), or response format. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with purpose, followed by helpful examples. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a six-parameter, all-optional query tool with full schema coverage, the description is adequate. It gives the essential purpose and common values. However, it omits guidance on when to use wqp_stations to find station IDs first, which would be useful for a complete workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds value by clarifying that station ID and parameter name are the primary filters and gives concrete examples for characteristicName, but it does not add syntax or format details beyond schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource ('Get water quality sample results') and specifies the two primary filtering dimensions (station ID and/or parameter name). The phrase 'sample results' distinguishes it from sibling wqp_stations, which focuses on station metadata.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (for sample results) but does not explicitly contrast it with alternatives like wqp_stations or state when to use it over other water quality tools. There are no exclusions or preconditions mentioned, so an agent gets limited selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_multinational_enterprisesA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful contextual constraints (e.g., State and Parent are AMNE-only, and AMNE stats require ownership_level and non_bank_affiliates_only), but it does not describe the response structure, pagination, or any other behavioral traits. It adds some value but not extensive behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured, using bullet-like lines to present required parameters and conditional settings. Every sentence contributes useful guidance without redundancy, fitting within a small block.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the core directions, classification, and AMNE-specific parameters, but it omits that 'year' is a required parameter (as shown in the schema) and does not explain how to use state, country, industry, or series_id filters. For a tool with 9 parameters, this leaves notable gaps, though the schema helps compensate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, giving a baseline of 3. The description adds meaning beyond the schema by explaining the semantics of DirectionOfInvestment values (e.g., 'Outward' = U.S. investment abroad / foreign affiliates) and clarifying when ownership_level and non_bank_affiliates_only are needed. This is meaningful added value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving Direct Investment (DI) and Activities of Multinational Enterprises (AMNE) data, with explicit subcategories (Outward, Inward, State, Parent). This specific resource focus distinguishes it from sibling BEA tools like bea_gdp_national or bea_international_transactions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear instructions on which direction/classification to use and when additional AMNE parameters are necessary, but it does not mention when to prefer this tool over related BEA options or explicitly state exclusions. It provides in-tool usage context but lacks tool-selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_queryA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the safety profile. The description adds useful behavioral context by specifying the query syntax (SODA) and enumerating the exact dataset IDs, which helps the agent understand the scope. It does not disclose return format or pagination behavior, but provides meaningful context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: one sentence stating the purpose and a second sentence listing datasets. The main verb and resource are front-loaded. The dataset list is informative and earns its place, providing key context without unnecessary verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has six parameters, a readOnly annotation, and no output schema. The description explains the purpose and lists datasets but omits output format details and does not reference the specialized sibling tools for when to use them. Given the moderate complexity, this is adequate but with clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and each parameter has a descriptive example (e.g., "$where clause: \"year = '2021' AND state = 'New York'\""). The description only adds 'using SODA syntax,' which is redundant since the schema already mentions SODA $group, $order, etc. The description does not provide additional parameter-specific meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Custom query against any CDC dataset using SODA syntax.' It explicitly lists the 12 available datasets, making the resource scope unambiguous. This distinguishes it from sibling tools like cdc_causes_of_death or cdc_covid, which are specific dataset wrappers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating it's a custom query tool for any CDC dataset, but does not explicitly say when to prefer this over the specialized CDC sibling tools. No when-not-to-use or alternative guidance is provided, leaving the decision ambiguous for an agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfpb_search_complaintsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotation, the description adds useful behavioral specifics: the 13M+ record scale, the fuzzy auto-retry behavior for company names with a concrete 'Wells Fargo' example, and the fact that results include company responses. It doesn't disclose pagination behavior or rate limits, but the annotation already signals a safe read operation and the added details are substantive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description opens with the core purpose, then efficiently adds high-value details: record volume, return content, fuzzy-match behavior, and product options. No filler or redundant restatement of the tool name appears; each sentence contributes to the agent's understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 14-parameter read-only search tool with no output schema, the description sufficiently covers the main search dimensions, return type, dataset scope, and a non-obvious company-name behavior. It doesn't mention pagination or default result limits, but those are already present in the schema, and the description plus schema provide enough context for reliable invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Since schema description coverage is 100%, a baseline of 3 is appropriate. The description adds meaningful value for the company parameter by explaining the auto-retry fuzzy matching behavior, and it reinforces product parameter choices with a list of valid values. Most other parameters are already well documented in the schema, so the extra contribution is modest but genuine.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly names the action ('Search') and the resource ('CFPB consumer complaint database'), and enumerates the main filter dimensions and return type ('individual complaints with company responses'). It does not explicitly distinguish this from sibling tools like cfpb_complaint_detail or cfpb_complaint_aggregations, so it falls just short of full sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies appropriate use by stating what dataset is searched and what results look like, which gives the agent a sense of when to invoke it. However, it never names alternatives such as cfpb_complaint_aggregations for aggregate views or cfpb_complaint_detail for individual complaint detail, so the guidance is context-only rather than explicit when/when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clinical_trials_field_valuesA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that results include 'top values, counts, and distributions' and gives concrete examples of return-style behavior, but it does not disclose potential limitations like pagination, result caps, or special field formatting. This is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, with the first and third providing core value. The phrase 'Powerful analytics tool:' is mild marketing fluff, but the description remains tight and front-loaded with the primary purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple 2-parameter schema, good annotations, and absence of an output schema, the description is reasonably complete. The examples clarify expected output behavior (count by phase, top conditions), which helps an agent anticipate return values without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 schema already explains both fields (pipe-separated names) and types (enum of field types). The description adds usage examples but no additional 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get value statistics for study data fields — top values, counts, and distributions.' This clearly distinguishes it from sibling clinical trials tools like search or detail, and examples such as 'fields="Phase" shows trial count by phase' reinforce the unique analytics purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool ('find top conditions, top sponsors, phase distributions'), which implies the analytics use case. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for an agent to select it over the many sibling clinical trial tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cms_hospitalsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation establishes this as a safe read operation, and the description's 'Query' wording is consistent. The description adds context about the types of data accessible, but it does not disclose behavior such as the need to select a specific dataset (via the dataset parameter) or potential pagination/limits beyond the schema's 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that front-loads the core action ('Query CMS hospital data') and then lists the data categories in a clear, comma-separated format. No filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (4 parameters, no output schema), the description adequately lists the type of data available but does not clarify how the dataset parameter relates to those categories—an agent might mistakenly expect all categories in a single response. It also lacks detail on return structure, though the schema partially compensates.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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), so the description adds limited extra value. It identifies state and city as filter options, which is already clear from the schema, and does not elaborate on the dataset parameter or its enum values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Query CMS hospital data,' and enumerates the specific data categories available (general info, quality ratings, mortality, readmissions, infections, patient surveys, Medicare spending). This distinguishes it from sibling tools like cms_nursing_homes or cms_search by focusing specifically on hospital data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by noting that results can be filtered by state or city, aligning with the state and city parameters. However, it does not explicitly mention when to use this tool versus alternatives such as cms_nursing_homes or cms_search, nor does it provide exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_billsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint: true, so the read-only nature is known. The description adds the dependency on committee codes and the analytical purpose, but does not describe response format, pagination, or edge cases. This is acceptable but not rich beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core verb+resource, and every sentence provides value: the first states the action, the second gives a prerequisite and a use case. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description does not explain what fields are returned or how results are ordered/paginated. However, the purpose and prerequisite are clear, and the readOnlyHint covers safety. It is adequate but leaves room for more detail about the response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are already documented. The description only reiterates the committee_code parameter indirectly by referencing congress_committees. It adds no additional meaning beyond what the schema provides for limit or chamber.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get bills referred to a specific committee', which is a specific verb and resource. It distinguishes from sibling tools by focusing on bills by committee, and the phrase 'Use congress_committees to find the committee system code' adds a helpful cross-reference.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear use case ('tracking which bills die in committee vs. get reported out') and tells the user to consult congress_committees for the code. It does not explicitly exclude alternatives like congress_member_bills or congress_bill_committees, but the guidance is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_meetingsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description carries a lower burden. It adds useful context about return content (dates, locations, topics) but does not disclose pagination, default limits, or relationship between returned meeting dates and the update-date filters. It does not contradict the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, front-loaded with the core action and content. Every phrase is informational; no filler words or vague claims.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the main return fields and the two primary filters, but it omits the date-range filters (fromDateTime/toDateTime) entirely and does not mention default or maximum result count. For a list tool with no output schema, it gives a reasonable but not exhaustive picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all 5 parameters at 100%, so baseline is 3. The description highlights the congress and chamber filters in natural language but adds no additional detail beyond what the schema already provides, such as formats or defaults.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a list operation for committee meetings, specifying the resource (committee meetings), the verb (list), and the content (dates, locations, topics). It also includes examples of meeting types and mentions filters, which helps differentiate it from sibling tools like congress_committee_meeting_details that provide detail lookups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by stating what the tool lists and that it can be filtered by congress and chamber. It does not explicitly name alternative tools or exclusions, but the phrase '(hearings, markups, etc.)' signals it covers a broader set than dedicated hearings tools, giving reasonable context for an agent to select it when needing a list of committee meetings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• coops_high_lowA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safe read nature is known. The description adds that data is 'verified' and returns 'high and low water level observations,' providing some context beyond annotations. However, it does not disclose any other behavioral traits like pagination, default date ranges, or response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded, with the main purpose in the first sentence. The second sentence adds the 'verified' detail but is somewhat redundant with 'high/low tide data' and 'high and low water level observations.' Still, it is efficient and free of unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool, a clear annotation, and 100% schema coverage, the description provides sufficient context for an agent to select and invoke it. It identifies the data type (observed high/low) and data source (NOAA CO-OPS station), which is enough to distinguish it from sibling tools, though it does not explain return structure or date handling.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all six parameters are already described in the schema. The description does not add additional parameter detail or clarify usage beyond what the schema provides, meeting the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool gets observed high/low tide data (or verified high and low water level observations) from a NOAA CO-OPS station. The verb 'Get' with specific resource and data type distinctly identifies the tool's function, and the mention of 'observed' differentiates it from sibling tools like coops_tide_predictions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context about intended use (accessing observed high/low tide data) but does not explicitly state when to use this tool over alternatives such as coops_tide_predictions or coops_water_level. While the word 'observed' implies contrast with predictions, no explicit exclusions or alternative tool names are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• co_water_readingsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations declare readOnlyHint: true, which is consistent with the description's 'Get' verb. The description adds useful context about measurement types and units, but does not disclose additional behavioral traits such as pagination, time zone handling, or that the 'real-time' claim may be misleading when date ranges are used. With annotations already covering the read-only safety profile, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a one-sentence purpose, a compact parameter list with units, and a short usage note. It is front-loaded with the main function and every element earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only telemetry tool with a sibling station-finder, the description provides essential workflow context (use co_water_stations first) and parameter semantics. It does not detail return format or pagination, but no output schema exists and the tool's behavior is relatively straightforward. It is sufficiently complete for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all 5 parameters with descriptions, so the baseline is 3. The description adds value by listing each measurement parameter with its units (e.g., DISCHRG in CFS, STORAGE in acre-feet) and by clarifying that 'abbrev' comes from co_water_stations. This goes beyond the schema's terse enumeration.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves real-time Colorado streamflow, reservoir, and weather telemetry readings, using a specific verb and resource. It does not explicitly contrast with sibling tools like co_water_stations, but the name and usage note imply differentiation, making it clear enough.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance to 'Use co_water_stations first to find station abbreviations,' which is a clear prerequisite and directs the agent to the correct companion tool. However, it does not explicitly state when not to use this tool or mention alternatives for other data types, so it misses the top score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dap_agency_reportA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already discloses the safety profile, and the description adds no additional behavioral context such as authentication requirements, rate limits, pagination behavior, or data scope limitations. It is not contradictory, but it provides minimal value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise: two sentences plus one example. It front-loads the verb and resource, and every sentence contributes to understanding the tool's purpose and usage. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description only says 'Returns analytics data,' which is vague and does not explain the response format, pagination behavior, or how the 'report' enum affects results. The example is helpful, but the description is minimally complete for a tool with 6 parameters and varied report types.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all 6 parameters with 100% coverage. The description's example uses parameter names but does not add new semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets an agency-specific web analytics report from the Digital Analytics Program and returns data for a specific federal agency's websites. The 'agency-specific' qualifier distinguishes it from sibling tools like dap_gov_wide_report and dap_domain_report, and the example reinforces the intended use.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description establishes a clear context: use this tool when you need analytics for one federal agency's websites rather than a government-wide or domain-level report. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eia_total_energyA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description's 'Get' is consistent. It adds useful context by listing the available MSN codes and their meanings, which explains the scope of returned series. However, it does not describe output format, pagination behavior, or the fact that the code list is partial (e.g., no price or production codes despite the intro mentioning prices).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tightly written: one introductory sentence establishes purpose and scope, followed by a terse bullet list of codes. No filler or redundant restatement of the schema or title.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only overview tool with all parameters documented in the schema, the core purpose is clear and the MSN code list materially improves invocation. Yet gaps remain: the intro references 'prices' and 'production' but no corresponding MSN codes are listed, and there is no description of the API response structure (no output schema exists). This makes it adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing a baseline of 3. The description adds genuine value for the msn parameter by enumerating seven specific MSN codes with plain-language definitions, which the schema alone does not provide. Other parameters (start, end, frequency, length, offset) rely on the schema's already clear descriptions, so the contribution is concentrated on msn.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb ('Get') and clearly identifies the resource: monthly/annual U.S. energy overview across production, consumption, imports, exports, and prices. This clearly distinguishes it from sibling sector-specific EIA tools (eia_petroleum, eia_electricity, eia_natural_gas, eia_state_energy) by emphasizing a cross-sector aggregate view.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for broad U.S. energy overviews by naming aggregate categories and providing MSN codes for common series, but it never explicitly states when to prefer this tool over the sector-specific EIA siblings or when to omit the msn parameter. The schema's msn description says 'Omit for overview,' but that guidance lives in the schema, not the description. Thus usage guidance is only implied, not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• epa_aqs_monitorsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, which the description aligns with. The description adds behavioral context beyond annotations by disclosing that it 'Requires AQS_API_KEY and AQS_EMAIL' and describing the return fields (monitor locations, operational dates, measurement types, operating agencies). No contradictions found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is reasonably concise and front-loaded with the primary purpose. It follows a logical structure: purpose, returns, parameters, use case, requirements. The parameter listing is lengthy but serves as a quick reference. No unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description compensates by listing return fields and authentication requirements. It covers the essential inputs and outputs for a monitoring-station lookup tool. It does not mention pagination or date-range limitations, but given the tool's moderate complexity, it is fairly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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. The description repeats the parameter codes and meanings, adding marginal value. However, it does mention external requirements (AQS_API_KEY, AQS_EMAIL) not in the schema, which is useful, but the core parameter explanations are redundant.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Find air quality monitoring stations from EPA AQS.' It further specifies what is returned (locations, dates, measurement types, operating agencies), clearly distinguishing it from sibling EPA tools like epa_aqs_daily or epa_air_quality.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Useful for finding what is being measured and where' implies usage context but does not explicitly differentiate from alternatives or state when not to use this tool. Unlike the TDQS example, it names no sibling alternatives and provides no exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fbi_hate_crimeA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds context about the returned breakdowns and optional bias filter. However, it does not disclose behavioral traits such as default behavior when no parameters are supplied, how the level (national/state/agency) is selected, or potential limitations like pagination or time ranges. The added value over annotations is modest.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the first sentence states the core function and scope, the second adds useful detail about the return structure and optional filter. No filler or redundant information is present, and the examples of bias codes are concise and helpful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a moderately complex tool with no output schema, the description covers the returned data dimensions but leaves important usage details unexplained, such as how to specify the national/state/agency level (which parameters control it) and what the 'type' parameter means. While the schema covers parameter names, the description does not fully compensate for the absence of an output schema or clarify the behavior when no filters are provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 six parameters. The description adds meaningful examples for the bias parameter (e.g., '12'=Anti-Black) and mentions the level options, but it does not clarify ambiguous parameters like type ('counts' vs 'totals'), which remains under-specified in both the schema and the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's purpose with a specific verb ('Get') and resource ('hate crime data from the FBI'), and distinguishes it from sibling FBI tools by focusing solely on hate crime statistics. It also specifies the levels (national, state, agency) and the breakdown dimensions, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool (when hate crime data is needed) and the available levels, but it does not explicitly mention alternatives or state when not to use it. There is no reference to sibling tools like fbi_crime_summarized or fbi_nibrs, so the guidance is implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_device_pmaA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares that this is a safe read operation. The description adds behavioral context by providing example query patterns and noting the available count fields, but it does not disclose response format, pagination behavior, or any rate limits. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and reasonably compact, with a clear opening sentence, a brief explanatory note, and a bulleted list of examples. The count fields line is a bit terse, but overall each sentence serves a purpose without unnecessary verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the moderate complexity of an openFDA search tool, the description covers the core purpose, provides query examples, and lists count fields. It is complete enough for basic usage, though it omits details about the response structure or pagination. The absence of an output schema is partially compensated by the illustrative examples.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes both parameters with 100% coverage. The description adds value beyond the schema by showing concrete example queries (e.g., 'decision_code:APPR', 'applicant:"Medtronic"') and highlighting the count fields, which illustrate the query syntax and valid field names in a way the schema alone does not.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Search Premarket Approval (PMA) decisions for Class III medical devices') and clearly distinguishes this tool from siblings like fda_device_510k by specifying PMA and Class III devices. The additional explanation of PMA as required for high-risk devices reinforces the tool's unique scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives implied usage context by explaining that PMA is for high-risk devices, which helps an agent understand when to select this tool. However, it does not explicitly mention alternatives or provide exclusion criteria, such as using fda_device_510k for lower-risk devices.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• loc_searchA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. The description adds useful breadth context (40M+ items, formats) but doesn't mention pagination behavior, response format, or other operational details. This is adequate but not rich beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no redundancy; the action, scope, and examples are front-loaded efficiently. Every word contributes to understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 5 parameters and no output schema, so the description must compensate for unknown return values. It lacks any mention of what the search returns or how results are structured. Schema covers pagination/sorting, but output behavior is left completely unspecified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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. The description's example queries add a bit of semantic nuance for the 'q' parameter, but no additional parameter-specific meaning beyond schema fields is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Search the Library of Congress across 40M+ items' with a specific verb and resource, and lists content types (books, maps, photos, etc.). This distinguishes it from sibling tools like loc_item_detail, which focus on specific items or other formats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context that this is a broad, cross-format search tool, with example queries demonstrating appropriate use. However, it doesn't explicitly mention when not to use it (e.g., for item details) or name alternatives, so it gains partial credit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_bay_historicalA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, covering the safety profile. The description adds context about the available variables and stations, but does not disclose response format, pagination, or error behavior. This matches the baseline expected when annotations provide the main behavioral traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the primary purpose. It then provides necessary variable and station mappings. Though somewhat repetitive with the schema, the direct code-to-name pairs are useful and the description remains efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 100% schema coverage, readOnlyHint, and a clear statement that it returns historical time-series data, the description covers the essential usage context. It does not specify data granularity or exact response structure, but this is not critical given the absence of an output schema and the tool's straightforward nature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 in detail. The description repeats the variable and station lists without adding semantics beyond what's in the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action and resource: 'Get historical time-series data from a CBIBS buoy station.' It also clarifies the scope with 'Query specific variable over a date range for trend analysis,' distinguishing it from sibling tools like md_bay_latest and md_bay_stations by emphasizing historical data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: when historical time-series data for a specific variable and date range is needed (e.g., trend analysis). It does not explicitly mention alternative tools or exclusions, but the use case is well-defined.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_bay_stationsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds station abbreviations and full names, which is useful context, but does not describe the output structure, status values, or any operational details like refresh frequency or response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The core description is a single clear sentence. The second sentence listing stations is somewhat long but valuable for reference. No wordy fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter, no-output-schema tool, the description adequately covers what the tool returns (stations with locations and status) and enumerates station codes. It lacks detail on status semantics, but the simplicity of the tool makes this acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters and 100% schema coverage, the description need not explain parameters. The baseline for zero-parameter tools is 4, and the station codes listed in the description add useful context about the data returned.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'List all Chesapeake Bay CBIBS buoy stations with their locations and current status', identifying both the action (list) and the resource (CBIBS buoy stations). It distinguishes itself from sibling tools like md_bay_latest or md_bay_historical by focusing on the station list rather than real-time data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its use as a reference for station codes and names, but provides no explicit guidance on when to choose this tool over related tools like md_bay_latest or md_bay_historical. No exclusions or alternatives are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• naep_gap_year_jurisdictionA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Given the readOnlyHint annotation already establishes safety, the description adds behavioral value by explaining the computation: it returns innerdiff1 (focal jurisdiction year gap), innerdiff2 (target jurisdiction year gap), and the gap between them. This goes beyond the annotation and clarifies the analytic intent. It does not contradict the read-only annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each earning its place: purpose, example, and output explanation. It is front-loaded with the core action and free of fluff or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, so the description's mention of return values helps. However, the text says 'the gap between them' (singular), implying exactly two jurisdictions, while the schema allows 2+ jurisdictions. This mismatch leaves the agent uncertain how additional jurisdictions are handled. The tool's moderate complexity would benefit from clarifying the role of each jurisdiction and the treatment of multiple inputs.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are already well documented. The description introduces the concepts of 'focal jurisdiction' and 'target,' which map to the jurisdictions parameter, but it does not clarify how these roles are assigned when more than two jurisdictions are provided. This leaves a slight ambiguity that the schema does not resolve.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Compare how score changes between years differ across jurisdictions,' which precisely describes the tool's function. It also includes a concrete example (COVID learning loss in California vs. Massachusetts) and names the specific outputs returned, making it distinct from sibling NAEP tools that compare levels or groups rather than year-over-year gaps.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example implies a use case (comparing pandemic impact across states) but does not explicitly state when to prefer this tool over alternatives like naep_compare_states or naep_gap_variable_jurisdiction. The guidance is inferred rather than direct, with no exclusions or mention of sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nps_eventsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation. The description adds value by listing the returned fields and noting the optional park code filter, but it does not disclose additional behavioral details such as pagination behavior or how 'upcoming' is defined. It neither contradicts nor substantially extends annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and efficiently structured, with three short sentences that front-load the main purpose, then state return fields and filtering option. No redundant or wasteful wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with two optional parameters and full schema coverage, the description is complete. It includes the essential return fields, the key filter, and the read-only nature (via annotation). No output schema exists, but the described return fields suffice.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema: it highlights the park_code filter as optional, but the schema already describes both parameters adequately with examples and defaults.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets upcoming events at national parks, using a specific verb ('Get') and resource ('upcoming events at national parks'). It distinguishes from sibling NPS tools like nps_parks, nps_alerts, and nps_campgrounds by focusing on events and mentioning returned fields.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (for events at national parks) but does not explicitly mention alternatives or exclusionary conditions. There is no guidance on when not to use it versus other NPS tools, so the usage context is clear but not fully articulated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nws_point_lookupA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, signaling a safe read operation. The description adds return-value details (grid office, gridX, gridY, timezone, county), but does not disclose other behavioral traits like rate limits, error handling, or accuracy limitations. This meets the baseline with annotations present but does not exceed it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each earning its place: action, key return values, and contextual importance. It is front-loaded with the core action and avoids unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity of a simple two-parameter lookup tool, the description is complete enough. It clearly states what the tool returns and why it matters. No output schema exists, but the return values are named explicitly, so agents know what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with clear descriptions for latitude and longitude including ranges and examples. The description adds no extra semantics about the parameters, but this is acceptable since the schema handles the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Resolve') and a specific resource ('latitude/longitude to an NWS forecast grid point'), clearly stating what the tool does. It also distinguishes itself from siblings like nws_forecast by emphasizing it provides the grid coordinates needed for forecast calls.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states this is 'the essential first step before getting forecasts,' giving clear context for when to use it. It does not explicitly list alternatives or when not to use, but the guidance is strong enough for an agent to understand its role in the forecast workflow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• regulations_search_documentsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint: true annotation already declares the safe read-only nature, so the description doesn't need to repeat that. It adds the context that the tool complements Federal Register data, but does not disclose additional behavior like pagination defaults or result format beyond what the schema already shows.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a clear opening sentence, followed by compact lists of document types and sort options. It is concise and front-loaded, though the repetition of schema enum values is slightly redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with 10 parameters all described in the schema, the description covers the core use case and key options. It could mention pagination behavior or how filters interact, but the schema covers pageSize/pageNumber and the description's overall context is sufficient for an agent to select and invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter is already well-documented. The description repeats some enum values (document types, sort) that are already in the schema, adding no new meaning beyond reinforcing the main filters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Search' and the resource 'federal regulatory documents', listing the document types. It also distinguishes this search tool from related detail tools like regulations_document_detail and from Federal Register search tools by noting it 'Complements Federal Register data with rulemaking context.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description tells the user the tool is for searching by agency, docket, date, or keyword, and lists document types and sort options. It implies when to use it versus detail tools, but does not explicitly name alternatives or state 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.

• search_datasetsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the read-only nature. The description adds meaningful behavioral context by disclosing that the search spans all 53 datasets and 181 endpoints and matches against specific metadata fields (name, table name, endpoint path, description). This goes beyond the generic annotation, though return format and rate limits are not mentioned.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately concise: two sentences, with the core purpose front-loaded in the first sentence and precise scope details in the second. Every word earns its place, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description explains what is searched and the scope, but does not clarify what the response contains (e.g., dataset names, endpoint paths, or full metadata). This missing return-value detail leaves a moderate gap, though the simple nature and good schema description partially compensate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for the single 'query' parameter, including a description and examples. The description's 'by keyword' adds no additional semantic value over the schema, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific action verb 'Search' and clearly identifies the resource: 'Treasury Fiscal Data datasets and endpoints'. It further specifies the scope (all 53 datasets, 181 endpoints) and the searchable fields (name, table name, endpoint path, description), distinguishing it from sibling tools like query_fiscal_data or list_datasets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for discovering relevant datasets/endpoints by keyword, but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. For example, it doesn't clarify that actual data values should be fetched with query_fiscal_data, or that list_datasets provides an unfiltered listing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_housingA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful content context by listing possible data categories. It does not disclose pagination, rate limits, data sources, or variability between states, so it adds some value but not rich behavioral detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the main purpose, and provides a useful list of content types without unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 offers some idea of return content but not structure or granularity. It is adequate for a query tool but could mention result format or data source caveats. It is complete enough for a basic tool but leaves gaps for an agent trying to interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema documents all parameters. The description adds no parameter-specific information, leaving the schema as the primary source. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Query housing data for a US state' and lists specific content areas (building permits, housing units authorized, foreclosure filings). This distinguishes it from sibling tools like state_health or state_crime.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides a clear context: state-level housing data, and suggests cross-referencing with HUD tools for federal data. However, it does not explicitly contrast with the many other state_* tools (e.g., state_property, state_query) or indicate when this tool is preferred over them.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_goes_particlesA
  3.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint: true, so the agent knows it's a safe read operation. However, the description adds no extra behavioral context—no return format, temporal scope, or data quirks. The SEP event sentence is interpretive context, not behavioral disclosure. For a zero-param tool, this leaves agents guessing about the output.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences: the first states the action and resource, and the second explains why the data matters. The description is front-loaded and contains no filler, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (zero params, read-only), and the description covers its purpose and use case. However, with no output schema, the absence of any indication of the return data (e.g., time series, units, timeliness) leaves an agent uncertain about what to expect after invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters, there are no parameter semantics to convey. The schema is empty, and the description correctly focuses on the data source. The baseline of 4 applies because no parameter documentation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Get GOES satellite energetic particle flux data.' This clearly identifies the tool's function and distinguishes it from sibling tools such as swpc_goes_xray and swpc_solar_flux, which cover different space weather data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The second sentence provides context: 'Elevated particle flux indicates solar energetic particle (SEP) events that can affect satellites and polar aviation.' This implies when an agent should use the tool (to check for SEP activity), but it doesn't explicitly mention alternatives or when not to use it, so it offers clear context without exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_sunspotsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already establishes the read-only nature. The description adds useful context about monthly granularity and the solar-cycle relationship, but it does not disclose return format, historical date range, or data source. No contradiction exists between the description and annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the core action, and contains no redundant or filler content. Every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only data retrieval tool, the description is mostly complete: it states what is returned and why it matters. However, with no output schema present, it could further clarify the return shape, units, or date coverage to be fully self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description adds the key semantic detail that the data is monthly, which clarifies the returned series, even though there are no parameters to document.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get monthly sunspot numbers.' It clearly identifies what the tool returns, but it does not explicitly distinguish itself from the sibling tool swpc_solar_cycle, and the phrase 'Tracks the ~11-year solar cycle' could blur the boundary between the two.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for use: monthly sunspot numbers track the solar cycle and correlate with solar activity and space weather events. It does not mention exclusions or name alternative SWPC tools, but the intended use case is reasonably clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usa_spending_over_timeA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, covering the read-only safety profile. The description adds that data is aggregated by time period, which aligns with the name and schema, but does not disclose additional behavioral aspects such as default date ranges, output format, or pagination.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It clearly states the core action and purpose, making it easy to scan and quickly understand the tool's intent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is brief (16 words) and conveys the primary time-series aggregation and trend use case, but it omits details about optional filters (state, agency, keyword, award type) and output characteristics. The comprehensive schema compensates for these gaps, but the description alone is minimally sufficient for a 7-parameter tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all 7 parameters, including enum values for 'group' and 'award_type'. The tool description itself adds no further parameter-level detail beyond what the schema already provides, so it meets the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 states the resource: federal spending aggregated by time period (monthly, quarterly, or fiscal year). This distinguishes it from sibling tools like usa_spending_by_agency or usa_spending_by_state, which aggregate by other dimensions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Useful for identifying trends' provides a clear context for when to use the tool. However, it does not explicitly mention alternatives or when not to use it, leaving some ambiguity among the related spending tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• va_facilitiesA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, so the tool's safety is known. The description adds value by specifying the output fields (facility names, addresses, phone numbers, services) and explaining facility type enum values. However, it does not disclose pagination behavior or that all parameters are optional, which could affect usage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise: three sentences plus an example. It front-loads the tool's purpose, then adds return details and type explanations, with a final usage example. Every sentence contributes either to understanding the tool's scope or its usage, with no redundant filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no required parameters (per schema) and no output schema, but the description does not clarify that state and type are optional or that page/limit have defaults. It implies searching 'by state and type' without noting that omitting them is allowed. Given the schema explains parameter details, the description is adequate but misses the optionality nuance, so it is not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the description adds meaning beyond the schema by explaining each facility type in plain language and providing a concrete example that clarifies how to use state, type, and limit together. This helps the agent map user intent to parameter values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches VA facilities, lists the specific facility types (hospitals, clinics, cemeteries, benefits offices, vet centers), and notes what it returns (names, addresses, phone numbers, services). This distinguishes it from sibling tools by focusing specifically on the VA facility domain.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for the tool (VA facility search) and includes an example invocation with state, type, and limit. However, it does not explicitly mention alternative tools or when not to use this tool, relying on the domain name to imply exclusivity to VA facilities.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bart_stationsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the specific return fields, which is useful, but does not disclose any additional behavioral details such as data volume, pagination, or update frequency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, with the action and scope in the first sentence and the return values in the second. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter list endpoint, the description is adequately complete: it states the resource, scope, and return fields. It does not mention potential limitations like pagination, but given the tool's simplicity and readOnlyHint annotation, this is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool accepts no parameters, so the description need not document any. Schema coverage is effectively 100% with an empty properties object, and the baseline for zero-parameter tools is 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and identifies the resource 'BART (San Francisco Bay Area) stations,' and clarifies the return fields, distinguishing it from sibling tools like bart_departures and bart_advisories.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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 a list of BART stations is needed) but does not explicitly mention alternatives or exclusions. It provides clear context about the resource, but no guidance on when not to use it or when to prefer another tool, such as bart_departures.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_dataset_infoA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds context by listing the four action types and available datasets, which enriches understanding of the tool's behavior beyond the annotation. However, it does not disclose details like response formats 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a concise intro, a bulleted list of actions, and a final list of datasets. Every sentence is purposeful, with no waste or repetition, making it easy to scan and understand quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (4 actions, 5 parameters, no output schema), the description is quite complete. It explains each action, lists datasets, and clearly positions the tool as an exploration prerequisite. It could go further by describing the return format, but the absence of an output schema is mitigated by the detailed schema descriptions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already fully documents all five parameters with descriptions and examples. The description provides an additional high-level overview (actions, datasets) but largely repeats information already present in the schema, offering marginal added value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Discover BEA datasets, parameters, and valid parameter values.' It is specific in verb and resource, and distinguishes itself from sibling data-specific tools (e.g., bea_gdp_national) by emphasizing it is 'Essential for exploring the BEA API before making data requests.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says to use this tool 'before making data requests,' providing clear context for when it should be used. It does not name specific alternatives or exclusions, but the distinction from data-specific siblings is implicit and clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_gdp_by_stateA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint=true annotation already declares the operation safe. The description adds table options and GeoFips format, but these are parameter semantics rather than behavioral traits; it does not disclose return format, pagination, or performance characteristics. Given the annotation covers the safety profile, no contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is roughly 60 words, front-loaded with the core purpose, and uses a bullet list for table options. Every sentence contributes useful context, with no redundant filler. The structure is easily scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple data-retrieval tool with full schema coverage and a read-only annotation, the description covers the key decision points: table selection and geography format. It does not detail return values, but there is no output schema to complement, and the output is likely self-explanatory. Missing references to sibling tools are minor given the clear scope.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All four parameters have schema descriptions covering 100% of them, satisfying the baseline of 3. The description repeats table_name and geo_fips guidance, adding examples like '06000' for CA, but this duplicates schema information. It does not introduce new parameter 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get gross domestic product for U.S. states,' providing a specific verb, resource, and geographic scope. It names the dataset (BEA Regional) and lists table options, which distinguishes it from sibling tools like bea_gdp_national and bea_gdp_by_industry.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through its scope—'U.S. states from BEA Regional dataset'—making it clear this is for state-level GDP. It does not explicitly list alternatives or exclusions, but the context is sufficient for tool selection. The table options provide within-tool guidance, e.g., SAGDP9 for real GDP.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_gdp_nationalA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful context about the data content (GDP, growth, components, deflators) and common table names. However, it does not disclose behavioral traits such as return format, data limits, historical coverage, or seasonality adjustments, which would be relevant beyond the read-only hint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short paragraphs: the first states the purpose in one sentence, and the second is a compact bullet list of common table names. No fluff or repetition; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description provides sufficient context for a read-only data retrieval tool: it states the data source, major content categories, and offers a meaningful table reference list. The main gap is the absence of explicit differentiation from other BEA tools, which would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all three parameters (100% coverage), providing a baseline of 3. The description enhances parameter semantics by expanding the table_name choices beyond the schema's brief list, including T30100 and clarifying real vs. nominal tables. This adds meaningful value for selecting the correct table.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get U.S. national GDP data from the NIPA tables.' It clearly identifies the scope (national GDP) and differentiates from sibling tools like bea_gdp_by_state or bea_gdp_by_industry. The listed components and table names further specify what the tool offers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for national GDP data through its title and first sentence, but it does not explicitly state when to use this tool instead of siblings such as bea_gdp_by_state or bea_gdp_by_industry. No alternative, exclusion, or prerequisite is mentioned, leaving the agent to infer the correct context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_input_outputA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds context about the data's meaning ('interrelationships between U.S. producers and users'), but does not disclose response format or any other behavioral details. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose and followed by a practical pointer. No filler or redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two parameters, the description covers purpose, data scope, and parameter discovery. No output schema exists, but the description does not specify return format; however, the tool's simplicity and read-only annotation make this acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters (table_id, year) already described in the schema. The tool description's mention of bea_dataset_info adds some context but is redundant with the schema's table_id description. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('Input-Output statistics'), and explicitly lists the table types (Make, Use, Requirements). This clearly distinguishes it from other BEA tools like GDP or income statistics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance on discovering valid table IDs via bea_dataset_info, which is essential for correct use. It does not explicitly contrast with other BEA tools, but the purpose and coverage are clear enough for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_personal_incomeA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context about table options and line code meanings, but it does not disclose other behavioral aspects like rate limits, default response format, or handling of invalid parameter combinations. This aligns with the baseline for annotation-supported tools.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficiently structured with a brief opening sentence followed by clear bullet-pointed table options and line code lists. Every line earns its place, with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool (4 params, all optional, no enums, no output schema), the description covers the key choices and defaults needed to invoke the tool correctly. It does not mention return format or potential edge cases, but those are not critical given the schema's richness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with descriptions for all four parameters. The tool description repeats and reformats line code mappings but does not add significant new meaning beyond the schema. Thus 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb-resource pair: 'Get personal income data by state from BEA Regional dataset.' It further lists table options (SAINC1, SAINC3, SAINC4) and line codes, clearly distinguishing this from sibling GDP tools like bea_gdp_by_state. The purpose is unambiguous and well-scoped.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 personal income by state is needed) and provides table choices to select the right data subset. However, it does not explicitly mention alternatives or when not to use this tool (e.g., for GDP data use bea_gdp_by_state), so it stops short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bls_search_seriesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already tells the agent this is safe. The description adds that this is a curated lookup (not a live search) and lists supported topics, which gives useful behavioral context. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core action. The topic list is useful and each sentence serves a purpose. No waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, read-only, with full schema coverage and no output schema. The description explains the tool's raison d'être and scope. It doesn't specify return format, but that may not be critical for a lookup tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so both parameters are already documented. The description repeats the topic list, which mirrors the schema, and adds no extra parameter-level nuance. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Look up') and resource ('popular BLS series IDs'), clearly scoping it by topic. It does not explicitly differentiate from sibling tools like bls_series_data, but the purpose is unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: BLS has no search API, so this tool fills that gap with curated IDs. It doesn't name alternative tools for when to use them, so exclusions are missing. Still, the intended use case is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bts_border_crossingsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With the readOnlyHint annotation already indicating a safe read operation, the description adds useful context about monthly frequency and geographic scope. It does not disclose pagination behavior, default limits, or response format, but the schema covers the limit parameter and no destructive traits are implied.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loaded with the action and resource, and every phrase adds value. It efficiently conveys scope, coverage, and data dimensions without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description explains the key dimensions (port, state, measure type) and monthly granularity, which gives a good sense of the returned data shape even without an output schema. It does not detail response structure, pagination, or use cases, but for a read-only data lookup with five self-describing parameters, this is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already well-described (e.g., 'state' lists examples, 'measure' provides enumerations and clarifications). The description mentions 'by port, state, and measure type' which aligns with parameters but does not add semantic details beyond what the schema provides, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'Get border crossing data at U.S. ports of entry' using a specific verb and resource, and enumerates the measure types (trucks, personal vehicles, pedestrians, train passengers, containers). This clearly distinguishes it from sibling tools like bts_transport_stats, which cover broader transportation statistics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: it covers U.S.-Mexico and U.S.-Canada borders, monthly data, and dimension by port, state, and measure type. However, it does not explicitly state when to use this tool over alternatives or when not to use it, so it stops short of the 'explicit when/when-not' bar.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_birth_indicatorsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true. Description adds context that data is quarterly and provisional, and it enumerates supported topics. However, it does not disclose response structure, defaults, or edge cases, so it only modestly exceeds annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two clean sentences, front-loaded with the action and object, followed by a compact list of topics. No filler or repetition, every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only query tool with three optional parameters and no output schema, the description adequately covers purpose, key filters, and data types. It could mention default limits or response format, but it is sufficiently complete for selection and basic invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema describes all three parameters with valid options, achieving 100% coverage. Description reinforces the race/ethnicity and topic filters but provides no additional syntax, defaults, or value semantics beyond the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states 'Get quarterly provisional birth indicators' with a specific list of indicator types (fertility, teen birth, preterm, cesarean, low birthweight) and filter dimensions (race/ethnicity). This distinguishes it from sibling CDC tools by naming the exact domain and metric types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: use for birth-related indicators like fertility, teen birth, preterm, etc. It does not explicitly name alternatives, but the topic list and scope make the intended use apparent, so it meets 'clear context, no exclusions'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_causes_of_deathA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds useful context about the data range (1999–2017) and example causes, but does not disclose return format, pagination, or other behavioral details. It adds some value beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the core purpose and followed by essential data range and example causes. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With readOnlyHint true and fully documented parameters, the description provides adequate context for a simple filtered lookup. It does not explain return values, but given the lack of output schema and the tool's simplicity, the description is reasonably complete. Could mention limit behavior but is not severely lacking.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all three parameters (year, limit, state). The description's mention of 'by state and year' reinforces this but does not add new 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and clear resource ('leading causes of death in the U.S.') with scope ('by state and year'), effectively distinguishing it from other CDC tools that cover mortality rates or life expectancy. The title and sibling context reinforce this.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: it is for U.S. causes of death, filterable by state and year, with data from 1999–2017. It does not explicitly state when to use this over sibling CDC tools like cdc_mortality_rates, but the unique scope is implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_covidA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description adds value by noting the data ends in early 2023, which is critical for interpreting staleness. It also clarifies the state format (two-letter abbreviations). This goes beyond the annotation without being repetitive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the action and resource, no filler. Every word contributes to understanding the tool's purpose and data scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with two optional parameters and no output schema, the description provides essential context: data type (weekly case/death counts), geographic granularity (state), and temporal coverage (through early 2023). It does not describe response format, but given the simplicity, this is not a major gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters (limit and state) already have descriptions in the schema, achieving 100% coverage. The description's mention of state abbreviations is redundant with the schema's parameter description, so it adds minimal extra value beyond confirming the data context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('COVID-19 weekly case and death counts by state'), and adds precise scope ('data through early 2023'). It clearly distinguishes from sibling CDC tools like cdc_weekly_deaths (which likely covers deaths only) and cdc_causes_of_death.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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 need weekly COVID-19 case and death counts by state), but does not explicitly state alternatives or exclusions. It could improve by noting that other CDC tools cover different metrics or time frames, but that is left to the reader.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_mortality_ratesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safe read-only nature is known. The description adds useful context by noting the data is 'provisional' and specifying the time range (2020–present), but it does not disclose behaviors like pagination, rate limits, or how the limit parameter affects results. No contradiction exists, but the description adds only moderate transparency beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no fluff. The first sentence front-loads the core function and scope; the second provides concrete examples and return fields. Every sentence contributes meaningful information, and the structure is easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given four fully described parameters, a readOnly annotation, and no output schema, the description does a reasonable job of filling gaps by naming the return fields (rate_overall, rate_sex_female, rate_sex_male, per-state rates). It lacks explicit detail about the 'limit' parameter's behavior, but the schema covers that. Overall, the description combined with schema provides sufficient context for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage of all four parameters with clear descriptions, including valid cause options, quarter format, and rate_type enum. The description's list of causes partially duplicates the schema and adds no new parameter-level syntax. Its mention of output fields (rate_overall, etc.) is useful but pertains to response structure, not parameter semantics. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' and identifies the exact resource: provisional age-adjusted death rates by cause, sex, and state with a quarterly temporal scope. It lists concrete example causes and names return fields, making the tool's purpose unmistakable. Though it doesn't contrast with sibling CDC tools, the specific resource and scope distinguish it effectively.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly defines the tool's coverage (quarterly, 2020–present, by cause/sex/state), so an agent knows when this data will apply. However, it does not explicitly mention alternatives like cdc_death_rates_historical or cdc_weekly_deaths, nor provide exclusion criteria. The context is clear but lacks direct 'use this instead of X' guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfpb_complaint_aggregationsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation, and the description's 'Get' verb is consistent. It adds value by listing aggregation fields and use cases, but does not disclose response format, pagination, or how optional filters interact with grouping.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences: purpose, use cases, and allowed aggregation fields. Each sentence earns its place with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose, common grouping fields, and example use cases. Since no output schema is present, the return format is only implied ('counts grouped by a field'), but this is likely sufficient for this aggregation tool. It could mention optional filtering parameters or response structure for full completeness, but is not critically lacking.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with every parameter having a description and the 'field' parameter having an enum. The description repeats the aggregation fields and adds use-case context, but does not provide additional parameter syntax or interaction details beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get complaint counts grouped by a field' – a specific verb and resource. It lists common grouping fields and example use cases, clearly distinguishing this aggregation tool from sibling CFPB tools like cfpb_complaint_detail or cfpb_complaint_trends.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear use cases: 'Useful for ranking companies by complaint volume, identifying top issues, or comparing states.' It gives strong contextual guidance, though it does not explicitly name alternative tools or state when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfpb_complaint_detailA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, which covers the safety profile. The description adds behavioral context by listing the fields returned and noting the conditional 'narrative (if consented)', which is a non-obvious data availability nuance. It does not detail error cases or rate limits, but the read-only nature and return contents are well communicated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the primary action. Every word earns its place: purpose, parameter, and typical return fields. No redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description provides a strong overview of expected return contents (product, issue, company, narrative, response, dates). It does not mention things like error conditions or response format details, but for a simple 1-parameter detail tool, the guidance is sufficient. The 'etc.' is acceptable given the enumerated fields.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with the parameter already defined as 'CFPB Complaint ID number'. The description simply reiterates 'Complaint ID' without adding format, example, or source details. The schema carries the semantic load; the description adds minimal value beyond confirming the parameter's role.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get full details for a specific complaint by its Complaint ID.' It names the specific resource (complaint) and operation (get details), and distinguishes itself from sibling search/aggregation tools by focusing on a single known ID. The mention of returned fields reinforces its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The use case is implied: use when you have a specific Complaint ID and need full details. However, there is no explicit guidance on when not to use it or how it relates to sibling tools like cfpb_search_complaints or cfpb_complaint_aggregations. The description does not mention alternatives or a prerequisite of searching first.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfpb_suggest_companyA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, establishing safe read-only behavior. The description adds workflow context (finding exact company name) but does not disclose additional behaviors like return format, pagination, or naming quirks. With annotations covering the safety profile, this is adequate but not detailed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the core action and resource. Every word adds value, with no repetition or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter tool with a read-only annotation, the description is nearly complete: it states the purpose, source, and usage context. It does not describe the output format, but given the tool's simplicity and the schema coverage, this is a minor gap. A perfect score would require a bit more behavioral detail, but this is well above average.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% — both text and size have descriptions in the schema. The description does not add parameter-level detail beyond what the schema provides, so the baseline 3 applies. The phrase 'Autocomplete/suggest' somewhat implies partial text input, but the schema already shows examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource: 'Autocomplete/suggest company names from the CFPB complaint database.' This clearly distinguishes it from sibling CFPB tools like cfpb_search_complaints or cfpb_complaint_detail, and the action is concrete.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use it: 'before searching complaints' to find the exact company name. This provides clear context and implies the alternative (cfpb_search_complaints) without naming it explicitly. It does not include exclusion criteria, so it is a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cftc_cot_citA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the tool safe for read operations. The description adds useful context about the report type (Supplemental CIT), its relationship to the Legacy report, and the market scope limitation. However, it does not disclose pagination behavior, date ranges, or what fields are returned, though the schema covers pagination parameters.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with a clear verb and resource, and each sentence adds value: the first explains what the tool gets, the second explains the scope and relationship to the Legacy report. No wasted words or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (3 optional params, no output schema, read-only annotation), the description adequately covers the essential context: what the data is, its relationship to the Legacy report, and its limited market coverage. It does not detail return fields, but for this type of simple data-retrieval tool, that is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 contextual information about market coverage but does not provide additional detail about the specific parameters (limit, offset, market_name) beyond what the schema already describes. It neither improves nor harms parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves Supplemental Commodity Index Trader (CIT) report data from CFTC, identifies it as a supplement to the Legacy report, and notes it covers only 13 agricultural markets. This distinguishes it from sibling CFTC tools like cftc_cot_legacy, cftc_cot_disaggregated, and cftc_cot_tff.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by positioning the tool as a supplement to the Legacy report and explicitly warns that it covers only 13 selected agricultural commodity markets ('only' acts as an exclusion). It does not explicitly name alternatives or say when not to use it, but the scope limitation gives actionable guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cftc_cot_disaggregatedA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds content context (position breakdown categories, physical commodities scope) but doesn't disclose behavioral details such as default pagination, row limits behavior, or result structure beyond what annotations/schema convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with the primary purpose, each sentence earning its place (function → data structure → scope/differentiation). Zero waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 100% schema param coverage, readOnlyHint annotation, and no output schema, the description covers the core purpose, data categories, and scope boundaries effectively. It would benefit from mentioning pagination/result size behavior, but for a straightforward filtered-report tool, it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all 4 parameters with descriptions (100% coverage), so the baseline is 3. The description adds no parameter-specific guidance beyond what the schema already provides; the report-category info is useful context but doesn't enrich parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource ('Get Disaggregated Commitments of Traders (COT) report data from CFTC') and details the distinct position categories (Producer/Merchant/Processor/User, Swap Dealers, Managed Money, Other Reportables). It explicitly distinguishes this from the Legacy report, which is directly relevant given the cftc_cot_legacy sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: 'More granular than Legacy report' and 'Covers physical commodities (not financial futures)' — this tells the agent when to choose this tool over the Legacy sibling and identifies a clear exclusion. It doesn't explicitly name alternatives for the TFF/CIT siblings, but the main alternative is covered.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cftc_cot_legacyA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile, so the description adds value by describing data content (commercial vs non-commercial positions, market coverage). It does not disclose deeper behavioral traits such as pagination behavior, rate limits, or potential response size issues, but it is consistent with the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, front-loaded with the primary action, and each sentence adds relevant information: purpose, data content, coverage, and parameter usage. No extraneous details or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the read-only annotation, schema with 100% parameter coverage, and the simplicity of the tool, the description adequately explains what data is returned and how to filter. It does not specify return fields or mention alternative COT reports, but these are not critical for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, providing full parameter documentation. The description adds a brief restatement of the futures_only behavior, but no new meaning beyond the schema. This meets the baseline without exceeding it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get Legacy Commitments of Traders (COT) report data from CFTC,' using a specific verb and resource. It further distinguishes this tool from sibling tools by specifying 'Legacy' and describing its scope (commercial vs non-commercial positions, all U.S. futures exchanges).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context on what the tool returns and how to use the futures_only parameter ('Use futures_only=true for futures-only, false for combined futures+options'). However, it does not explicitly mention when to prefer this over sibling tools like cftc_cot_disaggregated or cftc_cot_tff, so no direct exclusions or alternative comparisons are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cisa_kev_listA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish readOnlyHint=true, so the safety profile is known. The description adds context by stating it 'Returns all actively exploited CVEs' and lists the entry fields (CVE ID, vendor, product, etc.). However, it does not disclose potential response size, pagination behavior, or any rate limits, leaving some behavioral uncertainty for a potentially large dataset.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, front-loaded with the tool's core purpose. Each sentence provides distinct value: purpose, return scope, entry composition, and filter capability. No fluff or redundant restatement of the name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description compensates by listing return fields and filter options. It covers the essential information for a list-retrieval tool. However, it doesn't mention potential large payloads or any limits, which would be useful for a catalog with 'all actively exploited CVEs.' Still, the description is adequately complete for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 five parameters. The description adds a grouping phrase ('narrow results by vendor, product, or date range') but omits ransomware_only. Since the schema fully explains each parameter, the description is not required to compensate; baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Get CISA Known Exploited Vulnerabilities with mandatory federal remediation deadlines.' It clearly differentiates from siblings like nvd_cve_search by focusing on the CISA KEV catalog and explicitly listing the returned fields. The purpose is unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: when you need CISA KEV data with federal remediation deadlines. It does not explicitly mention alternatives or when not to use it, but the unique scope (CISA vs NVD) is implied. This fits 'clear context, no exclusions'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clear_cacheA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=false, correctly indicating this is a mutating operation. The description adds the effect ('force fresh data on next query') and the scope (source-specific or all). However, it does not disclose potential consequences such as performance impact or irreversibility of clearing all cached data. Since annotations already signal the mutation, the bar is lower and the description meets it adequately.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences front-load the action and purpose. Every word earns its place, and there is no redundancy or filler. The structure is ideal for quick comprehension.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For this simple utility tool with one optional parameter, no output schema, and only a readOnlyHint annotation, the description covers the core aspects: what, when, and how. It could be improved by mentioning what the tool returns or any warning about clearing all, but the description is largely complete for its simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has one parameter 'source' with a 100% descriptive coverage, including a detailed list of valid values and 'Omit for all.' The tool description reiterates this ('Specify a source name or omit to clear all') but does not add significant semantic meaning beyond the schema. Baseline 3 is appropriate given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states what the tool does: 'Clear cached API responses to force fresh data on next query.' The verb 'clear' and resource 'cached API responses' are specific, and the purpose is explicit. It is distinct from sibling tools, none of which deal with cache management.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides context for when to use the tool ('to force fresh data on next query') and explains the sole parameter's behavior ('Specify a source name or omit to clear all'). It does not explicitly state when not to use it or mention alternatives, but given there are no alternative cache-clear tools, this is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clinical_trials_by_locationA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint already provided in annotations, the description adds the behavioral detail that the tool uses ClinicalTrials.gov's geo-distance filter to find trials within a radius, which is useful. However, it does not disclose default radius, pagination behavior, or return format, so it does not go beyond what annotations and schema already convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences, no redundancy, with the primary purpose front-loaded. Every sentence earns its place by explaining the mechanism and providing usage guidance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 7 parameters, no output schema, and only a readOnlyHint annotation, the description adequately explains what the tool does and how to combine filters. It lacks explicit mention of defaults (e.g., 50mi radius) or return field details, but those are partially covered by the schema, making this a reasonably complete description for a search tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all 7 parameters. The description adds little beyond the schema, only mentioning latitude/longitude and radius generically. It does mention combining with condition/intervention, but that is a usage tip rather than parameter-level semantic detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool searches for clinical trials near a geographic location, with a specific verb ('Search') and resource ('clinical trials') and a clear scope ('near a geographic location'). It distinguishes itself from generic trial search tools by explicitly mentioning the geo-distance filter and latitude/longitude radius.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by explaining the geo-distance filter and suggesting combination with condition or intervention filters. It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for a location-based trial search.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clinical_trials_enumsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it returns every enum type with all valid values, which is some behavioral context but does not cover output format or pagination. Thus it adds moderate value beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: first states the action, second describes the return content and usage. No fluff, front-loaded with the core purpose, and every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only enumeration tool with an optional filter, the description is mostly sufficient. It clearly communicates what is returned and when to use it. It does not describe the exact output structure, but given the low complexity and good schema coverage, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: the enum_type parameter is fully described in the schema. The description mentions example enum types (Status, Phase, StudyType, InterventionType) that align with the schema values, but does not add new semantics beyond what the schema provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'List all valid enum values for ClinicalTrials.gov data fields', with a specific verb and resource. It distinguishes itself from siblings by focusing on enum types (Status, Phase, etc.) and clarifies it returns all valid values, which is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: 'Use as a reference when building search filters or understanding field values.' This tells when to use the tool, but does not mention exclusions or alternatives (e.g., clinical_trials_field_values), so it lacks explicit when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cms_queryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint: true, so the agent knows this is a safe read. The description adds that it is general-purpose and supports filtering by any field, but it does not disclose behaviors like pagination semantics, error handling for invalid dataset_id or filter_field, or that results are limited/offset via schema parameters. It adds some value but not rich behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences, all delivering essential information: what it does, how to find dataset IDs, and that filtering is supported. No fluff, no repetition of schema content, and it is front-loaded with the core action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a generic query tool with a read-only annotation, 100% parameter coverage, and no output schema, the description covers the key workflow: query by dataset_id, use cms_search for IDs, and filter by any field. It could be more complete by noting pagination parameters (limit/offset) or dedicated alternatives for common datasets, but it is sufficient for correct high-level usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already documented. The description adds the claim 'Supports filtering by any field,' which relates to filter_field and filter_value but does not add syntax or format details beyond the schema. The baseline of 3 is appropriate because the schema carries the semantic weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'General-purpose query against any CMS provider dataset by dataset identifier.' It distinguishes itself from siblings by emphasizing its generic nature and explicitly referencing cms_search for dataset discovery. The scope is precise: any CMS dataset, with filtering by any field.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear usage context: use cms_search to find dataset IDs before querying. It implies this is the tool to use for arbitrary CMS datasets, but it does not explicitly exclude the dedicated sibling tools (e.g., cms_nursing_homes, cms_hospitals) that may be more appropriate for specific datasets. This is a minor gap in exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bill_actionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds the useful detail that roll-call vote numbers are shown when available, but doesn't disclose other behaviors like pagination or chronological ordering. Modest added value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences pack a clear purpose and a usage pointer with no filler. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose, the types of data returned, and the prerequisite search step. Without an output schema, it could specify more about return structure, but the description is sufficiently complete for this moderately simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are fully documented in the schema. The description only restates the need to obtain congress, bill_type, and bill_number via a search tool, adding no extra semantics beyond schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves the full action history/timeline for a bill, enumerating the stages (introduction, committee, floor votes, amendments, signing). It distinguishes itself from sibling tools like congress_bill_details or congress_bill_amendments by its specific scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly tells the agent to use congress_search_bills first to obtain required parameters (congress, bill_type, bill_number). This provides clear prerequisite context, though it doesn't explicitly contrast with alternative bill-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bill_amendmentsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the safe read nature is known. The description adds that it shows sponsors, purposes, and status, but does not disclose any additional behavioral nuances like pagination, sorting, or what counts as 'filed.' Given the annotation coverage, the description provides modest value but not rich behavioral context, warranting a 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences. The first sentence clearly states the tool's function, and the second provides valuable context without redundancy. Every word contributes to understanding the tool's purpose and significance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward retrieval tool with four parameters and no output schema, the description adequately conveys the input requirements (via schema) and the output content (sponsors, purposes, status). It does not go into depth about response format or edge cases, but for this simplicity level it is sufficiently complete, though not exhaustive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for all four parameters, so the schema already documents required and optional fields. The description does not add any parameter-specific semantics beyond what the schema provides, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the tool retrieves amendments filed on a specific bill, with a specific verb and resource. It also mentions the key data displayed (sponsors, purposes, status), and the example 'gutted and replaced' clarifies the use case, distinguishing it from sibling tools like congress_amendments or congress_amendment_details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for when to use the tool: 'Critical for tracking how bills are modified.' It implies this is the tool for amendment-level detail on a bill, but it does not explicitly contrast with alternatives or state when not to use it, so it falls short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bill_relatedA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile. The description adds useful behavioral context by naming the types of relationships it identifies, but it does not disclose response format, pagination behavior, or any other limitations beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short, impactful sentences. The first sentence front-loads the core purpose, and the second adds a meaningful use case without wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only related-bills lookup with a complete schema and a readOnlyHint annotation, the description is sufficient. It lacks an explicit description of return values since there is no output schema, but the tool's purpose and scope are adequately conveyed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all four parameters are already documented with descriptions (congress, bill_type, bill_number, limit). The description adds no parameter-specific information, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses specific verbs ('Find', 'Identifies') and clearly specifies the resource ('related/companion bills'), detailing three categories: House-Senate companion bills, identical bills, and bills with related provisions. This effectively distinguishes it from other congress bill tools like congress_bill_details or congress_bill_actions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Useful for tracking legislation across chambers' provides a clear context for when to use this tool. However, it does not explicitly mention alternatives or exclusions, so it stops short of fully explicit when/when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bill_subjectsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, and the description says 'Get' which is consistent. The description adds that the tool returns the primary policy area in addition to subjects, which is useful. However, it does not disclose behaviors like pagination, rate limits, or the meaning of 'subjects' further. With annotations already covering safety, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary purpose and followed by use cases. It contains no fluff or redundant information, earning full marks for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, no output schema, and read-only nature, the description adequately explains what is returned (subjects and policy area) and gives use cases. It could mention how 'limit' affects results or clarify the output format, but for a bill-tagging lookup, it is mostly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all four parameters (100% coverage), including 'congress', 'bill_type' with enum, 'bill_number', and 'limit'. The description references 'a bill' but adds no parameter-specific detail beyond that. Baseline 3 is appropriate since schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get legislative subjects tagged on a bill, plus the primary policy area.' This uses a specific verb (get) and resource (bill subjects), distinguishing it from sibling tools like congress_bill_titles or congress_bill_summaries that focus on other bill aspects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Description provides explicit use cases: 'Useful for finding all bills on a topic and for cross-referencing with lobbying data.' This gives applied context, but it does not explicitly name alternatives or state when not to use the tool. Still, the usage guidance is clear enough for an agent to select this tool over siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bill_summariesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds useful behavioral context beyond the annotation: the summaries are plain-English, non-partisan, and multiple versions may exist (as introduced, reported, passed). This gives the agent insight into the nature and variability of the returned data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose, and includes only relevant additional context about CRS summaries. There is no fluff or repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with no output schema, the description adequately conveys what the tool returns (summaries) and that there may be multiple versions. It does not specify the response structure or pagination, but given the straightforward nature of the tool and the existing annotations, the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides minimal descriptions for all three parameters ('Congress number', 'Bill type', 'Bill number'), achieving 100% coverage. The description does not add any further meaning about how these parameters should be used or formatted, so it does not exceed the baseline for complete schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get CRS summaries of a bill.' It specifies the resource (CRS summaries), the target (a bill), and adds context about the summaries being plain-English and non-partisan. This distinguishes it from sibling congress_* tools that focus on bill text, actions, or amendments.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used to retrieve summaries for a specific bill identified by congress, bill type, and bill number. However, it does not explicitly state when to use this tool over alternatives like congress_bill_details or congress_summaries_search, nor does it provide exclusions or alternative suggestions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bill_votesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description's main job is to add behavioral context. It explains the internal process (scans action timeline, fetches each vote) and output (member-level results, party tallies). No contradictions. It doesn't discuss failure modes or rate limits, but for a read-only tool with this context, it's solid.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a front-loaded purpose and workflow bullets, but it repeats the same output statement ('party-line breakdowns' and 'full party breakdowns' in both opening and closing). This redundancy costs a point against the high standard of concise tool descriptions.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description explains what is returned (member-level results and party tallies for House and Senate). The three parameters are simple, and the tool's behavior is clearly described. It could mention empty results or timeout behavior, but for a read-only composite tool, it covers essential context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters (congress, bill_type, bill_number) are already documented. The description adds no additional parameter-specific semantics beyond 'specific bill'. Baseline for full schema coverage is 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Find ALL roll-call votes on a specific bill and fetch the party-line breakdowns.' It distinguishes itself from sibling tools like congress_house_votes and congress_senate_votes by emphasizing 'ALL roll-call votes' for a bill across both chambers, positioning it as the composite 'Bill → Votes' bridge.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides workflow context ('Bill → Votes (this tool) → ...'), and explains it scans the bill's action timeline, implying when this tool is appropriate for legislative accountability research. It does not explicitly exclude alternatives like congress_house_votes or congress_senate_votes, but the 'ALL' and 'composite' framing signals it as the comprehensive choice. Slight gap in naming alternative conditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bound_congressional_recordA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description does not need to state safety. It adds context about the bound nature and filtering capability, but does not disclose behaviors like pagination limits, what happens with no filters, or response format. The added context is useful but limited beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the main action ('Get bound Congressional Record issues'), and includes the key qualifier 'permanent, final publication' without any fluff. Every phrase earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description conveys the essential purpose and distinguishes from the daily edition. While no output schema exists, the description does not specify the return format or pagination behavior, but given the tool's simplicity and full schema coverage, it is reasonably complete for an agent to understand the tool's role.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 four parameters (year, month, day, limit). The description adds only a high-level 'Filter by year, month, and day,' which does not enrich parameter semantics beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get bound Congressional Record issues' with a specific verb and resource. It further clarifies 'the permanent, final publication of proceedings,' distinguishing it from sibling tools like congress_daily_congressional_record.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'permanent, final publication' provides clear context that this tool is for the bound edition as opposed to daily editions, implying the appropriate use case. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_nominations_for_committeeA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds some context about the nomination types and committee focus but does not disclose additional behaviors such as pagination limits, response format, or the necessity of using a specific committee code from another source.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states the action with a verb and resource, and the second provides a use case. There is no redundant or extraneous wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple filtered-list tool with a readOnlyHint annotation and a fully documented schema, the description is adequate. It conveys the tool's purpose and likely scenario, though it does not describe the return values or any edge cases, which would be helpful 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema clearly documents the 'limit', 'chamber', and 'committee_code' parameters. The description adds meaning by noting the typical use for Senate committees and judicial/agency nominations, but this does not significantly supplement the schema's own descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets nominations referred to a specific committee, using a specific verb and resource. It distinguishes itself from sibling tools like congress_nominations (which gets all nominations) and congress_nomination_committees (which gets committees for a nomination) by emphasizing the direction 'nominations... before a particular Senate committee.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description says it is useful for tracking judicial or agency head nominations before a Senate committee, giving clear context for when to use it. However, it does not explicitly state when not to use it or name alternative tools for broader nomination queries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_print_detailsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, covering the safety profile of this read operation. The description adds no extra behavioral context (e.g., response structure, ordering, or scope) beyond the statement of purpose, which is acceptable given the annotation coverage but does not exceed it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the action and all required identifiers. It contains no redundant content or filler, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only detail lookup with three fully specified required parameters and a readOnlyHint annotation, the description is adequate. It does not explain what 'details' includes or the return format, but the tool's simplicity and the clear identifier-based lookup make this a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with each parameter described (chamber, congress number, jacket number). The tool description merely reiterates these parameter names without adding deeper meaning or relationships, so it does not surpass the baseline for fully documented schemas.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get details about a specific committee print' with a specific verb and resource, and specifies the needed identifiers (congress, chamber, jacket number). This distinguishes it from sibling tools like congress_committee_prints (a list/search tool) and congress_committee_print_text (which focuses on text content).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use it when you need details about a specific committee print and have the three identifiers. It does not explicitly name alternatives or exclusion criteria, but the specificity ('specific committee print') implicitly guides the agent away from search/list tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_printsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile. The description adds clarifying context about the content (non-report publications, sometimes containing bill text) but doesn't disclose details like pagination, default limits, or response structure. This meets the baseline for a read-only list tool with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action and resource, then provides a brief clarifying definition. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool with five filter parameters and a readOnly annotation, the description sufficiently explains the tool's purpose and scope. It lacks details about output structure, but that is not required given the lack of an output schema and the straightforward nature of the operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with all parameters (limit, chamber, congress, toDateTime, fromDateTime) having descriptions. The description adds no additional parameter-specific meaning beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'List committee prints' with a specific resource and action. It further defines what committee prints are ('publications ordered by committees that are not committee reports'), distinguishing it from the sibling tool congress_committee_reports.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly guides usage by contrasting committee prints with committee reports and noting the common inclusion of Rules Committee prints with bill text. It does not explicitly name alternatives or state when-not-to-use, but the distinction from reports provides enough context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_senate_communicationsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals this is a safe read operation, so the description's job is lighter. The description adds the committee scoping constraint but does not disclose other behavioral aspects such as pagination or the shape of the returned data. This is adequate but not rich beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 11 words, front-loaded with the verb 'Get' and the resource. Every word contributes to understanding, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For this two-parameter read-only list tool, the description and schema together provide enough context to invoke it. There is no output schema, so a hint about the response format would be helpful, but the tool's name and the phrase 'Senate communications' make the expected return type reasonably inferable. Slight room for improvement in describing the output.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for both parameters, including descriptions for committee_code (with an example) and limit (default/max). The description adds no additional parameter semantics, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get'), identifies the resource ('Senate communications'), and includes the scoping qualifier ('referred to a specific Senate committee'), which clearly distinguishes it from sibling tools like congress_senate_communications that likely return all communications. This is a precise and unambiguous purpose statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool—when you need Senate communications for a particular committee—and the scoping makes it obvious that it is not the general Senate communications tool. However, it does not explicitly name alternatives or provide 'when not to use' guidance, so it falls short of full usage guidelines.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_house_requirement_detailsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds what data is returned (legal authority, frequency, nature, matching communications count) but does not disclose additional behavioral traits such as error handling, permissions, or rate limits. With the annotation lowering the bar, this adds some value but not rich context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the core purpose and includes the key response fields without any filler. Every word adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only lookup tool with one required parameter and no output schema, the description adequately covers what the tool returns by listing the key fields. It is complete enough for an agent to select and invoke it correctly, though it could have mentioned alternative tools or error behavior for a higher score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage with the parameter description explaining that requirement_number is the requirement number (e.g., 8070). The tool description does not add any additional meaning beyond what the schema already provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('detailed information about a specific House requirement'), and enumerates the included fields (legal authority, frequency, nature, matching communications count). This clearly distinguishes it from sibling tools like congress_house_requirements (listing) and congress_house_requirement_matching_communications (focused on communications).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'specific House requirement' implies you need a requirement_number to retrieve details, providing clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_house_requirementsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates a safe read operation. The description adds behavioral context by explaining that the tool lists recurring reporting obligations and includes specific output fields (requirement number, frequency, matching communications count). It does not contradict the annotations and provides value beyond what the structured data already conveys.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two efficient sentences, front-loaded with the core purpose and no extraneous content. Every phrase contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter list tool with a readOnly annotation, the description adequately explains what the resource is and what fields are returned. It doesn't mention pagination or a detailed return structure, but the limit parameter is covered by the schema and the output fields are specified, making it reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description for 'limit' is complete (max results, default 20, exclusiveMinimum 0), providing 100% coverage. The tool description adds no extra parameter details, but the baseline is 3 because the schema fully describes the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('List') and a clear resource ('House requirements'), and further distinguishes the tool by defining it as 'recurring reporting obligations from executive agencies to Congress' while noting the displayed fields (requirement number, frequency, matching communications count). This clearly separates it from sibling tools like congress_house_communications or congress_house_requirement_details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the listing tool for House requirements but does not explicitly state when to use it versus related tools such as congress_house_requirement_details or congress_house_requirement_matching_communications. No exclusions or alternatives are mentioned, so guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_member_billsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, establishing a safe read operation. The description adds the scope (sponsored or cosponsored) and the required ID context, but does not disclose return format, pagination, or sorting behavior. This is acceptable given the annotation coverage, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, zero waste. First sentence states purpose, second gives the prerequisite and a pointer to the sibling tool. Ideal structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read tool with full schema coverage and readOnlyHint annotation, the description is adequate. It doesn't describe the return payload, but no output schema exists and the task is straightforward. The only minor gap is lack of distinction from other member/bill tools, but purpose clarity covers that.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all three parameters (type, limit, bioguide_id) documented. The description only adds the hint to use congress_search_members to find the bioGuide ID, which is marginal beyond the schema's examples. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('bills sponsored or cosponsored by a specific member of Congress'), clearly distinguishing it from sibling tools like congress_search_members (which finds the member) or congress_bill_cosponsors (which lists cosponsors of a bill). It fully explains the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states the prerequisite (member's BioGuide ID) and directly references congress_search_members to obtain it. Itimplies the use case (finding a member's sponsored/cosponsored bills) but does not explicitly enumerate alternative tools for related queries, so it lacks exclusionary guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_nomination_committeesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds useful context about the returned data (referral, hearing, discharge) but does not disclose pagination limits, authentication requirements, or other behavioral nuances. It is adequate for a simple read-only tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the main action and followed by a brief clarification of what the tool returns. No filler or redundant information is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with two well-described parameters, a read-only annotation, and a clear statement of output content. Although no output schema exists, the description gives a high-level view of the data (committee activities). More detail on response structure would improve completeness, but it is sufficient for most use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters (congress, nomination_number) are fully described in the input schema with 100% coverage. The description adds no additional meaning or constraints beyond what the schema already provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('committees') with a clear qualifier ('associated with a nomination'), which unambiguously distinguishes it from sibling tools like congress_nomination_hearings or congress_nomination_details. It also lists what it shows (activity types), reinforcing the tool's unique purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 needing committees for a nomination) but does not explicitly mention alternatives or when not to use it. Given the many congress_* siblings, a note on differentiation would help, but the scope is clear enough for an agent to select it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_recent_lawsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is established. The description adds that results show 'legislation that has become law,' which is helpful but does not disclose nuances such as how 'recent' is defined (e.g., current Congress default) or default pagination. For a simple read-only list tool with annotations, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action verb 'Get,' and every word adds value. It efficiently conveys the core purpose and the optional filter without rambling.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with 3 optional params, no output schema, and read-only annotations, the description covers the essentials: what it returns and the key filter. The minor gap is not defining 'recently' (e.g., default to current Congress or a time window), but overall it is complete enough for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with each parameter (limit, congress, law_type) having clear descriptions and defaults/enums. The tool description merely restates the law_type filter ('public or private') without adding new details. Baseline 3 is appropriate since the schema carries the full parameter burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get recently enacted laws (bills signed by the President).' It clearly distinguishes this from bill search or law details by defining the scope as enacted laws with an optional filter by law type. This is unambiguous and differentiates from sibling tools like congress_search_bills or congress_law_details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this when you need recently enacted laws, optionally filtered by public/private type. It does not explicitly mention alternatives or exclusions (e.g., 'use congress_search_bills for broader bill search'), but the specificity of 'recently enacted' implies appropriate use. Lacks explicit when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_treaty_partitioned_actionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds content about what actions are shown. It does not disclose pagination, default limits, or any ordering behavior, but these are minor for a read-only list tool. Since annotations carry the safety burden, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action and resource, and includes specific details (committee referral, hearings, ratification votes) without any filler. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with a well-described schema and no output schema, the description sufficiently explains the tool's purpose and the kind of data returned. It could mention the required parameters or the distinction from partitioned details, but the current description is enough to understand usage in most cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all 4 parameters with 100% coverage, including treaty_suffix as 'Treaty partition letter (e.g., 'A', 'B')'. The description echoes this by referring to 'suffix letter' but adds no new parameter-level information. Baseline 3 is correct when schema covers all parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get actions') and clearly identifies the resource: a partitioned treaty (one with a suffix letter). It also lists the specific content returned (committee referral, hearings, ratification votes), which distinguishes it from related treaty tools like congress_treaty_details or congress_treaty_partitioned_details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: for treaties with a suffix letter (partitions). It does not explicitly name alternatives or exclusions, but the parenthetical clarification and content listing make the intended use obvious. It could be improved by explicitly contrasting with non-partitioned treaty tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• coops_current_predictionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation, so the description does not need to restate that. It adds value by noting the output ('predicted current speed/direction'), but it does not disclose additional behavioral traits such as pagination, date restrictions, or error cases. This is acceptable given the annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two sentences and front-loads the core purpose. Every word contributes meaning, with no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is brief but sufficient given the high schema coverage and clear annotations. It states the return type, which is important since there is no output schema. It does not describe parameter combinations or advanced usage, but for a straightforward current predictions tool, the current level is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (all 8 parameters have descriptions), so the description is not required to document parameters. The tool description itself adds no extra parameter semantics beyond the schema's existing coverage, which meets the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and a clear resource ('current predictions for a NOAA CO-OPS station'), and states the return content ('predicted current speed/direction'). It clearly distinguishes from siblings like coops_tide_predictions by specifying 'current', and from coops_currents by specifying 'predictions'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies the tool is for predicted current data at NOAA CO-OPS stations, providing context for when to use it. However, it does not mention explicit alternatives or exclusion criteria, though the tool name and description make the intended use evident compared to related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• coops_station_metadataA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description is consistent. It adds useful behavioral context by specifying the types of data returned (location, sensors, datums, products available), which goes beyond the bare read-only flag. It does not mention output format or rate limits, but the bar is lower given annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no filler. The first sentence states the action and resource; the second lists representative output contents. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 parameter) and strong schema/annotations, the description provides adequate contextual completeness by outlining what the response includes. The trailing 'etc.' slightly weakens completeness, but the description is sufficient for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides full coverage for the single parameter (station_id) with an example, so the description adds little beyond confirming the tool is for a specific station. Baseline 3 is appropriate because the schema handles the semantic load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and names the exact resource ('detailed metadata for a specific NOAA CO-OPS station'), making the tool's function immediately clear. It also lists returned content categories (location, sensors, datums, products), which distinguishes it from sibling tools like coops_water_level or coops_tide_predictions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied: call this tool when you need metadata for a known station. However, it does not explicitly mention alternatives (e.g., use coops_stations to discover station IDs) or provide when-not-to-use guidance, leaving usage context only implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• coops_stationsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already discloses the safe read-only nature. The description adds that filtering by type and state is optional, which is useful, but does not elaborate on return format, pagination, or default behavior when no filters are provided. This is adequate for a simple list tool 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the main purpose in the first sentence. The second sentence quickly explains optional filters. It avoids redundant detail and every sentence contributes to understanding the tool's function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list/search tool with two optional parameters and no output schema, the description is largely complete. The only gap is that it doesn't clarify what 'search' means beyond filtering (e.g., by name), but this is a minor omission given the tool's simplicity and the annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for both parameters ('type' and 'state'), so the description adds little extra information beyond what the schema already conveys. The description repeats the parameter meanings but does not introduce new semantics. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'List/search NOAA CO-OPS stations.' It specifies the resource (NOAA CO-OPS stations) and the verb (list/search), and distinguishes it from sibling tools like coops_water_level and coops_tide_predictions which retrieve specific data types rather than station metadata.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use this tool: to list/search stations, with optional filters by type and state. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for an agent to select it over sibling tools that serve different purposes.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• coops_water_levelA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description's 'Get' aligns with that. The description adds minimal behavioral context beyond the annotations, such as the date format and shortcuts, but these are already present in the schema. It doesn't disclose limitations, default units, or the nature of the returned data, so it adds little beyond the structured metadata.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise, two sentences that immediately convey the purpose and the minimal required inputs. It is front-loaded with the action and resource, and every clause serves a functional role without any redundancy or boilerplate.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with a well-documented schema, the description is nearly sufficient. It covers the essential inputs (station and date) and the distinction from predicted data. However, it does not mention the optional parameters or default behaviors (e.g., default units), leaving some context to the schema. Still, the schema is rich enough to compensate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already documented. The description essentially restates the station and date requirements without adding new meaning. It reinforces that station is required and that dates can be a range or shortcut, but this is already captured in the schema's descriptions and enums, so it provides no additional value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves observed water levels from a NOAA CO-OPS station, using the specific verb 'Get' and identifying the resource and source. It distinguishes itself from sibling tools like coops_tide_predictions and coops_high_low by emphasizing 'observed' water levels, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on how to invoke the tool (provide station ID and date range or shortcut) but does not explicitly name alternative tools for predicted levels or when not to use this tool. The 'observed water levels' wording implies a contrast with prediction tools, but lacks explicit exclusions or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• coops_water_qualityA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description's 'Get' aligns with that, showing no contradiction. The description adds modest context by specifying the data type, but it does not disclose additional behavioral traits such as date handling, station coverage, or return format. With annotations covering the safety aspect, the description meets the baseline but adds no extra depth.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states what the tool does without any unnecessary words or repetition. It is highly concise and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description clearly communicates the tool's purpose and data type, while the schema fully documents parameters and required fields. Although there is no output schema, for a simple read-only data retrieval tool, the combination of description and schema is sufficient for an agent to select and invoke it correctly. It does not overpromise or understate the tool's functionality.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all parameters, including station, dates, units, and shortcuts. The description does not add parameter-specific guidance beyond what the schema already provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and identifies the exact resource ('NOAA CO-OPS station') and data type ('conductivity/salinity (water quality)'). This clearly distinguishes it from sibling CO-OPS tools like coops_water_level and coops_tide_predictions, which focus on different data types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when conductivity/salinity data is needed at a CO-OPS station, and the sibling names reinforce this context. However, it does not explicitly state when not to use it or mention alternative tools, though the specificity of the description makes the intended use clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cos_occupation_searchA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description need not restate safety. It adds behavioral context by describing the return fields (O*NET codes, titles, descriptions) and suggesting follow-up usage, but does not disclose details like pagination or rate limits, which are not expected for this simple read tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences: purpose, return content, and follow-up guidance. Every sentence contributes meaningful information without redundancy, making it well-structured and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with well-documented schema and readOnly annotation, this description is sufficient: it states what the tool does, what it returns, and how to use results. The lack of an output schema is compensated by the explicit mention of returned fields. Minor gaps like result limits or default state behavior are not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters (keyword, location) have complete descriptions in the schema, covering 100% of the schema. The tool description does not add any parameter-specific details beyond what the schema already provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Search occupations by keyword using the CareerOneStop API,' which clearly identifies the action, resource, and data source. It also specifies the return content (O*NET codes, titles, descriptions), distinguishing it from sibling cos_licensing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for keyword-based occupation queries and advises using returned O*NET codes for 'more specific lookups,' giving a clear usage context. However, it does not explicitly compare to alternatives or state when not to use the tool, so it earns a 4 rather than 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cpsc_penalty_companiesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds context about the expected input source (company names from search results) and penalty types, but does not disclose other behaviors like pagination or return format. This is adequate given the annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, first sentence states the purpose, second gives workflow guidance. No redundant filler, front-loaded and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one parameter, schema coverage is complete, annotations cover safety, and the description addresses purpose and usage. It does not explain return format, but that is not critical for this type of tool. Overall, the information is sufficient for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides full coverage for the single parameter (penalty_type) with an enum and description. The description reinforces the civil/criminal values but adds no new semantic meaning. Baseline 3 is appropriate since schema carries the weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists companies with CPSC penalties (civil or criminal). The verb 'List' and resource 'companies that have CPSC penalties' are specific, and the civil/criminal scope distinguishes it from related tools like cpsc_penalty_search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance by instructing users to 'Use the company names from results with cpsc_penalty_search,' which clarifies the workflow and relationship to the sibling tool. It lacks explicit exclusions or alternatives, so a score of 4 is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cpsc_recall_searchA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful context about the date format (MM/DD/YYYY) and the requirement to use at least one filter, but does not disclose other behavioral traits such as pagination, result limits, or output structure. This is consistent with the calibration example where a similar level of added context merits a 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, front-loaded with the primary purpose, and includes an example in just a few lines. Every sentence contributes value without redundancy or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with 10 optional parameters and no output schema, the description covers the search criteria, date format, and usage example. It does not describe the return format or pagination, but the purpose is clear and the annotations provide safety context. Given the complexity, the description is nearly complete but could benefit from a note on what the response contains.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all 10 parameters. The description adds a high-level summary of parameter categories and an example, but does not add substantial meaning beyond what the schema already provides. Thus 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches CPSC consumer product recalls and lists specific searchable attributes (product name, manufacturer, hazard, date range, recall number). This distinguishes it from sibling tools like cpsc_recall_detail (which likely retrieves a specific recall) and cpsc_penalty_search (which searches penalties).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for use: it's a search tool with optional filters and requires at least one parameter. It includes an example demonstrating parameter combinations. However, it does not explicitly mention alternatives like cpsc_recall_detail for when a specific recall number is known, though the distinction is implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dap_domain_reportA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the source (Digital Analytics Program) and domain scope, but does not disclose other behavioral traits like date filtering, pagination, or response format. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences plus a succinct example. It is front-loaded with the core purpose and contains no fluff, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given a well-documented schema and readOnlyHint annotation, the description provides enough context for use. The example adds practical guidance. Without an output schema, some return-structure information is missing, but the tool's nature as an analytics report is reasonably clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all six parameters. The description's example (domain='nasa.gov', report='browser', limit=50) illustrates typical usage but does not add meaning beyond the schema's parameter descriptions, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get a domain-specific web analytics report from the Digital Analytics Program,' which is a specific verb + resource pair. It also states 'Returns analytics data for a specific government website domain,' clearly distinguishing this from sibling tools like dap_gov_wide_report and dap_agency_report.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool (for a specific government website domain) via 'domain-specific' and 'specific government website domain.' However, it does not explicitly mention alternatives or when not to use it, so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• doj_blog_detailA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already marks this as a safe read operation, and the description adds value by stating the exact return fields (complete body, component, topic, date, URL). No contradictions with the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, no filler, front-loads the purpose and then specifies the return content. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only fetch with no output schema, the description adequately explains what the caller gets. It lacks explicit error handling details, but these are not critical for such a simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides full coverage of the single 'uuid' parameter with a clear description. The tool description adds minimal extra nuance by mentioning 'full text' and return fields, but the schema already carries the load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 specific resource 'full text of a specific DOJ blog entry', with the identifier type (UUID). It distinguishes this tool from sibling list tools like doj_blog_entries by focusing on the detail fetch.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a UUID is known (from search results, as noted in the parameter schema), but it does not explicitly state when to choose this over alternatives or mention any exclusions. No alternative tools are referenced.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• doj_blog_entriesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers safety. The description adds the dataset size (3,200+ records) and content coverage, which is useful. However, it doesn't disclose pagination behavior, sorting defaults, or return format, so it provides moderate additional transparency beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences, front-loaded with the primary action. Each sentence adds value: what it does, why you might use it, and what it covers. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with optional pagination parameters and no output schema, the description adequately explains the tool's purpose and scope. It could mention that results are paginated or that the endpoint returns a list, but this is inferable from the schema and the tool name.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema documentation covers all 4 parameters with descriptions (page, sort, pagesize, direction). The description adds no parameter-level details, so with 100% schema coverage, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Search DOJ Office of Public Affairs blog entries') and specifies the resource with a record count. It differentiates from sibling tools by noting blog entries provide more context/analysis than press releases, making it distinct from doj_press_releases.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on when to prefer this tool: when more context and analysis than press releases is needed, covering policy discussions, division activities, and enforcement context. It doesn't explicitly name alternatives like doj_blog_detail, but implies a distinction from press releases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• doj_press_releasesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, so the safety profile is already known. The description adds useful context about the data scale (262K+ records), lineage (all DOJ divisions, FBI, DEA, etc.), and content types (enforcement actions, indictments, settlements), but does not disclose response format, pagination behavior, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the primary verb and resource. Each sentence contributes value: scope (262K+ records, all divisions), content types, filtering/sorting capabilities, and example components/topics. No redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the moderate complexity (5 optional params, no output schema) and strong annotations, the description covers the essential aspects: what is searched, how to filter/sort, and what types of content are included. It does not describe the return format, but the lack of an output schema makes this a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already well-described (e.g., 'Filter by title keyword: cybercrime, antitrust', 'Sort direction: DESC (newest first, default)'). The description only restates this capability without adding new meaning, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with the specific verb 'Search' and the resource 'DOJ press releases', immediately clarifying the tool's function. It distinguishes itself from the sibling 'doj_press_release_detail' by emphasizing its broad scope (all DOJ divisions, 262K+ records) and search-oriented capabilities.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates this is for searching across all DOJ press releases, with filtering by title keyword and sorting by date. It provides context for when to use this tool but does not explicitly mention alternatives like 'doj_press_release_detail' for retrieving full details, nor does it state exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dol_osha_accident_injuriesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the read-only nature is established. The description adds useful context by listing return fields and explaining the degree-of-injury coding (1=Fatality, 2=Hospitalized, 3=Non-hospitalized). It also notes the linkage via summary_nr, going beyond the annotations. No contradictions found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four concise sentences, front-loaded with the main purpose. Each sentence adds distinct value: purpose, return fields, degree value mapping, and linking mechanism. There is no redundant or fluff content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with a fully covered schema, the description is mostly complete. It explains what the tool does, what it returns, and how to link to accidents. A small gap is the lack of explicit guidance on how summary_nr relates to the dol_osha_accidents tool, but the linking note suffices for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all four parameters documented (limit, offset, summary_nr, degree_of_inj). The description's mention of 'Link to accidents via summary_nr' and the degree-of-injury mapping largely repeats the schema descriptions. Since the schema already provides full parameter semantics, no additional meaning is added.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's purpose: 'Get injury details from OSHA accident investigations.' It specifies the returned fields (demographics, nature of injury, body part, source, degree of injury) and distinguishes it from sibling tools like dol_osha_inspections and dol_osha_violations by focusing on injury-level details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a usage hint: 'Link to accidents via summary_nr,' implying it should be used with a known accident summary number. However, it does not explicitly state when to prefer this tool over alternatives like dol_osha_accidents, nor does it describe when not to use it. The usage guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ecfr_sectionA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint: true, so the safety profile is known. The description adds that it returns 'rendered regulation content,' which gives some output context, but does not disclose further behavioral traits such as pagination, large response sizes when requesting an entire part, or date-based versioning behavior beyond what the schema already implies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose, followed by helpful workflow guidance. There is no redundant phrasing or unnecessary detail, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description provides the primary function, return format, and a clear workflow with sibling tools. Since there is no output schema, it could benefit from more specifics on the structure of the rendered content, but for a simple retrieval tool with well-documented parameters, it is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with each parameter described. The description does not add new parameter semantics; it only restates that both section and part can be retrieved. Since the schema is fully descriptive, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get the full text of a specific CFR section or part. Returns the rendered regulation content.' It uses a specific verb and resource, and distinguishes itself from sibling tools ecfr_search and ecfr_title_structure by indicating they are preceding discovery steps.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly guides the agent to 'Use ecfr_search or ecfr_title_structure first to find the title, part, and section numbers,' establishing a clear workflow and naming alternatives for finding identifiers. It does not mention when not to use the tool, but the guidance is direct and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eia_natural_gasA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful context beyond the readOnlyHint annotation by disclosing the specific data series available (citygate, electric power, commercial, industrial, residential, Henry Hub spot) and their corresponding process codes. It does not contradict the annotation, but it omits details on units, output format, or data granularity, which would be useful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences: the first clearly states the purpose, and the second compactly lists process codes and their meanings. There is no fluff, and the information is front-loaded for quick parsing by an AI agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only data retrieval tool, the description covers the essential options (price series and process codes). It is slightly incomplete in not clarifying how it differs from sibling EIA data tools, which would help an agent decide when to invoke it, but it does not need to explain return values since there is no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  While the input schema has 100% description coverage, the tool description adds critical value by including the PNG code for Henry Hub spot, which is missing from the schema's process parameter enum. It also reiterates the meaning of the codes, reinforcing and supplementing the schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves natural gas prices and enumerates specific price categories (Henry Hub spot, citygate, residential, commercial, industrial, electric power). It distinguishes itself from sibling EIA tools (e.g., eia_petroleum, eia_electricity) by explicitly naming natural gas as the resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives like eia_petroleum or eia_total_energy. The description lists process codes but does not explain selection criteria or context for choosing this data source over other EIA datasets.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• epa_rcraA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so the read-only nature is already known. The description adds context about the regulatory program (RCRA Subtitle C) and the source (ECHO), but does not disclose behavioral quirks such as pagination, default limit, response structure, or any rate limits. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each earning its place: purpose, facility types returned, and cross-reference tip. No fluff, front-loaded with the primary action and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description adequately states what is returned (facility types) and the input dimension (state). For a simple 2-parameter tool without an output schema, it is mostly complete. It does not mention limit defaults or result ordering, but the schema covers limit, and the missing output schema is not a critical gap given the clarity of returned facility categories.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both 'state' and 'limit' well-documented in the schema. The description does not add any additional meaning beyond the schema, but since the schema carries the full burden, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses specific verb 'Search' and resource 'RCRA hazardous waste facilities by state via ECHO', clearly distinguishing this from sibling EPA tools like epa_facilities or epa_toxic_releases. It further specifies the return scope (generators, transporters, TSD facilities) under RCRA Subtitle C.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: searching hazardous waste facilities by state, and explicitly suggests cross-referencing epa_toxic_releases and epa_greenhouse_gas for multi-program analysis. It lacks explicit exclusion criteria (when not to use), but the context is sufficient for an agent to choose this tool over generic facility searches.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fbi_crime_summarizedA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral context beyond the readOnlyHint annotation by specifying that it returns year-by-year data with counts and rates. It also clarifies the scope levels. However, it doesn't mention how conflicting parameters (e.g., both state and ori) are handled, which is a minor gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the core purpose, and every sentence provides useful information (levels, offense codes, return format). No wasted words or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description adequately explains return values (year-by-year counts and rates). It covers the required offense parameter and the optional level selectors. It could be slightly more complete by noting potential default year ranges, but the schema already handles those details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 semantic value by implying that national level is the default when neither state nor ori is provided, which is not explicitly stated in the schema. This helps the agent understand the parameter selection behavior.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets summarized UCR crime data at national, state, or agency level, with a specific verb ('Get') and resource. It lists the 10 offense categories, making it distinct from sibling FBI tools like fbi_arrest_data or fbi_nibrs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 fbi_arrest_data or fbi_nibrs. It doesn't state exclusions or prerequisites, leaving the agent to infer from the word 'summarized' without explicit direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fbi_expanded_propertyA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds useful context by naming the data source (Supplemental Return / Return A) and the specific breakdowns available (stolen/recovered value, property type, premises). It does not describe return format, pagination, or other behavioral details, but the annotation lowers the burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the primary action, and each sentence adds distinct value: the resource, the data granularity, and the available offense codes. There is no filler or redundant restating of the tool's name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only data retrieval tool with a 100% covered schema, the description provides sufficient context for selection and invocation. It explains what makes this expanded data distinct from summarized data and enumerates the valid offense codes. It does not address the type parameter (counts vs totals), but the schema fully documents it, and no output schema exists to complicate understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 some semantic value by expanding the offense codes into full crime names in prose, but this largely duplicates the schema's own parameter descriptions. No additional parameter behavior is explained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: retrieving expanded property crime details from the FBI, specifically Supplemental Return / Return A data. It distinguishes itself from related FBI tools by noting it provides breakdowns beyond summarized counts and lists the covered offense codes (NB, NL, NMVT, NROB).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys when this tool is appropriate by contrasting it with 'summarized counts' and outlining the available offense types. It does not explicitly name sibling tools or provide when-not-to-use instructions, but the context is clear enough for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fbi_nibrsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the read-only nature, so the description does not need to restate it. It adds context about the data richness and offense code format, but does not disclose other behavioral traits such as pagination, rate limits, or return structure. With the annotation providing the safety profile, this is adequate but not extensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the tool's identity and resource, and packs substantive detail without fluff. It is well-structured and 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.

  Completeness4/5

  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 provides a strong overview of the data type and offense code format, which helps the agent understand what to expect. It does not explain return structure or the type parameter, but the schema covers parameter semantics. Overall, it is fairly complete for a data retrieval tool with a rich parameter schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are documented in the schema. The description adds value for the offense parameter by giving real-world examples (13A, 09A, etc.) and confirming the NIBRS code format. However, it introduces a minor inconsistency by saying 71 offense types while the schema lists 72, and it does not add information about other parameters beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves NIBRS data from the FBI with a specific verb (Get) and resource. It explicitly contrasts with summarized UCR data, distinguishing it from sibling FBI crime tools like fbi_crime_summarized, and provides concrete offense code examples, making its purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool—when detailed incident-level data (demographics, weapons, location, time of day) is needed rather than summarized UCR. It contrasts with summarized UCR data, indicating a clear use case, but it does not name a specific alternative tool or state explicit exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fcc_broadband_coverageA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful return-value context (providers, technology types, advertised speeds). However, it does not disclose potential behavioral caveats such as data vintage, coverage granularity, or behavior when no location is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three succinct sentences, each adding value: what it does, what it returns, and how to provide input. No wasted words or repetition of schema fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description adequately covers the key return elements and input requirements. It doesn't note whether filters are optional or address/lat-long precedence, but the high schema coverage and read-only annotation make the tool sufficiently complete for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 that latitude/longitude or address can be used for location lookup, but it does not explain the filter parameters (technology, speed_upload, speed_download) beyond the schema. The schema carries the load for those.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb and resource ('Check broadband coverage at a specific location') and clearly differentiates from sibling tools like fcc_broadband_providers by emphasizing location-based coverage rather than provider-level data. It also enumerates the key return elements, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool (when needing coverage at a specific location) and specifies location input options. It does not explicitly name alternative tools or state exclusions, but the context is clear enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fdic_failuresA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide readOnlyHint=true, so the description adds meaningful context: it specifies the data scope (since 1934), key fields returned (failure date, cost, resolution type, acquiring institution), and filtering behavior. It does not describe pagination or response format, but with annotations covering safety, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences and front-loaded: the first sentence states the core purpose, the second lists return fields, and the third gives filter examples. Every sentence contributes 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 5 parameters, lack of output schema, and minimal annotations, the description covers key elements: it states the data scope, lists important return fields, and provides filter examples. It omits details like default limits or sorting options, but these are already described in the schema, so the overall context is fairly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the schema already includes concrete examples for the filters parameter (e.g., 'PSTALP:"GA"' and date ranges). The description only repeats these examples in a simplified form, adding little beyond the schema. Thus, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get FDIC-insured bank failures — all failures since 1934.' It uses a specific verb ('Get'), identifies the exact resource (FDIC-insured bank failures), and provides a scope ('all failures since 1934'), which distinguishes it from sibling tools like fdic_history or fdic_search_institutions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives implicit usage context by describing the data and filters (e.g., 'Filter by state: PSTALP:"GA", by year range'), but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No sibling tool is mentioned, so the differentiation is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fdic_summaryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile, so the description only need to add contextual behavior. It adds that the tool provides totals by state/year, but does not disclose pagination behavior, default response shape, or query limits. This is acceptable but not rich beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the primary purpose and immediately followed by intended use cases. Every word adds value, with no redundant information or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an aggregate summary tool with no output schema, the description covers the core return values (totals, deposits, assets) and dimensions (state/year, charter type). It could mention the default limit or that it returns a list of aggregate records, but the description is sufficiently complete for a straightforward summary endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with all six parameters described in the input schema. The description merely reinforces the 'state/year' dimension mentioned in the filters parameter, but adds no extra meaning beyond what the schema already provides. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'Get aggregate banking statistics' and distinguishes it from siblings like fdic_search_institutions by emphasizing aggregate totals. It also specifies the dimensions (state or charter type) and example metrics (total banks, deposits, assets), making the tool's role unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  'Useful for overview metrics' provides clear context for when to use this tool, implying it is for high-level summaries rather than detailed institutional data. It does not explicitly name alternatives or state when not to use it, but the reference to overview metrics gives adequate guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fec_committee_financialsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds useful context about required input and committee types, but it does not disclose return volume, pagination, or default cycle behavior. With annotations doing the safety lifting, a 3 is warranted.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary action, and all words earn their place. It immediately states what the tool returns and then the essential prerequisite.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only two parameters, a read-only annotation, and no output schema, the description is almost sufficient. It identifies the core purpose and prerequisite, but lacks an explicit note about what the returned 'financial totals' comprise (e.g., receipts, disbursements, cash on hand). A brief mention of output fields would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes both parameters with 100% coverage, so the description adds little beyond restating the requirement for committee_id. The reference to fec_search_committees is a helpful semantic addition, but the baseline 3 is appropriate because the schema carries the parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and identifies a clear resource ('financial totals for a committee') with the scope of committee types (PAC, campaign, party). It also distinguishes itself from the sibling search tool by stating the requirement for a committee_id and referencing fec_search_committees.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit prerequisite and points to the correct alternative for finding a committee_id ('use fec_search_committees to find one'). However, it does not directly contrast with similar financial tools like fec_candidate_financials, so it lacks a full when/when-not comparison.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fec_search_candidatesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds the fact that the data comes from the FEC and that it supports searching by the listed fields, but it does not describe pagination behavior (although per_page and page parameters exist), result ordering, or any rate limits. This adds minimal context beyond the annotations and schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one efficient sentence: it states the tool's purpose, lists the primary filter dimensions, and identifies the data source. No fluff, no repetition of schema details. It is front-loaded with the action verb 'Search' and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given this is a search tool with good schema descriptions and a readOnly annotation, the description is sufficiently complete. It covers the essential purpose and filter dimensions. It does not mention pagination defaults or output structure, but for a search tool with no output schema and clear parameters, that is a minor gap. Naming sibling alternatives (e.g., fec_search_committees) would have made it a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, as every parameter has a description in the schema. The tool description lists the search dimensions (name, state, party, office, election year) which nicely summarizes the parameters, but adds no new semantics beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Search' and specifies the resource ('federal election candidates') along with the key filter dimensions: name, state, party, office, or election year. It also provides the data provenance ('Data from the Federal Election Commission (FEC)'), which clearly distinguishes this tool from sibling tools like fec_search_committees or fec_candidate_financials.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states what the tool searches (federal election candidates) and what filters are available. It does not explicitly exclude alternatives like fec_search_committees or mention when to prefer this over fec_candidate_financials, but the context of candidate search is clear enough for an agent to differentiate. A brief note about when to use committee search would make it a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fema_disaster_declarationsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true; description adds return fields and temporal coverage without contradiction. However, it does not disclose pagination behavior or result limits beyond the schema's top/skip parameters.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, roughly 20 words, front-loaded with verb+resource. Every sentence adds value—no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema, so mentioning return fields (name, type, area, programs) helps. Parameter schema handles filter definitions. Missing explicit pagination/limits, but adequate for a straightforward search tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with individual descriptions; description only names a subset of filter fields already present in schema, adding no additional semantic depth.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Search' and resource 'FEMA disaster declarations', includes temporal scope 'since 1953', and clearly distinguishes from sibling FEMA tools like fema_housing_assistance and fema_public_assistance.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  States supported filters (state, year, incident type, declaration type) and return fields, giving clear context for when to use. Does not explicitly name alternatives or exclusions, but the context is sufficient for a search tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fema_housing_assistanceA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, so the read-only safety profile is covered. The description adds useful context by enumerating the types of data returned (approved assistance amounts, inspections, damage by county/zip), which goes beyond the annotation. It does not disclose rate limits or pagination, but that is not critical for a read-only query tool with an annotation covering safety.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the main purpose, and wastes no words. It efficiently conveys scope, audience, and data content without repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description appropriately summarizes the return content (approved amounts, inspections, damage). It covers the tool's purpose and key filters (by county/zip and disaster). It lacks guidance on pagination or relationships to other FEMA tools, but the schema covers parameters and the read-only annotation provides safety context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all 5 parameters, so the input schema already fully documents top, skip, state, county, and disaster_number. The description adds no new parameter-level semantics beyond mentioning 'disaster' and county/zip, which are already represented in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Get FEMA Individual Housing Program (IHP) assistance data for homeowners' and specifies the scope (homeowners) and key content (approved amounts, inspections, damage by county/zip for a disaster). This distinguishes it from sibling tools like fema_public_assistance, which targets a different assistance program.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for fetching homeowner housing assistance data for a disaster, but provides no explicit guidance on when to use this tool versus siblings such as fema_disaster_declarations or fema_public_assistance. It does not name alternatives or mention exclusions, so the guidance remains implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fema_public_assistanceA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation, and the description adds useful content context about the grant types and recipients. However, it does not disclose behavior such as pagination, default limits, result ordering, or the absence of filtering, which would provide additional transparency beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core action, and every word adds value. It efficiently conveys the resource, recipients, and categories without fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple parameter set and the absence of an output schema, the description adequately conveys the tool's data scope ('project-level grants') and recipient types. It does not detail return fields or query behavior, but the tool is straightforward enough that this is not a critical gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for all four parameters (top, skip, state, disaster_number), each with a clear description. The tool description does not add parameter-specific semantics beyond the schema, so the baseline of 3 applies since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('FEMA Public Assistance (PA) grant awards'). It further distinguishes this tool from sibling FEMA tools by specifying recipient types (state/local/tribal governments and nonprofits) and project categories (debris removal, emergency work, permanent repair), making its scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on what the tool is for, but does not explicitly mention alternatives or exclusions. While the recipient types and project categories imply when to use this tool (e.g., for PA grants as opposed to housing assistance), it lacks an explicit 'use X instead' statement typical of the highest score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fema_queryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations mark readOnlyHint=true, so safety is disclosed. The description adds value by noting OData $filter support and the general-purpose nature across datasets, but it does not detail pagination behavior (beyond 'top' and 'skip' in the schema), default result limits (schema says default 50), known datasets, or any service-specific quirks or rate limits. It contributes some context beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states scope and examples, the second states the key syntax feature. No wasted words; front-loaded with purpose. Every sentence serves a distinct informational purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a flexible query tool with full schema coverage and readOnlyHint annotation, the description is reasonably complete. It omits an output schema, which is absent from the structured data, but the examples and syntax note help an agent. Given that it is a generic query tool, users are expected to know OData; the description could mention that no metadata/fields list is returned, but this gap is minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 each parameter including examples. The description adds a general note about OData syntax and mentions datasets, which aligns with the schema, but it does not compensate for or add meaning beyond what the schema's per-parameter descriptions provide. Baseline 3 is appropriate because schema carries the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it is a 'General-purpose query against any OpenFEMA v2 dataset' with a specific verb 'query' and a distinct resource class. It enumerates example datasets (NFIP, hazard mitigation, mission assignments, IHP registrations) and explicitly notes OData $filter syntax, which distinguishes it from narrow, single-dataset siblings like fema_disaster_declarations or fema_public_assistance.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context: use this for OpenFEMA v2 datasets, listing representative use cases. It doesn't explicitly say 'use X instead' or 'don't use for Y', but given the sibling list includes separate fema_* tools, an agent can infer to prefer specific tools for declared datasets and use this for undiscovered or alternative datasets. This is clear context without formal exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fema_regionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation. The description adds useful context about the 10-region coverage of all U.S. states and territories, but does not mention output format or other behavioral details. With annotations covering safety, this is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the core action and resource. No waste, and every sentence provides substantive information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only static lookup, this is fairly complete. It states what the tool returns (region boundaries and states) and adds context on coverage. However, it does not disclose the output format (e.g., GeoJSON, list of states), which would be useful given there is no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics since there are none, and the input schema is fully covered.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' with a clear resource 'FEMA region boundaries and associated states'. It also notes the 10-region coverage, which helps distinguish it from sibling tools like fema_housing_assistance and fema_disaster_declarations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for retrieving FEMA region boundaries and associated states, but it does not explicitly state when to use it over alternatives or provide exclusions. Usage is inferred from the resource description rather than explicitly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fmcsa_carrier_detailA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes that this is a safe read operation; the description adds behavioral context by enumerating the kind of data returned (safety rating, inspections, crash data, etc.). It does not disclose error behavior for invalid DOT numbers, but with the annotation covering the safety profile, this is acceptable and adds value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences. The first sentence front-loads the primary purpose (get full safety profile by DOT number), and the second efficiently lists the key data categories. No filler or redundant information is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter tool with no output schema, the description is reasonably complete. It lists the major response categories (safety rating, inspection results, crash data, driver counts, operational details), which gives the agent a good sense of what to expect. It does not specify error handling or response structure, but the tool's low complexity and rich annotations partially compensate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes the only parameter (dot_number) with 'DOT number of the carrier', and the description also mentions 'by DOT number'. Since schema_description_coverage is 100%, the description adds no additional meaning beyond what the schema provides, which meets the baseline for a well-covered schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' with a clear resource: 'full safety profile for a motor carrier by DOT number'. It lists the types of information returned (safety rating, inspection results, crash data, driver counts, operational details), making the tool's purpose explicit and distinct from the sibling search tool fmcsa_carrier_search, which likely returns a list of carriers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you have a DOT number and need a detailed safety profile, but it does not explicitly state when to use this tool versus alternatives like fmcsa_carrier_search. There is no mention of prerequisites (e.g., search first) or exclusion criteria, so the guidance is only implied rather than overt.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fmcsa_carrier_searchA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds useful behavioral context by listing return fields (legal name, DBA, state, driver count, power units, safety rating) beyond the readOnlyHint annotation. It does not disclose potential limitations such as result caps or pagination, but the read-only safety profile is already established by annotations, so the added detail is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences that front-load the main action and include only necessary information: what the tool does, what it returns, and when to use it. There is no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with no output schema and read-only annotations, the description covers the essential aspects: purpose, search criteria, and return contents. It does not address edge cases like requiring at least one parameter or result limits, but these are not critical for a simple search operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (name, state, dot_number) having descriptive text. The description only restates these same search criteria without adding new meaning or clarifying constraints, so it does not elevate beyond the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches FMCSA motor carriers by company name, DOT number, or state, and returns carrier profiles. It is specific about the resource and action, but it does not explicitly distinguish itself from the sibling tool fmcsa_carrier_detail, so it misses the differentiation element for a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear use case ("Use to find trucking companies, bus companies, and other motor carriers") and lists the search criteria, giving the agent context for when to invoke it. However, it does not mention when not to use it or suggest an alternative like the detail tool, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fooddata_listA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile. The description adds that the tool is 'paged' and filterable 'by data type,' which is useful behavioral context beyond the annotation. It does not disclose return format or pagination details, but with the annotation as a baseline, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two sentences, front-loaded with the main action ('Browse a paged list of foods'), and every word adds value. It is efficient, clear, and contains no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With clear annotations, complete schema descriptions for all parameters, and a simple list-browsing purpose, the description is sufficiently complete. It could explicitly mention default pagination or sorting options, but the schema already covers these, and the tool's simplicity keeps the description adequate without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already documents all five parameters. The description only adds a general mention of filtering 'by data type,' which maps to the dataType parameter but does not provide additional meaning beyond what the schema already states. This aligns with the baseline of 3 for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Browse') and resource ('foods from the USDA database'), and clearly frames the tool as a paged listing tool. The phrase 'without a specific search term' distinguishes it from the sibling fooddata_search, making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description says it is 'useful for exploring available foods by data type without a specific search term,' which clearly indicates the best use case (browsing/exploring) and implies that fooddata_search is the alternative when a search term exists. However, it does not explicitly name the alternative tool or state 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.

• fr_presidential_documentsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds the scope of document types covered, which is useful context. It does not disclose other behavioral traits such as pagination behavior, result ordering, or any limitations, but the read-only nature is already conveyed by annotations and the verb 'Search.' No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that immediately states the action and scope. It wastes no words and provides all necessary high-level information in a compact form.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a straightforward search tool with no required parameters and a well-described schema. The description adequately conveys the core purpose and coverage, though it does not explain return value structure or pagination in the absence of an output schema. For the tool's complexity, this is sufficient but not exhaustive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so every parameter (keyword, doc_type, start_date, end_date, president, per_page) already has a descriptive definition. The description only lists document types that mirror the doc_type enum and adds no additional parameter-level meaning, hence the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Search' with the resource 'all presidential documents' and enumerates document subtypes (executive orders, memoranda, proclamations, other presidential actions). This clearly distinguishes it from sibling tools like fr_executive_orders (which targets a subset) and fr_search_rules (which targets rules).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states it searches 'all presidential documents,' giving an implicit sense of when to use it as a comprehensive search tool. However, it does not explicitly mention alternatives or when to use a more specific tool (e.g., fr_executive_orders for executive orders only), so it lacks exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ftm_contributionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds a data-source/coverage detail ('via the National Institute on Money in Politics') and the search scope, but it does not disclose return format, pagination, or any filtering limitations beyond the parameters. This matches the get_calls calibration example where annotations carry the safety burden and the description adds modest context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a two-sentence, front-loaded summary. The first sentence begins with the action verb 'Search' and a concrete resource. The second sentence adds essential coverage and provenance. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward search tool with five parameters and no output schema, the description covers purpose, scope, and data source. It does not describe the return payload shape, but the absence of an output schema and the simple query nature make this acceptable. Slightly more detail on what constitutes a 'contribution' record might help, but not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already explained (year, limit, state, donorId, candidateId). The description's phrase 'by candidate, donor, state, and year' simply mirrors the schema and adds no new semantic detail, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Search state-level campaign finance contributions by candidate, donor, state, and year.' This is a specific verb+resource combination that differentiates it from sibling FEC (federal) tools. The addition of 'Covers all 50 states via the National Institute on Money in Politics' further clarifies scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is for state-level campaign finance data, not federal. It explicitly says 'state-level' and covers 'all 50 states', which helps an agent choose this over similarly named FEC tools. However, it does not explicitly mention alternatives or exclusions (e.g., 'for federal contributions, use fec_search_candidates').

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fws_species_detailA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, and the description's 'Get detailed information' aligns with that. The description adds value by listing the included content areas (listing history, critical habitat, recovery plans, range), but does not disclose other behavioral aspects like return format or pagination. Given the annotations cover the safety profile, this is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states the core purpose, the second lists included details. It is front-loaded with the verb and resource, contains zero filler, and every word contributes to understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool with no output schema, the description covers the essential context: what the tool does, what input is needed, where the input comes from, and what information is returned. It lacks details on output structure, but given the low complexity and presence of annotations, it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter 'tsn', which already includes 'Taxonomic Serial Number from fws_species results'. The description merely repeats 'by TSN', adding no new semantic meaning beyond what the schema provides, so it meets the baseline but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Get detailed information about a listed species') and identifies the resource/input (TSN). It distinguishes this tool from its likely sibling fws_species by focusing on retrieving details for a single species rather than searching or listing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the usage context: you must have a TSN, and the parameter description further clarifies that the TSN comes from fws_species results. However, it does not explicitly name alternatives or exclusions, so it's clear but not fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hmda_filersA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already communicates that this is a safe read operation. The description adds that it returns institution names, LEIs, and filing details, but it does not discuss additional behavioral aspects such as pagination, rate limits, or data freshness. This is similar to the calibration example where annotations cover the safety profile and the description adds minimal extra context, warranting a 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loading the core purpose, then briefly noting return fields and a practical use case. Every sentence contributes value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description compensates by listing return fields (institution names, LEIs, filing details). It also provides a concrete use case. However, it does not mention potential limitations like pagination or result limits, which could be relevant for a list endpoint. This is a minor gap, so a 4 is warranted.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides a complete description of the only parameter (year: 'Filing year (e.g. 2022). Required.'), achieving 100% schema coverage. The description merely restates 'for a given year' without adding semantic depth. Per baseline rules for high schema coverage, a 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'List[s] financial institutions that filed HMDA data for a given year,' with a specific verb and resource. It also names the return fields (institution names, LEIs, filing details) and explicitly connects the tool to finding LEIs for aggregation queries, distinguishing it from other HMDA-related sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear use case: 'Use to find LEIs for filtering aggregation queries by institution.' This tells the agent when to use the tool. However, it does not mention alternatives or when not to use it, falling short of the explicit when/when-not guidance that would merit a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hmda_rate_spreadA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read/calc operation, so the description does not need to repeat that. It adds useful context about the formula and external CFPB calculator, but does not disclose additional behavioral traits such as rate limits or error handling. This is acceptable given annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the main action, and each sentence earns its place: the first states what it does, the second adds the formula and usage context. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool is a straightforward calculator with all parameters documented in the schema, the description is mostly complete. It defines the calculation and its purpose, though it does not state the return format, which an agent might infer. Still, for a simple calculation tool, this is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptive details, so the baseline is 3. The description adds only the conceptual formula (APR vs APOR) but does not elaborate on individual parameter formats or constraints beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool calculates the rate spread for a mortgage loan, names the specific CFPB calculator, and provides the formula (APR minus APOR). It distinguishes itself from sibling HMDA tools like hmda_validate_uli and hmda_check_digit by focusing solely on rate spread calculation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides context for when to use the tool ('Used for HMDA reporting and fair lending analysis'), indicating relevant use cases. It does not explicitly exclude alternatives or mention other tools, but the purpose is specific enough that the usage is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hud_fair_market_rentsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description's 'Get' is consistent. It adds useful context about the output (efficiency through 4-bedroom) and the tool's purpose (FMR determines Section 8 amounts), exceeding the minimum for a read-only tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences, each earning its place: action and scope, output shape, and policy context. No redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with no output schema, the description conveys core functionality and output (rent by bedroom count). It relies on the schema for parameter details, which is acceptable given 100% coverage. It does not mention when to use it vs. related tools, but that is covered under usage guidelines.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with parameter descriptions. The description gives a high-level overview of location scoping (county/metro/state) but does not add significant new meaning beyond the schema's parameter descriptions. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the verb 'Get' and resource 'HUD Fair Market Rents' with scoping options (county, metro area, or state). It specifies the output (monthly rent by bedroom count), but does not explicitly distinguish from related tools like hud_income_limits or hud_list_states.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context on what locations are supported (county, metro, state) and notes the policy relevance (Section 8 voucher amounts). Does not explicitly state when to use this tool over alternatives, but the scoping guidance is clear enough for an agent to select it for FMR queries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hud_income_limitsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, which covers the safety profile. The description adds that the tool returns income thresholds by household size, which is useful but does not disclose other behaviors such as return format, whether multiple results can be returned, or any pagination. With annotations covering the basic safety, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: two sentences that front-load the main purpose, then detail the data returned and use case. Every sentence earns its place without redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (3 optional parameters, read-only, no output schema), the description is nearly complete: it specifies the output content and geographic scope. It does not mention sibling resources like hud_list_counties for obtaining entity_id, but the schema already references hud_list_counties in the entity_id description. The description is sufficient for a straightforward lookup tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters (year, state, entity_id) are already well-documented. The description adds contextual meaning by tying the scope to 'county, metro area, or entire state,' which maps to entity_id and state, but it does not introduce new parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves HUD Income Limits with a specific verb ('Get') and resource. It further specifies the geographic scope (county, metro area, or entire state), the income threshold categories (Very Low, Extremely Low, Low), and household sizes (1-8 persons), which distinguishes it from siblings like hud_fair_market_rents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool ('Used for affordable housing eligibility') and implies the scope (county/metro/state). However, it does not explicitly mention alternatives or when not to use it (e.g., when fair market rents are needed), so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ita_tariff_ratesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, which the description does not contradict. The description adds value by specifying the type of data returned (tariff lines, rates, base rates, final year, rule text), which is helpful but not behavioral context like pagination, default limits, or authentication. With annotations already covering the safety profile, the description provides some additional context but not extensive behavioral detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loads the main verb and resource, and every word adds functional value. It avoids 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 4 optional parameters, 100% schema description coverage, and no output schema, the description explains the purpose and return result categories. It does not specify pagination, result count defaults, or response format, but the schema covers parameters and the description covers the core usage. It is complete for a search tool with good schema support.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter having a clear description. The tool description itself does not add parameter-level detail beyond mentioning the search dimensions. Since the schema covers parameters thoroughly, the baseline score of 3 is appropriate. The description does not compensate with additional examples or parameter relationships, but it is not necessary.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Search' and clearly identifies the resource: Free Trade Agreement (FTA) tariff rates. It lists the key search dimensions (HTS code, partner country, keyword) and the types of results returned (tariff lines, rates, base rates, final year, rule text). This clearly distinguishes it from sibling trade-related tools like ita_trade_events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states that the tool searches FTA tariff rates, implying use when the agent needs FTA tariff information. It does not explicitly provide when-not-to-use or alternatives, but the scope is clear enough to differentiate from other trade tools. The context signals show no exclusions or alternative guidance, so it is slightly above baseline but lacks explicit alternative references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jpl_fireballA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations include readOnlyHint=true, so the read-only nature is already declared. The description adds useful context about the data source (DoD/DoE satellite sensors) and included fields (date, location, velocity, energy, altitude), but does not disclose rate limits, pagination, or response format. This is adequate given the annotations, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences plus an example, front-loaded with the main purpose. Every sentence adds value: purpose, definition, data fields, and usage example. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with three optional parameters and no output schema, the description covers the key aspects: what it returns (fields listed), how to use it (example), and its source. It could mention pagination or behavior with no date range, but the schema and annotations already handle defaults and safety. Adequate for the complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% description coverage for all three parameters, including formats and the limit default. The description's example (date_min='2024-01-01', date_max='2024-12-31') marginally reinforces usage but does not add significant meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Get reported fireball/bolide events from US Government sensors' with a specific verb and resource, and adds clarifying context about what fireballs are. This clearly distinguishes it from sibling tools like jpl_close_approaches, which focus on near-Earth objects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use the tool (to retrieve fireball events) and provides a concrete example with date parameters, but it does not explicitly mention alternatives or when not to use it. The context is clear, but exclusions are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• la_metro_stopsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a read-only operation. The description adds context about return fields (IDs, names, coordinates) and the optional filter, which is useful. However, it does not disclose behavior when no route is provided (e.g., returns all stops), pagination, or rate limits. With annotations covering safety, a score of 3 reflects the added but limited transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, starts with the verb 'List', and contains no filler. Every word adds value: the resource, the system, the returned fields, and the optional filter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a low-complexity tool with one optional parameter and no output schema. The description covers the essential details: what it lists, what it returns, and the optional filter. It could clarify what happens without a route code, but the optional parameter implies all stops. This is adequate for the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the parameter, including a description with an example ('720' for Wilshire Rapid). The tool description adds 'Optionally filter' indicating the parameter is optional, which aligns with the schema (not required). Since the schema already provides detailed semantics, the description adds little beyond the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'List stops for an LA Metro (Los Angeles) route.' It specifies the resource (stops), the scope (LA Metro), and the output (stop IDs, names, coordinates). This distinguishes it from sibling tools like la_metro_routes (which lists routes) and la_metro_vehicles (which lists vehicles).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this to list stops for a route, optionally filtered by route code. However, it does not explicitly mention alternatives or when not to use this tool (e.g., 'use la_metro_routes to get route lists'). No exclusions are stated, but the purpose is specific enough to infer usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lobbying_searchA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds useful behavioral context by stating it returns expenses/income, issues lobbied, and registrant/client info, but it does not disclose pagination behavior or other operational details beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear lead sentence, a bulleted list of search parameters, and a concise return statement. Every line adds value, and it is neither verbose nor under-specified.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 6 parameters and no output schema, the description covers the core purpose, search dimensions, and return values. However, it omits filing_type and page_size from the 'Search by' list, which could lead an agent to overlook these filters. This is a minor completeness gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed descriptions and enums for all parameters. The description repeats some parameter examples (e.g., 'Pfizer', 'Google', 'TAX') but adds minimal new 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Search lobbying disclosure filings.' It clearly states the purpose (find who is lobbying Congress, on what issues, and how much they're spending) and distinguishes this search tool from sibling tools like lobbying_detail and lobbying_contributions by focusing on filing searches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by enumerating search dimensions (registrant, client, issue, year) and return types. However, it does not explicitly mention when to use this tool over alternatives like lobbying_detail for specific filing details, so it stops short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• loc_newspaper_searchA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already signals the safe read-only nature. The description adds that it searches OCR text from digitized pages, which is mildly informative, but it does not disclose other behaviors such as pagination limits, result format, or any specific usage constraints beyond what the schema documents.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences that front-load the core purpose and provide the key scope. Every word is informative, with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only search tool with a fully described schema, the description adequately covers the high-level purpose, resource, and scope. The state/date filters are documented in the schema, so the description doesn't need to repeat them. Slight deduction because it doesn't note that results will be pages or hits, but that is implied by 'search of newspaper pages'.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% description coverage for all 6 parameters, including text, state, date_from, date_to, page, and rows. The description does not add additional meaning beyond the schema; it mentions the historical date range but that is a resource scope, not parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action: full-text search of historical U.S. newspaper pages, with the scope (Chronicling America, 1777–1963) and the nature (OCR text). This clearly distinguishes it from sibling tools like loc_newspaper_titles (which searches titles) or loc_search (general LOC search).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: when searching the text of historical U.S. newspapers. It gives the date range and the fact that it searches OCR text. However, it does not explicitly state when not to use it or name alternative tools for other types of searches, so a small gap remains.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mbta_routesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safe read-only behavior is known. The description adds no further behavioral context such as response format, pagination, or rate limits, but it does not contradict annotations. Given the simple read-only nature, this is 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, using two sentences to convey the core action and optional filtering. It is front-loaded with the main purpose and every part adds value without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple filtered-list tool with full schema coverage and a readOnlyHint annotation, the description provides enough context to use it correctly. It does not specify return fields or pagination behavior, but the schema covers the limit parameter, and the tool's purpose is straightforward.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, meaning the schema already documents both 'type' and 'limit' parameters. The description repeats the type mapping already present in the schema and adds no new semantic information beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' with a clearly defined resource 'MBTA (Boston) transit routes' and mentions optional type filtering. It distinguishes the tool from sibling tools like mbta_predictions and mbta_alerts by explicitly focusing on routes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates this tool is for listing MBTA routes and supports filtering by route type, providing clear usage context. However, it does not explicitly mention alternative tools for related data (like predictions or alerts) or state when not to use this tool, so it misses explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mbta_vehiclesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds value by naming the returned fields (GPS coordinates, speed, bearing, current status) and noting it covers active vehicles. It does not disclose additional limitations like data freshness or pagination, but these are not critical for this simple tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two focused sentences, front-loaded with the main action, no fluff. Every word earns its place, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with only two optional parameters and no output schema, the description covers the essentials: what it returns, which transit system, and the filtering option. It could mention alternatives or response format, but the description is adequate for its simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for both parameters (limit and route), including examples and a default. The description's 'Optionally filter by route' adds no new information beyond the schema, so it does little to enhance parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets live vehicle positions for MBTA (Boston), with specific data fields (GPS coordinates, speed, bearing, current status). This distinguishes it from sibling tools like mbta_routes, mbta_alerts, and mbta_predictions, as well as other agencies' vehicle tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description indicates the tool is for live vehicle positions and mentions optional filtering by route, providing clear user context. However, it does not explicitly mention when not to use it or alternatives such as mbta_predictions for arrival times, so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_traffic_incidentsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description adds context beyond that: 'real-time', 'updates continuously', and the CHART (MDOT SHA) data source. However, it does not disclose output format, pagination, or latency, which would have been useful, but is not critical for a no-parameter live feed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences: core purpose first, then examples of included events, then data source and update frequency. Every sentence adds value with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, read-only tool, the description covers what it returns (active incidents), the types included, and the source. It lacks a detailed response structure, but without an output schema, the description is sufficiently complete for an agent to invoke the tool and interpret results at a basic level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema confirms this with 100% coverage (empty properties object). Since there is nothing to document, the baseline of 4 applies; the description offers no parameter explanation but none is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get active traffic incidents on Maryland highways in real-time' with a specific verb and resource. It enumerates incident types (accidents, disabled vehicles, debris, construction) which distinguishes it from sibling tools like md_traffic_closures or md_traffic_speeds.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when needing incident data, but does not explicitly mention alternatives or when to prefer this over related Maryland traffic tools. There is no direct comparison or exclusion guidance, though the scope is clear enough for basic inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_transit_vehiclesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, so the description only needs to add context. It discloses the API key requirement and the list of agencies, which is useful. However, it does not mention response format, data freshness, error behavior, or rate limits, leaving some behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise lines, front-loaded with the main action, and includes the key requirement and agency mapping. Every sentence earns its place; no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only tool, the description covers the essential aspects: what it does, the required environment variable, and the accepted agency values. Since there is no output schema, a brief note on the expected response structure would have made it complete, but it is already quite usable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 mapping each enum value to its human-readable agency name (e.g., 'mta-maryland' = Local Bus), which helps agents select the correct parameter. This goes beyond the schema's 'Swiftly agency key'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get real-time vehicle positions' with a clear resource 'Maryland MTA transit'. It lists the four agency keys with human-readable labels, which makes the tool's scope unmistakable and distinguishes it from other transit tools like md_transit_trip_updates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the primary use case (retrieving vehicle positions) and notes the required API key, but it does not explicitly contrast this tool with siblings like md_transit_feeds or md_transit_trip_updates, nor does it state when not to use it. Usage is reasonably clear but lacks explicit alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• naep_available_variablesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the tool's safety profile is known. The description adds that it returns variable names, short labels, and long labels, which is useful. However, it does not mention pagination, ordering, or any potential limitations, so it only adds marginal context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each serving a clear purpose: stating what it does, when to use it, and what it returns. There is no redundant or filler content, making it efficient and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a relatively simple discovery tool, the description is adequately complete. It covers the tool's purpose, usage context, and output structure. The full parameter schema and readOnly annotation fill in remaining details, so the agent has enough context to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all three parameters (subject, cohort, years), and the description does not add additional semantics beyond the schema. It refers to the parameters generically ('subject, cohort, and year') without providing extra format or constraint details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists available independent variables for a NAEP subject, cohort, and year, which is a specific verb+resource combination. It also distinguishes itself from siblings like naep_scores by noting it is for discovering variables before querying scores.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use this to discover what demographic/survey variables are available before querying scores,' which provides clear usage context. It does not explicitly list alternatives or exclusion cases, but the instruction is direct and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nara_searchA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include readOnlyHint=true, so the description appropriately adds context beyond that by mentioning the rate limit (10,000 queries/month) and what the return includes (record metadata, titles, descriptions, dates, links). This is useful behavioral context without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each earning its place: purpose, return value, and a critical constraint (rate limit). It is front-loaded with the primary verb and resource, and contains no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool without an output schema, the description covers what the tool does, what it returns, and a practical limitation. It doesn't mention pagination details, but the schema documents offset/limit, so the description is adequately complete. The sibling nara_record is not referenced, but isn't required.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters query, limit, and offset are already documented. The description adds no additional meaning beyond what the schema provides, earning the baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Search') and resource ('National Archives catalog'), and lists the types of content (historical records, documents, photographs, government publications). It distinguishes itself from the sibling tool nara_record by describing a search operation rather than a record detail lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for searching the catalog and notes a rate limit, but it does not explicitly state when to use this tool versus alternatives like nara_record, nor does it mention exclusions or prerequisites. The context is clear but relies on inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nasa_image_captionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe, non-destructive operation, and the description adds that the output is a URL to an SRT file. However, it does not disclose details such as availability of captions for all videos, possible error cases, or whether the URL is directly usable without additional authentication, which would enhance transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that is front-loaded with the primary action and outcome. It contains no filler, no repetition of the tool name, and every word contributes to the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one required parameter and no output schema, the description sufficiently conveys the input, the action, and the output (a URL). It is slightly sparse on context like how to obtain the NASA ID or when captions might be unavailable, but given the tool's simplicity, the description is complete enough for accurate invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter 'nasa_id' has a complete schema description ('NASA video ID'), achieving 100% schema coverage. The tool's description adds no additional semantic detail beyond what the schema already provides, so it meets the baseline without needing to compensate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('Get the URL') and its specific resource ('SRT subtitle/captions file for a NASA video asset'), which is distinct from the sibling NASA image tools that focus on assets or metadata. It leaves no ambiguity about what this tool does or the kind of item it targets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly communicates when to use it: when a caption/subtitle file URL for a NASA video is needed. It does not explicitly name alternatives or exclusion criteria, but the narrow purpose and presence of a dedicated NASA ID parameter provide clear context for the intended use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nasa_image_searchA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, which already signals a safe read operation. The description adds context about the scope (image, video, audio) and available filters but does not disclose additional behavioral traits such as pagination limits, response shape (e.g., metadata only vs. direct files), or whether any parameters are mutually exclusive. With annotations covering safety, this meets the baseline but adds limited extra value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary action and resource. Each sentence contributes: the first states the core purpose, the second enumerates filter capabilities. No filler or redundant phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with 13 parameters and no output schema, the description gives a useful overview of capabilities and filter categories. It does not explain response format or pagination behavior, but the readOnlyHint and the schema (which fully documents each parameter) reduce the need for that detail. The description is sufficient for an agent to select the tool for a broad media search, though it could mention that it returns search results rather than actual media assets.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, so the baseline is 3. The description adds a light summary of parameter families (keyword, center, media type, year range) but does not provide deeper semantics beyond what the schema already documents. It repeats examples like center codes already present in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('Search'), a resource ('NASA's image, video, and audio library'), and a scope (filterable by keyword, center, media type, year range). This distinguishes it from sibling tools like nasa_image_asset or nasa_image_metadata, which imply retrieval of specific assets rather than general searching.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: when searching NASA media. It lists the main filter dimensions, giving the agent an idea of the types of queries it can serve. However, it does not explicitly name alternative tools or exclude cases (e.g., 'use nasa_image_asset to fetch the actual image file'), so it falls short of a perfect score for explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nasa_mars_photosA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With the readOnlyHint annotation already indicating a safe read operation, the description adds useful domain context by enumerating valid rovers (curiosity, opportunity, spirit) and camera examples. However, it does not disclose the response format, pagination, or any limitations such as rate limits. It goes slightly beyond the annotation but lacks rich behavioral detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and efficient: a single purpose sentence followed by two short enumerations. It is front-loaded with the main action ('Get Mars Rover photos') and provides necessary enumeration without fluff. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, the description covers the essential purpose and parameter options. The absence of an output schema means it could have described what the response contains (e.g., photo URLs), but the phrase 'Get photos' implies it returns photos. With complete schema coverage and readOnlyHint, it is sufficiently complete for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already has 100% coverage with descriptions for all four parameters. The description repeats some of this information (e.g., sol meaning 'Mars day' and the list of cameras) but adds no new meaning beyond the schema. The only slight addition is the phrase 'use sol OR earth_date' implied in the first sentence, though the schema also states this.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get Mars Rover photos by sol (Mars day) or Earth date.' It specifies the exact resource (Mars Rover photos) and the filtering dimensions (sol/date), with a specific verb ('Get'). It also lists the relevant rovers and cameras, distinguishing it from other NASA tools like nasa_image_search or nasa_neo.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool: whenever Mars Rover photos are needed by sol or Earth date. It does not explicitly name alternative tools or exclusions, but the purpose is so specific that an agent can infer when to use it. The inclusion of available rovers and cameras implicitly defines the scope of use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nasa_neo_detailA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, so the safe read-only nature is already declared. The description adds no extra behavioral context beyond what annotations provide, such as return format, request limitations, or whether all details are included. It aligns with annotations, but adds minimal value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, clear sentence that fully conveys the tool's purpose without unnecessary words. Exceptionally concise while still specific.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple single-parameter input, high schema coverage, and readOnly hint, the description is sufficient for an agent to select and invoke the tool correctly. It doesn't explain the structure of the returned detail, but no output schema exists, and this is a straightforward detail retrieval.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of the only parameter with a description ('NEO asteroid ID from nasa_neo results'). The tool description adds no additional meaning beyond what is already in the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Get detailed information' and identifies the resource as 'a specific Near-Earth Object by asteroid ID'. This clearly distinguishes from sibling tools like nasa_neo which lists objects, and jpl_small_body which also provides details but by different parameters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Implies usage when an asteroid ID is available, especially referencing 'from nasa_neo results' in the parameter schema. However, it doesn't explicitly mention when to use this instead of similar detail tools like jpl_small_body, nor exclude alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhtsa_decode_vinA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so safety profile is known. The description adds return field details but does not mention potential errors, invalid VIN handling, or output format. This is adequate given the read-only annotation, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise, front-loaded sentences cover purpose, outputs, and input constraint with no wasted words. Each sentence adds distinct value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter tool with no output schema, the description lists the primary return fields and input length. It lacks detail on response structure or failure modes, but those are not critical for a straightforward decoder.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the 'vin' parameter with type, length constraints, and description. The description's 'VINs are 17 characters' is redundant with the schema. No additional parameter semantics are provided beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('Decode') and resource ('Vehicle Identification Number'), and lists expected output fields (make, model, year, engine, etc.). This distinguishes it from sibling NHTSA tools like recalls or complaints.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies clear usage context: when you have a VIN and want vehicle specifications. However, it does not explicitly mention alternatives or when not to use this tool, though the 'decode' purpose makes the use case evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhtsa_makesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds the filtering behavior (makes with recalls/complaints) but does not disclose return format or edge cases. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short lines: purpose, parameter clarification, and an example. No wasted words, front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read-only tool with clear annotations, the description is adequate. It lacks explicit return structure, but the name and purpose imply a list of makes, which is sufficient for this simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% – both parameters have descriptions. The description reiterates the issue_type values ('r' for recalls, 'c' for complaints) and provides an example, but this adds only marginal illustrative value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'List vehicle makes for a model year that have recalls or complaints,' specifying the action (list) and resource (vehicle makes) with a precise scope (model year and issue type). This distinguishes it from siblings like nhtsa_models and nhtsa_model_years.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use the tool: when you need makes for a given model year filtered by recalls or complaints. The example illustrates usage, though it does not explicitly mention alternatives or exclusions. This is sufficient for a simple list tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhtsa_modelsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already signals a safe read operation, so the description doesn't need to state that. The description does clarify that omitting issue_type changes the data source (vPIC database) and that issue_type='r' returns models with recalls, adding useful context beyond the schema. However, it doesn't disclose pagination, response structure, or any 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences plus an example, with no filler. It front-loads the primary use case, then clarifies the alternative mode, and includes a concrete example. Every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 3 parameters, no output schema, and a readOnlyHint annotation, the description is quite complete. It covers both modes of operation, uses an example, and clarifies the issue_type semantics. Minor gap: it doesn't explain what fields the returned model list contains or how results are ordered/sorted, but this is not critical for a list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all three parameters with descriptions (100% coverage), so the description's example adds marginal value. It reinforces that issue_type is optional and model_year is optional, but the schema already conveys this. The description's example is helpful but not critical beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists vehicle models for a make and year, with an optional issue_type filter for recalls or complaints, and a fallback to list all models from the vPIC database when issue_type is omitted. The verb 'List' and specific resources ('vehicle models', 'make', 'year', 'recalls/complaints') make the purpose unambiguous and distinct from siblings like nhtsa_makes and nhtsa_model_years.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example and explains when to use the issue_type parameter, implying that it is used for recalls/complaints vs. general model lookup. However, it does not explicitly state when to prefer this over sibling tools like nhtsa_recalls or nhtsa_complaints, nor does it mention any alternatives for broader queries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nih_projects_by_agencyA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so the safety profile is covered. The description adds context that the results show which institutes fund the most research, giving meaning to the counts. However, it does not disclose any other behavior (e.g., defaults for agencies, pagination, or performance), though the schema covers the agencies default. It adds some value 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences, front-loaded with the main action, then benefits and use case. No filler or redundancy. Each sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only count aggregation tool, the description covers the core purpose, output type (counts), and context. The schema covers required fiscal_year and optional agencies. It doesn't explain return format or finer details, but that's acceptable given no output schema and modest complexity. Missing a bit on how counts are organized (per agency), but 'by institute/center' covers that.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 fiscal_year and agencies (including the default 'top 25'). The description's mention of 'fiscal year' does not add new meaning beyond the schema. It gives examples of institutes but not param-specific guidance. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get project counts by NIH institute/center for a fiscal year.' It clearly distinguishes its aggregated-count purpose from sibling tools like 'nih_search_projects' (search projects) and 'nih_spending_by_category' (spending categories). It adds examples of agency codes to clarify output.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description includes an explicit use case: 'Useful for understanding NIH budget allocation across disease areas.' This implies when to use the tool, but it doesn't mention alternatives or exclusions (e.g., when you need project-level detail). Clear context but no direct comparison to siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nih_search_projectsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the description correctly doesn't need to restate that. It adds return field details, which is useful but not a behavioral trait. There is no disclosure of pagination behavior, data freshness, or rate limits. Given the read-only annotation, the description adds some value but lacks deep behavioral context, matching the baseline 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two tight sentences: the first states the search dimensions, the second states return fields and use cases. Every clause adds value with no filler. It is well-front-loaded with the primary purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 17 parameters and no output schema, the description provides a strong overview including filter dimensions, return fields, and use cases. The schema handles the detailed parameter semantics. It could mention pagination or data source, but the existing context is sufficient for an agent to understand the tool's role.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 repeats high-level filter categories (e.g., 'disease area' maps to spending_categories, 'investigator' to pi_name) but does not add new meaning beyond what the schema already provides. It groups concepts usefully but doesn't compensate for any schema gaps since there are none.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Search' with a clear resource: 'NIH-funded research projects'. It enumerates the many filter dimensions (text, disease area, investigator, institution, state, agency, spending category, grant type, funding amount) and explicitly contrasts with siblings by focusing on projects rather than publications. It also names the return fields, making the tool's function unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear use cases: 'find research grants for any disease, track institutional funding, or identify PIs.' This gives an agent strong context for when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, which would merit a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• noaa_climate_dataA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description's 'Get' aligns with this read-only nature. The description adds no behavioral context beyond the annotation (e.g., no mention of pagination, response size, API rate limits, or how to handle errors). The bar is lower with annotations, but there's still no extra transparency provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two sentences: the first states what the tool does, and the second lists required and optional inputs. It is concise, front-loaded, and contains no unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 7 parameters and no output schema, the description covers the essential usage pattern (required inputs and common filters). However, it does not mention how to discover valid dataset IDs (which noaa_datasets provides) or what the return structure looks like. A brief note on finding datasets or expected output format would make it more complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all 7 parameters, so the schema already explains dataset_id, start_date, end_date, station_id, etc. The description's mention of 'dataset ID + date range' and 'filter by station or location' reinforces required vs optional parameters but adds no new semantic detail beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description specifies the exact action ('Get climate observations') and the resource ('from NOAA'), with concrete data types (temperature, precipitation, snow, wind). It clearly distinguishes this tool from sibling tools like noaa_datasets and noaa_stations, which are metadata-focused, by focusing on the observation data itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states the required inputs (dataset ID + date range) and optional filters (station or location), providing clear context for when to use this tool. However, it does not explicitly direct users to related tools like noaa_datasets for finding dataset IDs or noaa_stations for finding station IDs, which would be a stronger exclusionary guide.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nps_alertsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so no safety warning is needed. The description adds the 'current' temporal scope and alert categories, which is useful. However, it doesn't describe the return format or any limitations beyond what the schema already provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the main verb and resource, and includes a brief usage note without excess. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with fully described parameters, the description covers the essential purpose and use case. It could mention that results are returned as a list, but the schema and name make this reasonably clear, so the gap is minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover both parameters fully (limit default, park_code examples). The description reinforces the park_code filter but adds no new semantics beyond the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves current park alerts and enumerates alert categories (closures, dangers, cautions, general information). It differentiates from sibling NPS tools by focusing on alerts rather than parks, campgrounds, or events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides a clear use case ('checking conditions before visiting') and explicitly mentions optional park code filtering, which signals when to use park_code. It doesn't explicitly exclude alternatives, but the purpose is distinct enough from sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nrel_solarA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description's burden is lower. It adds context about the data content (monthly/annual irradiance) and the output's interpretive value (solar panel potential), but does not disclose specifics like return format, units, or error handling. This is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the main verb and resource, and the second sentence adds a practical use-case without redundancy. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (2 params, no output schema), the description conveys the essential purpose, data type, and a real-world application. It lacks details on return structure or units, but these are not critical for this straightforward read-only lookup tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully covers both parameters (lat and lon) with descriptions, so the baseline is 3. The description does not add parameter-specific detail beyond what the schema provides. It reinforces the geographic scope (U.S. location) but does not specify formats or bounds.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: getting solar energy resource data (monthly and annual solar irradiance) for any U.S. location. It also adds a use-case ('Shows potential for solar panels'), which further clarifies intent and distinguishes it from sibling NREL tools like fuel stations or utility rates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 solar resource/irradiance data for a U.S. location is needed, with a practical application (solar panel potential). However, it does not explicitly mention alternatives or exclusions, though the context is clear enough for an agent to select it over other tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nvd_cve_detailA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotation, the description discloses return content (CVSS scores, attack vectors, CPE, CWE, references), adding behavioral context about what the tool provides. Does not contradict annotations, though it omits potential rate limits or errors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, no filler, and each sentence contributes meaning. The description front-loads the action and efficiently lists the key return fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter detail endpoint with no output schema, the description sufficiently covers the purpose and return values. Missing the response format is a minor gap, but the listed content details make it largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with a clear example for cveId. The description does not add extra parameter semantics, but the schema already documents the parameter adequately, meeting the baseline for full coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('Get full details') and resource ('CVE vulnerability') identified by a CVE ID. It distinguishes itself from the sibling nvd_cve_search by emphasizing 'full details' rather than search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a CVE ID is already known ('by its CVE ID'), but it does not explicitly mention alternatives (e.g., nvd_cve_search for finding CVEs) or when not to use this tool. The context is clear but exclusions are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nws_alert_detailA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already establishes this is a safe read operation. The description adds useful return-content context (complete description, instruction text, affected areas, timing) but discloses no additional behavioral traits such as pagination, response size, or rate limits. With annotations covering safety, this 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the tool's purpose, and every word adds value. It avoids fluff and redundant phrasing, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool with no output schema, the description adequately explains what the tool does and what the response contains. It lacks minor context like explicit statement that it returns a single alert object, but the overall guidance is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single parameter alert_id is already well-described with an example URN. The description reinforces that the ID identifies a specific alert but does not add significant new meaning beyond what the schema provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get full details for a specific weather alert by ID.' It uses a specific verb, identifies the resource (weather alert), and explicitly distinguishes this detail action from list/search siblings by requiring an ID. It also enumerates the kind of information returned.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the tool to use when you already have an alert ID and want complete details. It provides clear context but does not explicitly exclude alternative tools or name them (e.g., nws_alerts_active for listing alerts), so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nws_glossaryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, and the description adds no contradictory information. It adds context that the glossary covers 'terms and abbreviations,' but it does not disclose output structure, size, or whether it is searchable—though for a zero-parameter tool the behavior is fairly self-evident. With annotations covering the safety profile, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one sentence, front-loaded with action and object, with no filler. Every word earns its place, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, read-only annotation, glossary return), the description is complete enough for an agent to understand what it returns. It could mention that it returns the full glossary or a list, but that is implied by 'Get glossary.' Overall, sufficient for the low complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Since the input schema has zero properties, schema coverage is trivially 100%, and the baseline is 4. The description adds no parameter details, but none are needed. This is appropriate for a parameterless tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the verb 'Get' and specifies the resource 'NWS weather glossary' with the clarifying detail 'definitions of weather terms and abbreviations.' This clearly distinguishes it from sibling NWS tools like nws_forecast or nws_alerts_active. It meets the 'specific verb+resource' criterion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its use case—looking up definitions of weather terms—but provides no explicit 'when to use' guidance or alternative comparisons. It doesn't mention when not to use it or suggest other tools for related needs, so usage context is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nws_stationsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile, so the description only needs to add behavioral context. It adds the search-mode distinction and the downstream use of station IDs, but it does not disclose behaviors like default limits, what happens when no parameters are provided, or output structure. This is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences, front-loaded with the primary purpose. Every sentence adds value: the main action, the two search modes, and the downstream use of station IDs. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, read-only lookup tool with fully documented parameters, the description is largely complete. It covers the main purpose, search modes, and relationship to observation tools. It could mention default limit or no-parameter behavior, but these are minor gaps given the schema already provides parameter detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema carries the parameter documentation burden. The description adds a small amount of meaning by framing state and lat/lon as alternative search modes, but it does not elaborate on the limit parameter or provide syntax details beyond what the schema already offers.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool finds weather observation stations, which is a specific verb+resource pair. It also distinguishes itself from siblings like nws_radar_stations by explicitly using 'weather observation' and by noting station IDs feed into observation tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage context: search by state code or by latitude/longitude for nearby stations. It does not explicitly exclude alternatives or name sibling tools, but it conveys when this tool is appropriate and how its output can be used downstream.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• oba_routesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds that it returns route names, types, and descriptions, which is useful output context. However, it doesn't disclose potential edge cases (e.g., invalid agency_id behavior or pagination), though the bar is lower given the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loading the main purpose and then adding the default agency and return contents. Every sentence delivers useful information without redundancy or verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one optional parameter, the description covers the essential elements: what it does, the default agency, and the return fields. Since there is no output schema, this return information is critical and is provided. A 5 would require more detail about pagination or error handling, but those aren't critical for this tool's basic use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides a full description for the single parameter (agency_id) with the default value and King County Metro mapping. The description adds 'Seattle' as clarification but essentially duplicates the schema. With 100% schema coverage, the baseline is 3, and the description doesn't significantly elevate it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function ('List transit routes') with a specific geographic scope ('Puget Sound agency'), and distinguishes it from sibling tools by noting the default agency (King County Metro Seattle). It also mentions the output contents (route names, types, descriptions), making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this tool to list routes for Puget Sound transit agencies, with King County Metro as the default. It doesn't explicitly mention alternatives or when not to use it, but the regional qualifier effectively differentiates it from other transit route tools like la_metro_routes or mbta_routes.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• open_payments_by_specialtyA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, so the agent knows it's a safe read. The description adds that it provides national totals and averages rather than individual records, which is useful behavioral context, but it does not disclose return format or how the limit parameter affects results.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, fully front-loaded with the core action. The second sentence adds a concrete example of the output's value. No filler or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one optional parameter, read-only annotations, and no output schema, the description gives a clear picture of purpose and output substance (totals, averages, top specialties). It could be slightly more explicit about the shape of returned data, but for the tool's simplicity, it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the only parameter (limit) already has a clear description in the schema: 'Number of specialties (default 30)'. The tool description adds no additional parameter semantics, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action: 'Get national payment totals and averages by medical specialty.' It names the resource (Open Payments data by specialty) and includes examples of specialties, distinguishing it from sibling tools like open_payments_by_physician or open_payments_by_company.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when the user needs national-level specialty aggregates, especially ranking of specialties by pharma payments. It does not explicitly state when not to use it or name alternatives, but the context is clear enough to guide selection among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• open_payments_ownershipA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation already declares readOnlyHint=true, so the description does not need to cover safety. It adds qualitative context about the nature of ownership data ('deepest form of conflict of interest') but does not disclose additional behavioral traits such as result format, pagination, or filtering behavior beyond what the schema descriptions provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: two to three sentences that immediately state the tool's purpose, domain, and significance. Every sentence adds value and there is no redundant phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given five optional parameters, full schema coverage, and a readOnly annotation, the description provides sufficient high-level context for an agent to understand the tool's focus. It does not describe the return shape, but the absence of an output schema is partially mitigated by the tool's apparent simplicity and the parameters' clear descriptions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and all five parameters already have clear descriptions in the schema. The description adds contextual framing (doctor/company relationship) but does not add new meaning about parameter syntax or semantics beyond what is already documented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Search') and identifies a distinct resource ('Open Payments OWNERSHIP data') with a clear subject ('doctors with ownership or investment stakes in pharma/device companies'). It clearly differentiates from sibling tools like open_payments_by_physician by focusing specifically on ownership interests.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when investigating physician ownership stakes, calling it 'the deepest form of conflict of interest.' However, it does not explicitly mention when not to use it or name alternative sibling tools, so it falls short of full explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• open_payments_summaryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation covers the safety profile, and the description adds useful context about the national scope and all-years aggregation. However, it does not disclose other behavioral traits such as the data source, years available, or any limitations. The bar is lower due to the annotation, but more detail could 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose and followed by a plain-language elaboration. Every word earns its place, with no unnecessary detail or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only summary tool, the description is largely complete: it states what the tool does and what it returns (totals and averages across all years). It could mention the dataset timeframe or that it is a national aggregation, but given the tool's simplicity and annotations, it is sufficiently contextual.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters, the schema already fully covers parameter semantics (baseline 4). The description adds meaning by explaining the output scope, which is appropriate even though no parameters exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Get') and resource ('national-level Open Payment totals and averages across all years'), clearly distinguishing it from sibling tools like open_payments_by_physician or open_payments_by_company. The second sentence adds a concise explanation of the real-world meaning ('how much money flows from pharma to doctors nationally').

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by highlighting 'national-level' and 'across all years', but it does not explicitly state when to use this tool versus alternatives (e.g., open_payments_by_physician for physician-level data). There are no direct exclusions or alternative names given, so the guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opm_status_historyA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful context about the data content (closures, delays, early departures) and pagination behavior (max 5000 per request). No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the main purpose, no redundancy or unnecessary details. Every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with only two parameters and no output schema, the description provides sufficient information about what the tool does and its pagination. It could mention default behavior or date range, but is generally complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 mentions startrow and count for pagination, but this largely repeats schema descriptions rather than adding new meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it gets historical federal government operating status records, with specific verb 'Get' and resource. It distinguishes from siblings like opm_current_status (current) and opm_status_types (types) by emphasizing historical status changes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied through 'historical' and 'past status changes', but no explicit alternative tools are mentioned (e.g., 'For current status use opm_current_status'). Pagination guidance is provided but not comparative usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• os_candidate_summaryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the requirement for a CID, which is also captured in the schema, and does not disclose additional behaviors like return format, pagination, or rate limits. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core purpose, followed by a necessary prerequisite. Every word earns its place; no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description lists the key output fields (total raised, spent, cash on hand, debt), giving a good sense of return values despite no output schema. It doesn't mention the optional cycle parameter's default behavior or edge cases like a missing/invalid CID, but for a simple summary lookup, it is mostly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with clear descriptions for cid and cycle (including example format for cid). The description only reiterates the CID requirement and example, adding no new 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets a candidate's fundraising summary, listing specific data points: total raised, spent, cash on hand, debt. This is a specific verb-resource combination and distinguishes from siblings like os_top_contributors and os_industry_totals by focusing on a single candidate's summary.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this when you need a candidate's fundraising summary and have an OpenSecrets CID. It does not explicitly name alternatives or exclusions, but the 'Requires OpenSecrets CID' statement gives a concrete prerequisite, which is useful guidance for when to invoke this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• os_top_contributorsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true and the description uses 'Get' and 'Shows' which align with read-only behavior. It adds that the output is grouped by organization with PAC and individual contributions, but doesn't disclose pagination, defaults, or data limitations beyond what annotations already cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences: the first states the core purpose and the second clarifies the contribution types shown. No unnecessary detail or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with two straightforward parameters and no output schema, the description gives enough to understand the return scope (top contributing organizations with PAC and individual breakdowns). It could note the optional cycle default or response format, but the essentials are covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 cid and cycle. The description adds that the output is organized by contributor organization, but doesn't enrich the cycle parameter or provide additional parameter constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states 'Get top contributors (organizations) to a candidate' with a specific verb and resource, and adds that it shows PAC and individual contributions by organization. This distinguishes it from sibling tools like os_candidate_summary and os_industry_totals.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: use this tool to get top contributing organizations for a candidate. It doesn't name alternative tools or explicitly state when not to use it, but the context is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pubmed_cited_byA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds value by implying the return type (PMIDs) and the workflow of following up with pubmed_summary. But it does not disclose potential limitations such as pagination, rate limits, or how many results are returned, which would be richer 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two sentences. The first sentence states the core action, the second provides a rationale and a practical next step. Every sentence earns its place with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema and annotations present, the description covers the purpose, use case, and follow-up action. It does not explicitly state the exact return format but implies it by referencing 'returned PMIDs,' which is sufficient for an agent to understand the tool's role without additional documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes the single pmid parameter with an example ('12345'), and the description also says 'given PMID.' With 100% schema coverage, the description adds no additional semantic meaning beyond what is already structured, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Find articles that cite a given PMID.' This clearly distinguishes the tool from siblings like pubmed_search (search by query) and pubmed_summary (get article details), and the subsequent phrase about tracking impact further clarifies the unique purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives a clear use case ('tracking the impact and influence of a paper') and points to a follow-up tool (pubmed_summary) for acting on the results. However, it does not explicitly state when not to use this tool or compare it to alternatives like pubmed_related, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• rec_campsitesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by listing return fields ('campsite names, types, loops, and accessibility info'), but does not disclose potential limitations like pagination or error behavior. With annotations covering the core read-only nature, the description provides an average amount of extra 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each with a distinct role: action, usage prerequisite, and output summary. It front-loads the primary purpose and wastes no words, making it efficiently scannable for an AI agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter read-only tool with no output schema, the description adequately covers what the tool does, how to use it (via rec_facilities), and what it returns. It omits details like default limits or error cases, but those are either in the schema or not critical for basic invocation. Overall, it is sufficiently complete for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema already describes both parameters (facility_id and limit) with 100% coverage, so the description does not need to add much. It reinforces the meaning of facility_id by telling users to obtain it from rec_facilities, but that info also appears in the schema. Thus it meets the baseline for schema-covered parameters without going beyond.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Search available campsites') on a specific resource ('a specific recreation facility'), and clarifies the scope. It also distinguishes itself from sibling tools by referencing 'rec_facilities' for finding facility IDs, implying this tool is for facility-level campsite lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs the user to 'Use rec_facilities first to find facility IDs', providing a clear prerequisite and workflow. However, it does not mention alternatives (e.g., nps_campgrounds) or exclusions, so it falls short of fully explicit when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• regulations_comment_detailA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so the agent knows this is a safe read operation. The description adds minimal behavioral context beyond that, but it doesn't contradict the annotation and is adequate for a simple read tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no wasted words. It is front-loaded with the verb and object, making it highly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (one parameter), the annotation, and complete schema coverage, the description is sufficient. It doesn't detail the return structure, but without an output schema this is not a major gap for a simple detail tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with a clear description for commentId. The description echoes 'by its comment ID' but adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: get detailed information for a specific public comment by its comment ID. This distinguishes it from sibling tools like regulations_search_comments (for searching) and regulations_document_detail (for documents).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: when you have a comment ID and need detailed information. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough for an agent to choose this tool over search tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sbir_awards_searchA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true in annotations, the read-only nature is already disclosed. The description adds context about agency coverage and an example, but does not describe pagination defaults, result format, or rate limits. It doesn't contradict annotations, providing moderate additional 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately concise: it front-loads the purpose, lists common agencies in a helpful list, and includes an example—all in a few sentences. No redundant wording, every sentence contributes.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only search tool with no output schema, the description adequately conveys what the tool does, what agencies are covered, and how to structure a query. It lacks details about result fields or pagination, but the 6-parameter schema and simple scope make it sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all 6 parameters (100% coverage), so the baseline is 3. The description adds value by listing common agency abbreviations and showing a usage example, but does not add significant meaning beyond the schema's per-parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's specific verb and resource ('Search SBIR/STTR small business innovation research awards') and elaborates on search dimensions (keyword, agency, company, year) and coverage across all participating federal agencies. This distinguishes it from sibling tools like nsf_awards_search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool (searching SBIR/STTR awards by various criteria) and gives a concrete example of combining keyword, agency, and limit. It doesn't explicitly name alternative tools or exclusion criteria, but the scope is self-evident from the description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scorecard_compareA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so the read-only nature is already known. The description adds useful context about the comparison metrics (cost, graduation rate, earnings, debt) but doesn't disclose other behavioral aspects like output format or potential limitations. This is acceptable given the annotation coverage, but no additional behavioral traits are revealed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences that front-load the core purpose and provide a direct usage instruction. Every word adds value, with no superfluous detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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, read-only, no output schema), the description is sufficient to understand purpose and input. It doesn't describe the output format, but that is not critical for a direct comparison tool with a clear input type.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with the 'schools' parameter fully described in the schema, including format examples. The description only restates 'Provide school names,' adding no semantic value beyond what the schema already provides. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Compare specific colleges side-by-side on cost, graduation rate, earnings, and debt.' This provides a specific verb (compare), resource (colleges), and scope (specific, side-by-side), distinguishing it from sibling tools like scorecard_search or scorecard_top.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The instruction 'Provide school names to search and compare' implies the tool is used when you have specific colleges in mind to compare. While it doesn't explicitly mention alternatives or when not to use it, the context is clear enough for an agent to select it for direct college comparisons.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sec_filing_searchA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds useful context about the full-text scope across all SEC EDGAR filings and explains form type meanings. However, it does not disclose return format, pagination, or any limitations. With annotations covering the safety profile, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states the main purpose, the second lists form types. All information is relevant and front-loaded. There is no redundancy with schema details—the form type explanations add value. Extremely concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with full schema descriptions and a readOnly annotation, the description is largely complete. It gives the search scope and form type meanings. Missing is explicit mention of the return format or any result size limits, but these are not critical for a basic search tool with no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with each parameter described, so baseline is 3. The description adds meaning beyond the schema by explaining what each form type represents (e.g., 10-K annual, 10-Q quarterly, 8-K current events). This enhances understanding of the 'forms' parameter beyond the schema's simple list.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: "Full-text search across all SEC EDGAR filings" and specifies search dimensions (company name, keyword, topic). It also lists form types (10-K, 10-Q, etc.), which differentiates it from sibling tools like sec_company_search. This is specific and distinguishes the tool's scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating what can be searched (company name, keyword, topic) and lists form types, giving context for when to use it. However, it does not explicitly mention alternatives or when not to use it, such as when to prefer sec_company_search or sec_company_financials. No exclusions are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• septa_next_to_arriveA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safe read nature is covered. The description adds what fields are returned but does not clarify behavioral details like whether 'next' refers to real-time predictions or scheduled times, or what happens with invalid station names. This is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no wasted words. It front-loads the verb and resource, then specifies return fields, making every token informative and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 3-parameter read-only tool with fully documented schema and no output schema, the description covers the core purpose and return fields. It lacks mention of the real-time nature or time window, but given the simplicity and sibling context, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with start and end explained as origin/destination and count as number of results. The description does not add further parameter semantics beyond what the schema already provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific verb 'Get' and the resource: next trains arriving between two SEPTA regional rail stations. It also lists the return fields (departure/arrival times, delays, line info, connection details), distinguishing it from sibling tools like septa_bus_view or septa_train_view.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this tool is for querying next arrivals between two specific SEPTA stations, implying its use case. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• smithsonian_searchA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds useful behavioral context beyond the readOnlyHint annotation, such as returning 'matching records with basic metadata' and listing covered museums. However, it claims filtering by 'museum, date' without corresponding schema parameters, and the only way to filter is via query syntax (like 'unit_code:NASM'), which is only partially disclosed in the schema. This mild inconsistency reduces transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise and well-structured. It opens with the core purpose, provides key details (record count, filter types, output type), and adds a useful museum coverage list. Every sentence earns its place, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with 3 parameters and no output schema, the description is nearly complete. It specifies what is returned ('basic metadata'), covers the museums included, and notes the scale. The only gap is a clearer specification of output fields or structure, but this is not critical given the tool's simplicity and the schema's parameter documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description reinforces the query concept by mentioning filterable facets (keyword, museum, date), which adds some meaning not fully captured by the schema alone (e.g., museum via unit codes). It does not elaborate on limit or offset beyond what the schema provides, so it does not meaningfully exceed the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Search Smithsonian Institution collections.' It adds scope with '11M+ records across all museums' and distinct filters ('keyword, museum, date'), effectively distinguishing from sibling tools like smithsonian_detail, which likely handles individual record details rather than search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys clear context for when to use the tool: searching Smithsonian collections. It mentions common filter types and coverage, providing enough situational guidance. However, it does not explicitly state when not to use it or name alternative tools for similar tasks, such as using smithsonian_detail for specific record lookup.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_gis_servicesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already declares the tool's read-only nature. The description adds context about querying the state's ArcGIS REST endpoint and listing folders/layers, but does not disclose potential latency, pagination, authentication requirements, or output format. No contradiction exists between description and annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short, purposeful sentences. The first sentence fronts the main action, the second adds precision about the resource, and the third provides usage context. No redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, but the description explains what the tool lists and how to use the results for state_gis_query. It does not specify the exact return structure or whether nested folders are included, but for a discovery tool with strong annotations and schema, this is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters are well-documented: state has a full enum of state codes, folder has an example. The description does not add additional meaning beyond what the schema already provides, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses specific verbs 'Discover' and 'Lists' with a clear resource: 'GIS services' / 'service folders and layers' on the state's ArcGIS REST endpoint. It also distinguishes itself from sibling tools by explicitly referencing state_gis_query as the downstream consumer of the results.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context by stating 'Use the results to find service paths for state_gis_query', which positions this tool as a prerequisite discovery step. It does not explicitly mention alternatives or when not to use it, but the guidance is sufficient for an agent to understand the typical invocation flow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_transportationA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, which already communicates the read-only nature, and the description's 'Query' aligns with that. The description adds content scope (what data may be included) but does not disclose behavioral details such as pagination, return format, or rate limits. With annotations covering the safety profile, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, well-structured, and front-loaded with the primary purpose. The first sentence states what the tool does, and the second provides the key exclusion and alternative. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (6 parameters, all documented in the schema) and the presence of a readOnlyHint annotation, the description provides sufficient context for an agent to select and invoke the tool. It covers the scope and a key alternative, though it does not elaborate on query capabilities or response structure. Most gaps are filled by the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already documented. The description does not add additional parameter-level semantics beyond the schema, so the baseline score of 3 applies. It gives high-level context about the data domain but does not explain how to use parameters like 'q', 'where', or 'county'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Query transportation data for a US state.' It lists examples of content (vehicle registrations, EV adoption, traffic data) and distinguishes itself from sibling state_* tools and real-time traffic modules. This is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly provides an alternative for real-time traffic: 'For real-time traffic, use state-specific traffic modules (e.g., md_traffic_*).' This gives a clear when-not-to-use and an alternative. However, it does not discuss when to prefer this over other transportation-related tools like bts_transport_stats, so guidance is partial.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_dst_indexA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds interpretive context for the Dst values (e.g., thresholds for moderate/intense storms) but does not disclose specifics about the response format, time window, or data source. Thus it adds modest value beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core function, and no redundant information. The second sentence provides useful interpretive thresholds in nT, earning its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless tool with no output schema, the description is reasonably complete, identifying the index and its units via thresholds. However, it could clarify whether it returns the current value or a time series, and the exact response shape is not described. These gaps are minor given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has no parameters, so the schema covers everything. Baseline of 4 is appropriate; the description's threshold explanation adds context but is not required for parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with 'Get Dst (disturbance storm time) index', using a specific verb and resource. This distinguishes it from sibling SWPC tools like swpc_kp_index, which target different space weather indices.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by explaining Dst interpretation, but it does not explicitly state when to prefer this tool over alternatives such as swpc_kp_index or swpc_alerts. There is no alternative guidance or exclusions, so usage is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_scalesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds no further behavioral disclosure (e.g., rate limits or update cadence) but does not contradict the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two clear sentences, front-loaded with the main action, and no wasted words. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 returns (R/S/G scales with ranges) without an output schema. It could mention update frequency or data source, but for a simple current-level lookup it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  No parameters exist, so the schema fully covers them. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the output rather than parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves current NOAA space weather scale levels, specifies the R, S, and G scales, and distinguishes it from other SWPC tools focused on specific indices or forecasts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case (current scale overview) without explicitly contrasting with sibling tools like swpc_alerts or swpc_kp_index. It gives clear context but no exclusions or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_solar_windA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true annotation, the description adds value by disclosing the specific data components (density, speed, temperature, Bz, Bt) and explaining the scientific significance of southward Bz. This goes beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise at three sentences, front-loaded with the main action, and every sentence adds value: purpose, data fields, and domain context. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although there is no output schema, the description adequately explains the data content and time range (7-day) for a simple read-only tool with one optional parameter. It does not describe response format or units, but that is not critical for this simple retrieval.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameter semantics are fully documented in the schema. The description repeats the same field breakdown (plasma vs mag) and provides no additional parameter-specific details beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get 7-day solar wind data' with a specific verb and resource. It distinguishes from sibling SWPC tools by focusing on solar wind plasma and magnetic field data, not alerts or indices.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: if you need solar wind plasma/magnetic field data, use this tool. It provides context (7-day, types of data) but does not explicitly name alternatives or exclusions, relying on sibling tool names for differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• traffic_511_listA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description clearly states what data will be returned (states and platform type), going beyond the readOnlyHint annotation. It is consistent with the annotation and discloses the result contents in a straightforward manner.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately communicates the action and result. No extraneous words or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, zero parameters, and read-only annotation, the description is adequately complete. It specifies the scope (states with 511 data) and the output (platform type), which is sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema fully covers parameter semantics. The description adds no parameter details, but none are needed. Baseline of 4 is appropriate for a parameter-less tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') with a clear resource ('states with 511 traffic data') and specifies the output ('platform type'). It distinguishes the tool from generic state lists by scoping to 511 traffic data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 traffic_511_query or state_list. The description implies a purpose but does not explicitly state exclusions or mention sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• urban_ed_collegesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already communicates that this is a safe read operation. The description adds useful context about the data source (IPEDS) and coverage (Title IV institutions), but does not disclose any further behavioral traits such as return format, pagination behavior, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no wasted words. It front-loads the action and resource while adding relevant scope information in the second sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only query tool with a well-documented schema, the description combined with the schema is sufficient. It names the data source and population coverage, though it does not describe the response structure since no output schema is provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all four parameters individually documented (year, limit, offset, stateFips). The description does not add parameter-level meaning beyond noting that the data is FTE enrollment, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Query'), the resource ('college/university enrollment data (FTE) from IPEDS'), and the scope ('all Title IV postsecondary institutions'). This differentiates it well from sibling tools like urban_ed_schools and urban_ed_districts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use this tool: to query FTE enrollment data from IPEDS for Title IV postsecondary institutions. It does not explicitly mention alternatives or exclusions, but the resource-specific wording makes the intended use obvious enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• urban_ed_districtsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already communicates that this is a safe read operation. The description adds useful scope ('Covers all public school districts in the US') but does not disclose behavioral details such as return format, pagination limits, or filtering semantics beyond what the schema already provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose, and contains no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple query tool with four parameters and no output schema, the description provides the essential information: data type (district-level enrollment), source (CCD), and coverage (all US public school districts). It does not describe the return structure, but the low complexity makes this acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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), so the description does not need to explain them. It adds only general context about enrollment data, not parameter-specific meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Query') and identifies the resource ('district-level enrollment data from the CCD'), clearly distinguishing it from siblings like urban_ed_schools (school-level) and urban_ed_colleges (college-level).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states the scope ('all public school districts in the US') and implies a use case for district-level enrollment queries. However, it does not explicitly mention when not to use it or point to alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• urban_ed_schoolsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation. The description adds minimal behavioral context beyond the annotation, such as the data source (CCD) and national coverage. It does not disclose potential caveats like rate limits, pagination behavior, or data update frequency. Given the presence of readOnlyHint, the description adds some but not rich behavioral context, so a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no fluff. The key action ('Query school-level enrollment data') is front-loaded, followed by a concise scope statement. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the schema provides detailed parameter descriptions and annotations indicate read-only behavior, the description adequately covers the basic purpose and scope. However, it does not enumerate possible filters (like state or grade) or describe the response format, which would be useful since there is no output schema. Still, it is complete enough for a straightforward query tool with well-documented parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, meaning each parameter (year, grade, limit, offset, stateFips) already has a meaningful description in the schema. The tool description does not add any additional parameter semantics beyond what the schema provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Query school-level enrollment data') and identifies the resource (CCD, Common Core of Data). It differentiates from sibling tools like urban_ed_districts and urban_ed_colleges by explicitly specifying 'school-level' enrollment data. The scope ('Covers all public schools in the US') adds further clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is for querying school-level enrollment data, covering all US public schools. However, it does not explicitly mention alternatives or when not to use this tool (e.g., for district-level data, use urban_ed_districts). The absence of exclusions is acceptable, but no explicit alternative guidance means it doesn't reach a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usda_pricesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description's 'Get' action is consistent. The description adds scope context (any commodity, farmer prices) but does not disclose other behavioral traits such as pagination, date range handling, or response format, so it minimally supplements the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences front-load the core purpose and include useful examples. There is no filler, redundancy, or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple three-parameter tool with no output schema, the description covers the essential purpose and commodity flexibility. While it does not detail output structure or year range, those are inferable from the schema and the tool name, making it reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for year, state, and commodity. The description adds a general 'any commodity' statement and examples, but these largely overlap with the schema's commodity description. No additional meaning is provided for year or state beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns prices received by farmers for agricultural commodities, using a specific verb ('Get') and resource ('prices received by farmers'). It also differentiates from siblings like usda_crop_data and usda_livestock by emphasizing 'Works for any commodity' and providing examples spanning both crops and livestock.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use for any agricultural commodity price, with examples. However, it does not explicitly mention when to avoid this tool or point to alternative tools, so it lacks explicit exclusions but gives a strong sense of applicability.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usgs_earthquake_countA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover readOnlyHint=true. The description adds the behavioral nuance of returning counts rather than full records, which is useful context. However, it does not disclose any additional behaviors such as default date ranges, response format, or handling of empty results, which would be helpful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences effectively communicate the core purpose and a use case. The structure is front-loaded with the main action ('Count earthquakes matching criteria') followed by a concrete example. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple count tool with well-documented parameters and a readOnly annotation, the description is largely complete. It could explicitly state the return value format (e.g., a number or object), but the verb 'count' strongly implies the outcome. The absence of an output schema makes this a minor gap, but the overall context is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% parameter description coverage, so the baseline is 3. The description's example (M5+ in 2024) helps map to minmagnitude and starttime/endtime, but this is minor value beyond the schema descriptions already provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool counts earthquakes matching criteria, distinguishing it from sibling tools like usgs_earthquakes that fetch full details. The example 'How many M5+ earthquakes occurred in 2024?' makes the purpose immediately understandable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description indicates this is for statistics and explicitly says 'without fetching full details,' implying that the alternative tool should be used when details are needed. However, it does not name the exact sibling tool or provide explicit when-not-to-use guidance beyond that.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• uspto_application_documentsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation, and the description's use of 'List' is consistent (no contradiction). The description adds modest context by enumerating document types and filters, but it does not disclose pagination, return format, or any other behavioral traits beyond what annotations and the description already imply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states the primary function first and then lists filters. Every phrase earns its place, and there is no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list tool with one required parameter and no output schema, the description is largely complete: it conveys the resource, scope, and filtering capabilities. It does not mention return format or pagination, but given the simplicity and the readOnly annotation, it is sufficient without being verbose.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema descriptions already cover all parameters (100% coverage), so the baseline is 3. The description adds value by explicitly mentioning 'filter by document code or date range', which clarifies how document_codes and date_from/date_to are intended to be used. This goes slightly beyond the schema's individual descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and clearly identifies the resource: documents filed in a patent application. It also provides examples of document types (office actions, amendments, drawings) and states the filtering options, making it easy to distinguish from sibling tools like uspto_application_details or uspto_application_transactions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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 need to list documents in an application, with filtering by document code or date range. However, it does not explicitly name any alternative tools or state when not to use it, so the guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• uspto_petition_decisionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already discloses the safe read behavior. The description adds specific petition types and search dimensions but does not disclose pagination behavior, result size limits, or response format. For a standard search tool with readOnlyHint, this provides moderate added context without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose and followed by search criteria. Every word is useful, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with a rich schema and readOnlyHint, the description is adequate. It specifies the domain, petition types, and searchable fields. It does not explain response structure, but no output schema exists and the parameter details are covered. Minor gaps like default pagination are acceptable for this tool type.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions and examples (e.g., 'firstApplicantName:BRANT*', 'petitionMailDate 2021-01-01:2025-01-01'). The description adds a high-level list of searchable criteria but does not significantly enhance parameter understanding beyond what the schema already provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool searches USPTO petition decisions, names specific petition types (extension of time, revival, suspension), and lists searchable criteria (applicant name, decision type, technology center, date range). This clearly distinguishes it from sibling tools like uspto_ptab_decisions (PTAB decisions) and uspto_application_assignments.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for typical use (searching petition decisions with specific filters) but does not explicitly state when to use this tool versus alternatives, such as PTAB decisions. Given the many USPTO-related siblings, an explicit exclusion would be helpful, but the context is sufficient for basic selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• uspto_ptab_decisionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so the read-only nature is already known. The description adds context about available search dimensions but does not disclose behavior such as pagination, query syntax nuances, or result format. This is acceptable given the annotation coverage, but not particularly rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences that front-load the core purpose and key search fields. Every sentence earns its place, with no redundant or filler text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with fully documented parameters in the schema, the description adequately covers the main use cases and searchable dimensions. It does not detail return values or pagination behavior, but the schema documents limit/offset, and the tool's purpose is straightforward.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 value by surfacing high-level search dimensions (trial type, outcome, patent owner, grant date range) that map to the parameters, giving users a conceptual handle beyond the individual parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Search PTAB trial decisions.' It specifies the resource (PTAB trial decisions) and the action (search), and lists specific decision types (institution, final written) that distinguish it from sibling tools like uspto_ptab_proceedings or uspto_petition_decisions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains what users can search by (trial type, outcome, patent owner, grant date range) but offers no explicit guidance on when to choose this tool over similar PTAB sibling tools. It implies usage for trial decision searches but does not state exclusions or name alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wb_compareA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation declares the tool as read-only, so the safety profile is covered. The description adds that it compares across countries, but does not disclose other behavioral aspects like return format, handling of missing data, or limitations. It sticks to the core purpose without additional behavioral transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, tightly packed with value. The first declares the function; the second gives a practical example. No word is wasted, and it is front-loaded with the essential purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (3 params, no output schema, read-only annotation). The description covers purpose and use case, and the schema covers parameters, making it sufficiently complete for an agent to select and invoke the tool. It could optionally mention return format, but the lack is not a major gap given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 three parameters (countries, indicator, date_range) with formats and defaults. The description does not add further parameter-specific meaning beyond the schema, maintaining the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool compares a World Bank indicator across multiple countries, using a specific verb and resource. It distinguishes itself from siblings like wb_indicator or wb_search by emphasizing multi-country comparison and provides a concrete example question ('How does US compare to...').

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage context with 'Great for 'How does US compare to...' questions', signaling when to use this tool. It does not explicitly mention alternatives or exclusions, but the multi-country scope implicitly differentiates it from single-country or search tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wb_indicatorA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already communicates that this is a safe read operation. The description adds the list of popular indicators but does not disclose behavioral traits such as return format, time-series structure, or any data limitations. Since the annotation covers the safety profile, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loaded with the core action, and the second sentence efficiently lists four popular indicator codes. Every sentence adds value with no fluff or repetition of schema fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With a straightforward read-only tool, a clear schema, and a helpful set of examples, the description covers the essential context. However, since there is no output schema, the description could have briefly mentioned what the response contains (e.g., a time series or single value), leaving a minor gap in completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents all three parameters (100% coverage), but the description adds practical value by providing examples of indicator codes with human-readable meanings (GDP, life expectancy, health spend, unemployment). This goes beyond the schema's generic example and helps the agent select realistic values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get a World Bank indicator for a country.' This is a specific verb+resource combination that distinguishes it from siblings like wb_compare, wb_search, and wb_countries, which have different scopes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear action but provides no explicit guidance on when to use this tool versus alternatives like wb_compare or wb_search. Usage context is only implied by the verb 'Get' and the mention of popular indicators, with no exclusions or alternative suggestions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wmata_bus_predictionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true, the description already benefits from annotation coverage. It adds some context with 'next' implying real-time predictions, but does not disclose behavior like pagination, data freshness, or rate limits. This is adequate but not rich beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core action, and contains zero wasted words. It is appropriately concise for a single-parameter tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 is sufficient: it states what is returned (predictions), the target (bus stop), and the required input. It lacks any mention of edge cases or result limits, but these are not essential given the tool's simplicity and annotation coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the schema already describes stop_id as a 7-digit WMATA bus stop ID. The description only repeats this requirement without adding additional meaning, so it meets the baseline but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('Get') and resource ('next bus arrival predictions at a WMATA bus stop'). It distinguishes from sibling tools like wmata_train_predictions by specifying 'bus', and the requirement of a 7-digit stop ID is immediately clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear prerequisite ('Requires a 7-digit stop ID') and establishes the context (bus predictions for a specific stop). However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_international_investmentA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, so the description isn't required to state safety. It adds value by explaining what type of data is returned (stocks vs. changes from transactions/prices/rates), but it does not disclose behaviors like response format, pagination, or rate limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a concise opening sentence followed by organized lists for TypeOfInvestment and Component. All content is useful, though it could be slightly tightened by referencing a dataset list for full type options.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only data retrieval tool with well-documented parameters and annotations, the description provides sufficient context: it explains the tool's purpose, key parameter values, and default behavior. It doesn't describe return format, but the output schema is absent and the description's mention of what data is shown partially compensates.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 meaningful examples and definitions for TypeOfInvestment and Component, clarifying semantics beyond the schema's basic descriptions. It even provides default values and concrete examples like 'FinAssetsExclFinDeriv' and 'ChgPosTrans'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get U.S. international investment position (IIP) data' and explains what the data represents ('end-of-period accumulated stocks of U.S. financial assets and liabilities'). This specific verb+resource combination distinguishes it from sibling BEA tools like GDP or international transactions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool (to retrieve IIP data), and the examples of TypeOfInvestment and Component values implicitly guide use. However, it does not explicitly state when NOT to use it or name alternative tools for related data.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• calc_contract_ratesA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds that the tool shows all labor categories and rates, which is useful context, but it does not disclose pagination behavior or potential result size limitations beyond what the schema already provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the verb 'Get' and immediately states the resource and scope. Every word earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only lookup tool with only two parameters and no output schema, the description fully covers what the tool does, what input it needs, and what results are returned (all labor categories and rates). It is as complete as needed given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% as both contract_number and page_size have detailed descriptions. The tool description reinforces contract_number as the key input but adds no new meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves all ceiling rates for a specific GSA MAS contract by contract number (IDV PIID), which is a specific verb+resource+scope. It distinguishes itself from sibling tools by focusing on a single contract rather than searching rates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use: when you have a specific contract number and need all its ceiling rates. It does not explicitly mention alternatives like calc_search_rates for finding contracts, but the context is clear and no exclusions are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_death_rates_historicalA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes the tool is safe and non-mutating. The description adds useful behavioral context by specifying the dataset scope (age-adjusted rates since 1900, specific causes), but it does not disclose return format, pagination behavior, or potential edge cases. With annotations covering safety, the description provides moderate added value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the first sentence states the core function, followed by a succinct cause list and usage hint. No unnecessary words or repetition; every sentence contributes value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only historical data query tool, the description covers the essential context: what data is returned (age-adjusted death rates), the covered causes, and the time span (120+ years). The parameters are fully described in the schema, and the readOnlyHint covers the safety profile, so the description is complete for the agent to select and invoke the tool confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with each parameter already having a description in the input schema. The description adds a small benefit by listing the cause enum values and expanding the CLRD abbreviation, but it largely duplicates the schema's parameter information, matching the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Get'), resource ('age-adjusted death rates for major causes'), and time scope ('since 1900'). It also lists the exact causes covered, making the tool's purpose immediately clear and distinct from CDC siblings that focus on other metrics or periods.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool ('Great for long-term trend analysis — 120+ years of data'), which helps an agent select it for historical analyses. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of a full usage exclusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bill_cosponsorsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, so the safety profile is covered. The description adds that the tool returns party affiliation and sponsorship dates, but does not disclose pagination behavior or that the default/max limit of 250 may prevent returning a truly 'full list' for bills with more cosponsors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the main action and immediately followed by a valuable sibling comparison. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, and while the description mentions the type of data returned (party affiliation, sponsorship dates), it fails to explain the impact of the limit parameter on 'full list' semantics or describe pagination behavior. For a list endpoint with a 250 cap, this is a notable completeness gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are already documented. The description does not add extra meaning to the parameters beyond indicating the output context, matching the baseline for fully-covered schemas.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('full list of cosponsors for a bill'), and clearly distinguishes itself from sibling congress_bill_details by noting it returns individual cosponsor details rather than a party breakdown summary.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly names the alternative congress_bill_details and explains the key difference, telling the agent when to choose this tool over that sibling. This provides clear usage context and differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bill_full_profileA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already signals a read-only operation. The description adds behavioral context by noting 'Fetches 8 endpoints in parallel' and the composite coverage, which goes beyond the annotation. It doesn't detail potential delays or failure modes, so a 4 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a front-loaded main point, a clear list of included components, and a brief 'Ideal for' section. It's slightly long due to the component enumeration, but every sentence adds value, earning a 4.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, so the description carries the burden of explaining return values. It thoroughly lists the data sections returned and the parallel fetch behavior, which gives the agent a clear picture. It doesn't specify response structure details, but for this composite profile, the description is sufficiently complete (4).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All three parameters are fully documented in the input schema (100% coverage), and the description adds no additional parameter semantics—it focuses entirely on the output. The baseline of 3 is correct.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear, specific purpose: 'Get a COMPLETE bill profile in ONE call' and enumerates exactly what's included (bill details, cosponsors with party breakdown, action timeline, CRS summaries, etc.). It distinguishes itself from sibling granular tools by name, listing 'congress_bill_details + congress_bill_actions...' as alternatives, making it a clear 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit guidance to use this composite instead of calling eight individual congress_bill_* tools, and lists ideal use cases ('complete legislative analysis, bill research, accountability investigations'). However, it doesn't explicitly state when NOT to use it (e.g., if only a single data section is needed), so it's a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_law_detailsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations include readOnlyHint: true, which already signals a safe read-only operation. The description adds context about the type of information returned (sponsors, CBO cost estimates, committee reports, constitutional authority statement) but does not disclose rate limits, pagination, or other behavioral traits. With annotations covering the safety profile, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first front-loads the core purpose and output contents, and the second states the required inputs. There is no filler, redundancy, or ambiguity. Every word contributes to the description's utility.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only lookup with three well-documented parameters and no output schema, the description sufficiently explains what the tool does, what it returns (sponsors, CBO estimates, committee reports, constitutional authority statement), and what inputs are needed. This compensates for the lack of an output schema and makes the tool easy to select and invoke.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage with clear descriptions for all three parameters (congress, law_type, law_number). The tool description merely restates that these parameters are required, adding no additional semantic detail beyond the schema. Baseline of 3 applies per the rubric for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'Get detailed information about a specific public or private law' which clearly specifies the action (get detailed information) and the resource (a specific public/private law). It also lists representative content (sponsors, CBO cost estimates, committee reports, constitutional authority statement), which distinguishes it from sibling tools like congress_bill_details or congress_recent_laws.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states the prerequisites ('Requires congress number, law type, and law number') and uses 'specific' to convey that it is for retrieving details about an already‑identified law, implying when to use it. It does not explicitly mention alternatives or when not to use it, so it falls just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• co_water_rightsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the read-only safety profile, and the description adds content details such as 'appropriation dates and decreed amounts' but does not disclose behavioral traits like pagination, default limits, or response structure. The description is consistent with annotations and adds moderate context beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences deliver the core purpose and filter guidance without wasted words. The structure is front-loaded with the main action, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only search tool with four optional parameters and full schema coverage, the description sufficiently explains what the tool does and how to narrow results. The annotations and schema fill in the remaining details, and no output schema is needed for this simple search.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all four parameters with clear descriptions, and schema coverage is 100%, so the baseline is 3. The description repeats mention of county and water_source but does not add new semantic meaning beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific action ('Search Colorado water rights and structures') and identifies the resource type with concrete examples ('adjudicated water rights, diversions, wells, and reservoirs'). The scope is clear and distinguishes it from sibling tools like co_water_stations and co_water_readings, which focus on stations and readings rather than rights.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context by describing the primary filters ('Filter by county and/or water source name'), which indicates intended usage. It does not explicitly discuss when to use this tool over alternatives or mention exclusions, but the purpose statement is strong enough to guide selection among related Colorado water tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagov_dataset_detailA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the return content (title, resources, tags, etc.) but does not disclose behavior beyond that, such as error handling or whether 'full metadata' includes all possible fields. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose, and every clause carries useful information. It is concise without being terse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only one required parameter, no output schema, and read-only annotation, the description adequately covers return values by enumerating the major metadata fields. This is enough for an agent to invoke the tool and interpret the response correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes the single parameter 'id' as 'Dataset name (slug) or UUID' with an example, so schema coverage is 100%. The description repeats the 'by name (slug) or UUID' form, adding no new semantic detail beyond confirming the identifier can be either type.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') with a clear resource ('full metadata for a Data.gov dataset') and identifies the input as a name (slug) or UUID. This distinguishes it from sibling tools like datagov_search_datasets, which searches rather than fetches details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by specifying the identifier types ('by name (slug) or UUID'), which tells an agent when this tool is appropriate. However, it does not explicitly mention alternatives (e.g., use datagov_search_datasets to find datasets first) or state when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagov_list_organizationsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, and the description adds useful behavioral context: the return fields (name, title, description, dataset count) and the default sort order (by dataset count, most prolific first). This goes beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences, each adding distinct value: purpose, return fields, and default ordering. Front-loaded with the main verb and no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with full schema descriptions and a readOnlyHint annotation, the description covers the essential aspects: what it lists, what it returns, and default ordering. No additional context is needed for safe usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with all three parameters (sort, limit, offset) documented. The description's note about default sorting by dataset count is somewhat redundant with the schema's 'package_count desc' default, adding no new parameter-specific information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists federal agencies publishing data on Data.gov, with a specific verb and resource. It distinguishes itself from sibling tools like datagov_search_datasets and datagov_dataset_detail by focusing on agencies rather than datasets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (when you need a list of agencies on Data.gov) but provides no explicit guidance on when to choose this tool over alternatives or when not to use it. The context is clear 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.

• dol_osha_violationsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description need not restate safety. It adds useful behavioral detail by listing which fields are returned (standard cited, initial/current penalty, abatement status) and explaining that activity_nr links to inspections. It does not mention pagination, but that is handled in the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the primary action. Every sentence adds value: scope, violation type codes, return fields, and linkage to inspections. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 7 parameters and no output schema, the description covers the key return fields and the relationship to inspections. The schema handles pagination, sorting, and parameter formats. The only notable gap is the violation-type inconsistency, which prevents a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3, but the description introduces a mismatch: it lists U and F violation types that are not present in the viol_type enum (which only allows S, W, R, O). This can mislead an agent into sending invalid parameter values. It does add the useful clarification that activity_nr links to inspections, but the contradiction outweighs that benefit.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Search OSHA violations found during workplace inspections.' It clearly distinguishes this tool from sibling tools like dol_osha_inspections and dol_osha_accidents by focusing on violations and their attributes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly establishes context: use this when you need OSHA violation records, including cited standards, penalties, and abatement status. It does not explicitly name alternatives or state when not to use it, but the sibling set makes the intended use obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dol_ui_claims_stateA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds context about the data fields and the ability to compare across states, which is useful, but it does not disclose any additional behavioral traits such as pagination behavior, data freshness, or sorting defaults beyond what the schema already explains.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the core action. The second sentence adds clarifying detail about the comparison functionality without any waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with well-described parameters, the description provides enough context about what the tool does and what data is available. The absence of an output schema is mitigated by the description's mention of the specific claim types and the state-level scope, making the tool's purpose and invocation clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All five parameters have descriptions in the schema (100% coverage), so the schema carries the burden of explaining limit, state, offset, sort_by, and sort_order. The description does not add any parameter-specific meaning beyond what is already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get state-level weekly Unemployment Insurance (UI) claims.' It clearly distinguishes from national-level counterparts by stating 'state-level' and lists the exact metrics (initial claims, continued claims, insured unemployment rate) that can be compared.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for state-level comparisons and contrasts with tools like dol_ui_claims_national without naming it. It provides clear context (state-level vs. national) but does not explicitly state when not to use it or name alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eia_state_energyA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds context about the data source and MSN codes. However, it does not disclose behavioral details such as response format, pagination behavior, or what happens when no state parameter is provided. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized, beginning with a clear summary sentence followed by a structured list of MSN codes. Every element is directly useful, with no filler or redundancy, making it easy for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description provides a solid overview of data scope and code meanings, but since there is no output schema, it does not explain the response structure or how the data is returned. It also leaves some behavior unspecified (e.g., whether state is optional for all-state data), though the schema covers parameter defaults. Given the tool's simplicity, this 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.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All parameters are described in the schema (100% coverage), so a baseline of 3 applies. The description adds value by providing a curated list of MSN codes with their full names and units, going beyond the abbreviated examples in the schema. This helps the agent choose the correct code for the desired metric.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Get state-level energy data from the State Energy Data System (SEDS).' It further specifies what is covered (production, consumption, expenditures, and prices by energy source) and the geographic scope (all 50 states), which distinguishes it from sibling tools like eia_petroleum or eia_electricity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on the type of data this tool returns—state-level energy statistics from SEDS—but does not explicitly mention when to use this over siblings or any exclusions. The scope is well-defined enough that an agent can infer when this is the appropriate tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• faa_pirepA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as read-only (readOnlyHint=true). The description adds useful context about the types of conditions included (turbulence, icing) and the filtering option, but doesn't discuss rate limits, data source details, or return format beyond that.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences, front-loaded verb, every clause adds info about either the content or the optional filter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple one-optional-param read-only tool with no output schema, the description adequately covers the purpose, content, and filter option, making it sufficient for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter 'hours' is fully documented in the schema with min/max and description, and the description only reiterates the filtering behavior, adding no additional meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb 'Get' with a distinct resource 'pilot reports (PIREPs)', and lists specific content types (turbulence, icing, weather phenomena) that distinguish it from siblings like faa_metar or faa_taf.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Description clearly states what the tool returns and that hours is an optional filter, implying it's for recent PIREPs. However, it doesn't name alternative tools or state when not to use it, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_animal_eventsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, and the description adds meaningful context: the 1.3M+ report scale, masked 'MSK' values for privacy, and example query patterns that hint at response behavior. This goes beyond what the annotation states, with no contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded: a clear lead sentence, report contents, privacy note, and examples. Every line adds value, though the density of examples and count fields makes it slightly more verbose than strictly necessary.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter search tool with no output schema, the description covers the data domain, query syntax examples, privacy considerations, and report contents. It does not describe the response envelope, but the core information an agent needs to select and invoke the tool is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (both parameters have descriptions), and the description supplements this with concrete search examples ('animal.species:"Dog"', date range syntax) and a list of count fields, giving actionable guidance for constructing queries beyond the schema's generic field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource ('Search animal/veterinary adverse event reports'), and immediately distinguishes this tool from FDA human drug/device event tools by focusing on animal/veterinary data. It further clarifies scope with report contents (species, drugs, reactions, outcomes).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description strongly implies usage for animal adverse event searches, but it does not explicitly state when to use this tool versus sibling FDA tools (e.g., fda_drug_events) or mention exclusions/alternatives. The included example searches are useful for query construction but do not guide tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_tobacco_problemsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, covering the safety profile. The description adds valuable context beyond annotations: query syntax examples, count field hints, and dataset composition. It does not detail pagination or response format, but this is acceptable given the read-only annotation and simple 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the core purpose, followed by example queries and count field hints. Every sentence provides useful information with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, so the description needs to convey enough to use the tool effectively. It provides example queries, count field suggestions, and dataset context. It could mention response shape or result fields, but for a straightforward search tool with well-described parameters, it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, covering both `limit` and `search`. The description supplements this with example query values and mentions count fields, adding practical meaning beyond the schema. This goes beyond the baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search tobacco product problem reports' and provides specific scope (~1.3K reports) and content categories. The resource is well-defined and distinguishes from other FDA tools by topic, though it does not explicitly mention sibling alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context about when to use the tool (searching tobacco problem reports), describes dataset composition (e-cigarettes dominate), and provides concrete example searches. It lacks explicit alternatives or exclusions but is sufficient for an agent to determine appropriate use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fred_searchA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, which covers the safety profile. The description adds no extra behavioral context about return format, pagination, or how results are presented. It is not misleading, but it does not go beyond the annotation and 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: a clear purpose statement followed by examples. Every word earns its place, and the front-loading of the purpose makes it immediately scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with two parameters and no output schema, the description covers the basic operation and provides examples. However, it lacks any mention of what the results look like or how to follow up (e.g., using fred_series_info to get details on a found series), and no guidance on the limit parameter's consequences. This is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents both parameters (query='Keywords', limit='Max results (default 20)') with 100% coverage. The description adds value by giving concrete examples of query values ('GDP', 'unemployment', 'CPI', 'mortgage rate') and implicitly clarifies that limit is optional via its default. This goes beyond the bare schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search FRED series by keyword' which is a specific verb+resource. The examples ('GDP', 'unemployment', 'CPI') provide concrete use cases and help distinguish it from sibling tools like fred_series_info and fred_series_data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use this tool (to search FRED series by keyword), but does not explicitly mention alternatives or exclusions. It is evident from the examples and naming that this is the search entry point, but no direct comparison to other FRED tools is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• govinfo_cbo_reportsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, so the safety profile is covered. The description adds context about the source (GovInfo) and typical content (tax bill distributional analyses), but does not describe behavioral details like pagination behavior or return format. This meets the minimum bar without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences: the first states the primary function and source, the second provides relevant domain context. Every word earns its place; no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple search tool, full schema documentation for both parameters, and read-only annotation, the description covers what the agent needs. No output schema means return values are not described, but this mirrors similar well-scored tools and does not create a meaningful gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both 'query' and 'page_size' are documented, including an example for query. The tool description adds no additional parameter semantics beyond that, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Search' with a clear resource: 'Congressional Budget Office reports published through GovInfo.' It also adds a distinguishing use case about CBO scoring tax bills with distributional analysis, setting it apart from sibling tools like govinfo_search or congress_crs_reports.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates the tool is for searching CBO reports, and the added context about tax bill scoring gives a concrete scenario. It does not explicitly name alternatives or when-not-to-use, but the scope is clear enough for an agent to choose this over more general GovInfo search tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hmda_validate_uliA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already set readOnlyHint=true, so the description's burden is lower. It adds that the tool verifies the check digit and returns a validity boolean, which is meaningful behavioral context beyond the annotation. No side effects are mentioned, but the read-only nature is sufficient for this operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences, each adding value: the action, the output, and the purpose. It is front-loaded with the main verb and contains no redundant or unnecessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter, read-only validation tool with no output schema, the description fully covers what it does, what it returns, and why it would be used. No additional details about error handling or algorithms are needed for this simple operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the parameter description already explains the structure ('Full ULI to validate (loan ID + 2-digit check digit)'). The description adds that the tool 'verifies its check digit,' which reinforces the parameter's role but does not introduce extra semantic detail 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Validate a Universal Loan Identifier (ULI) by verifying its check digit,' which is a specific verb ('validate'), a clear resource (ULI), and the method (check digit verification). It also states the return value ('Returns whether the ULI is valid or invalid'), fully distinguishing it from siblings like hmda_check_digit that generate check digits.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly contrast with alternatives, but 'Used for HMDA reporting compliance verification' implies the intended context. There is no explicit when-to-use or when-not-to-use guidance, though the tool's simplicity makes it fairly obvious. The sibling list includes hmda_check_digit, and the description does not clarify the difference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hud_list_countiesA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations provide readOnlyHint=true, so the agent knows this is a read operation. The description adds useful context about the output (counties with FIPS codes) and downstream usage, but it does not disclose other behavioral details such as ordering, pagination, or potential errors. Given the annotation already covers safety, the description provides moderate added value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no unnecessary words. The first sentence states the purpose, and the second provides a practical downstream instruction. It is concise and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 1-parameter, read-only tool with a complete schema and no output schema, the description is sufficiently complete. It explains what the tool returns (counties and FIPS codes) and how to use the result in related tools, making it self-contained for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage for the 'state' parameter, including a clear description with examples. The tool description only re-states that it operates on a state without adding any new information about the parameter semantics. The baseline of 3 applies because the schema already explains the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'List counties in a state with their FIPS codes.' This uses a specific verb ('List') and resource ('counties in a state'), and distinguishes it from sibling tools like hud_list_states and hud_list_metro_areas by mentioning FIPS codes and the state scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by stating that the returned FIPS codes should be used as 'entity_id' in hud_fair_market_rents and hud_income_limits. This tells the agent when this tool is needed, but it does not explicitly contrast it with other listing tools such as hud_list_states or hud_list_metro_areas, so exclusions are not stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• la_metro_routesA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description's 'List' and 'Returns' align with a safe read operation. The description adds useful context about returned fields and bus/rail coverage, but it does not disclose behaviors like pagination, response size limits, or potential performance considerations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, with the verb and resource stated first. Each sentence earns its place: the first announces the tool's action and scope, the second details the return fields and coverage. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, no-parameter listing tool, the description fully explains what the tool does and what it returns. The readOnly annotation covers the safety profile, and the output fields are explicitly stated, making it complete for the tool's low complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The schema coverage is trivially 100% and there is no parameter information needed. The description adds no parameter detail, which is appropriate since there are none.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all LA Metro transit routes, using a specific verb (List) and resource (LA Metro routes). It distinguishes itself from siblings like la_metro_vehicles or la_metro_stops by specifying route IDs, names, types, and colors for bus and rail lines.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context (LA Metro routes) but no explicit guidance on when to use this tool over alternatives such as mbta_routes or la_metro_vehicles. It does not mention exclusions or name specific sibling tools, so usage is implied rather than explicitly directed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lobbying_detailA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds useful context about the output content (issues, bills, lobbyists) but does not disclose other behavioral traits such as pagination, error conditions, or response format. This matches the 'middle' benchmark where annotations do the heavy lifting.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states the action and expected contents, the second gives the required parameter source. Every sentence earns its place, and it is front-loaded with the primary purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With one parameter, no output schema, and a read-only annotation, the description sufficiently covers purpose, expected return fields, and how to obtain the required UUID. It is complete enough for an agent to select and invoke the tool correctly without additional documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the parameter description ('Filing UUID from lobbying_search results') is identical to the usage guidance in the tool description. The description adds no new semantic 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') with a clear resource ('specific lobbying filing') and lists what is included (every issue lobbied, specific bills mentioned, lobbyist names). This clearly distinguishes it from the sibling lobbying_search, which is for discovering filings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs to use the filing UUID from lobbying_search results, providing clear context and prerequisite. It does not explicitly state when not to use this tool or mention alternative detail tools like lobbying_contributions, but the guidance is still unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mbta_alertsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already conveys that this is a safe read operation. The description adds useful scope (what kinds of alerts are returned) but does not disclose additional behavioral traits such as pagination, default limits, or how 'active' is determined. With the annotation covering safety, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose, and includes the essential details (alert types, optional filter) with no filler. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple read-only tool with two optional parameters, both well-documented in the schema, and no output schema is required. The description explains what the tool returns and the filtering option, which is complete for an agent to select and invoke it correctly. The annotation covers safety.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents both 'limit' and 'route' with examples and defaults. The description only paraphrases the route filter ('Optionally filter by route') and adds no new semantic information beyond what the schema provides. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and identifies the resource ('service alerts for MBTA (Boston) transit'), and it lists the types of alerts (delays, suspensions, detours, planned changes) and the optional route filter. This clearly distinguishes it from sibling tools like mbta_predictions, mbta_vehicles, and mbta_routes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states that this tool provides MBTA service alerts and optionally filters by route, which gives sufficient context for when to use it (when the need is for MBTA alerts). However, it does not explicitly mention alternatives or exclusions (e.g., 'for predictions, use mbta_predictions'), so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• naep_compare_groupsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations include readOnlyHint=true, so the read-only nature is already known. The description adds behavioral details such as 'significance testing' and 'shows achievement gaps,' which go beyond the annotation and describe what the tool actually does with the data. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with no fluff. The first sentence states the core purpose, the second provides illustrative examples. Highly efficient and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, so the description must explain what the tool returns. It gives a high-level 'shows achievement gaps' but does not specify the output structure, how significance testing is represented, default values (e.g., year), or behavior with jurisdiction. This leaves some ambiguity for an agent interpreting the results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already has 100% coverage, including descriptions for variable ('SDRACE' race gap, 'GENDER' gender gap, etc.) and grade constraints. The description's examples ('White vs Black, Male vs Female') reinforce the variable semantics but do not add significant new parameter-level information beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Compare NAEP scores across demographic groups (race, gender, poverty) with significance testing.' It provides concrete examples (White vs Black, Male vs Female) and differentiates from sibling tools like naep_compare_years and naep_compare_states by focusing specifically on demographic group comparisons.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys clear usage context by specifying the tool compares demographic groups and shows achievement gaps. It does not explicitly mention alternatives or when not to use the tool, but the examples and phrasing make the intended use case obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nrel_fuel_stationsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, and the description's 'Search' verb is consistent. It adds scope context ('Covers all U.S. alt fuel infrastructure') and fuel type definitions, but does not disclose return format, pagination, or error behavior. With annotations covering safety, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose. The fuel type list is somewhat redundant with schema descriptions but earns its place by providing plain-language mappings. No unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 6 parameters, full schema descriptions, and read-only annotations, the description covers the essential search scope and fuel types. It does not elaborate on response contents or combination rules, but the schema and annotations carry much of that burden.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions. The description adds human-friendly fuel type expansions ('ELEC' → 'EV', 'HY' → 'hydrogen'), which aids agent comprehension beyond the raw schema enum values. This extra semantic value raises it above baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb 'Search for' and clearly identifies the resource: 'EV charging stations, hydrogen stations, biodiesel, CNG, and other alternative fuel stations.' It also distinguishes itself from siblings like nrel_solar and nrel_utility_rates by specifying alt fuel infrastructure.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear usage context: 'Covers all U.S. alt fuel infrastructure' and lists the filter dimensions ('Filter by state, zip, fuel type, radius'). Does not explicitly name alternatives or exclusions, but for a search tool this is sufficient guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nsf_award_detailA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations include readOnlyHint=true, so the read-only nature is already disclosed. The description adds context about the returned fields, which is useful, but it does not mention any specific behavioral traits like error handling, rate limits, or what happens if the award ID is not found. This is acceptable given the annotation, but not exceptionally rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states the function, the second lists the return fields. It is front-loaded and contains zero wasted words, making it highly efficient and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter detail tool with no output schema, this description is complete. It explains the purpose, the input, and explicitly lists what will be returned, which is essential since there is no output schema. No other context is necessary for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the awardId parameter is fully described in the input schema with an example. The description only says 'by award ID' and adds no new information about parameter formatting or semantics beyond what the schema already provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get', the resource 'full details of an NSF research award', and the identifier 'by award ID'. It lists specific return fields (title, PI info, institution, funding, abstract, program, co-PIs), which distinguishes it from the sibling search tool 'nsf_awards_search'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating 'by award ID', making it clear this tool is for fetching details when an award ID is known. It does not explicitly exclude search scenarios or mention the alternative nsf_awards_search, but the context is clear and no misleading alternatives are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ntsb_queryA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds useful behavioral detail about the return content (event details, injuries, probable cause) but does not disclose pagination behavior, potential limitations, or any other side effects. This is a reasonable addition beyond the annotation but not rich context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the core purpose, followed by modes, return content, and examples. The examples are useful but take up space; still, every sentence contributes meaning, and the overall length is appropriate for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 compensates by explicitly stating what is returned (event details, injuries, probable cause). It also covers the main query parameters with examples. It could mention pagination behavior or the relationship to the aviation-specific sibling, but overall it is sufficiently complete for this query tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage with descriptions for all parameters, giving a baseline of 3. The description adds value by offering concrete example values for mode and query, which illustrate how to construct valid queries and clarify the semantics of the 'query' parameter beyond the schema's 'Search text'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: querying NTSB investigation datasets by transportation mode. It enumerates the supported modes and describes the return content (event details, injuries, probable cause), and the examples differentiate it from the more specific sibling tool ntsb_aviation_accidents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use the tool (querying NTSB investigation data by mode) with practical examples. It does not explicitly mention alternatives or exclusions, such as pointing to ntsb_aviation_accidents for aviation-only queries, so it lacks explicit when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nws_alerts_by_stateA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation already declares readOnlyHint=true, and the description adds the scope of 'currently in effect' and the types (warnings, watches, advisories). However, it does not disclose behavior like return format, pagination, or response limits. Since annotations cover the safety profile, this is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the primary purpose and a concise note on return content. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one required parameter, no output schema), the description sufficiently covers what it does and what it returns ('warnings, watches, and advisories currently in effect'). Annotations provide the read-only safety context, making this complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameter 'state' is fully documented in the schema. The description adds no further parameter semantics, aligning with the baseline of 3 when the schema handles the documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get all active weather alerts for a specific state' with a specific verb, resource, and scope. It distinguishes from sibling tools like nws_alerts_active (broader scope) and nws_alert_detail (single alert).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the primary use case: retrieve alerts for a given state. It provides clear context ('for a specific state') but does not explicitly name alternatives or exclusion criteria, so it falls short of explicit when/when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sec_company_financialsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, covering the tool's safe read-only nature. The description adds that it 'returns standardized financial data' and specifies filing types, but does not disclose potential edge cases, rate limits, or error behaviors. With readOnly covered by annotations, the description provides marginal additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, front-loaded with the main purpose, and each sentence serves a distinct role (what it does, prerequisite, guidance, examples). It is concise without sacrificing necessary details, though the common concepts list could be formatted more cleanly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two parameters and no output schema, the description covers purpose, required input (CIK), prerequisite lookup (sec_company_search), and valid metric values. It does not explicitly state that omitting 'metric' returns a summary, but that is documented in the schema, so overall completeness is strong.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes both parameters with examples, and schema coverage is 100%. The description supplements this by listing common XBRL concepts (e.g., Revenues, NetIncomeLoss, Assets), giving the agent concrete valid values for the 'metric' parameter and adding value beyond the schema's generic description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get financial data ... from SEC XBRL filings for a company.' It specifies the source (10-K and 10-Q filings) and lists common data points, making the purpose explicit and distinct from sibling lookup tools like sec_company_search and sec_filing_search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear guidance on prerequisites ('Requires CIK number') and explicitly directs users to 'Use sec_company_search to look up filings first,' naming a specific alternative for a needed preliminary step. It does not explicitly state exclusions (e.g., when to use sec_filing_search instead), but overall usage context is well conveyed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_goes_xrayA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description does not contradict this. The description adds domain context (flare classes and radio blackouts) but no operational behavior details such as time range, units, or output format. This is acceptable for a read-only data fetch, but adds limited transparency beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two sentences. The first states the action, the second provides useful interpretive context about X-ray flare classes. Every sentence earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only tool with no output schema, the description gives core purpose and domain context but omits specifics like units (e.g., watts/m²), time coverage, or whether data is current or historical. This is a moderate gap for an agent interpreting results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and schema coverage is 100%, so the description need not explain parameters. The baseline for a 0-parameter tool is 4, and the description does not need to compensate for missing parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb+resource: 'Get GOES satellite X-ray flux data.' This uniquely identifies the tool among SWPC siblings like swpc_solar_flux, swpc_goes_particles, or swpc_kp_index. The added flare classification context reinforces the tool's specific subject.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this tool is for GOES X-ray flux data, which implicitly distinguishes it from other SWPC data tools. However, it does not explicitly state when not to use it or name alternative tools, so it is a clear context without exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usa_spending_by_stateA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares safe read-only behavior. The description adds that the tool returns total awards and per-capita spending, which clarifies output scope. However, it does not disclose additional behavioral details such as pagination, default fiscal year handling, or behavior when state is omitted—though the schema covers the latter.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It concisely states the resource, action, and key output metrics.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two optional parameters and no output schema, the description is sufficient. It states what the tool does and what it returns, while the schema covers parameter details. No significant gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters (state and fiscal_year) already described in the schema. The tool description adds no extra meaning about parameters, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (federal spending by state or territory) and the action (get), and specifies the output metrics (total awards and per-capita spending). This distinguishes it from sibling tools like usa_spending_by_award or usa_spending_by_agency by its geographic scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a clear use case: retrieving geographically aggregated federal spending. It does not explicitly name alternatives or state when not to use this tool, but the state/territory scope provides enough context for an agent to differentiate it from agency or recipient breakdowns.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• uspto_ptab_proceeding_detailsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a read operation, and the description consistently says 'Get details'. The description adds the trial-number scoping and example format, but no additional behavioral context such as rate limits or return structure. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no wasted words. It states the action, resource, and identifying input, and includes a helpful example at the end.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, single-parameter detail lookup with a read-only annotation and no output schema, the description fully covers what the tool does and what input is needed. No missing information is apparent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the single parameter already documented including an example. The description's reference to trial number adds no new semantic beyond what the schema provides, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('details for a specific PTAB trial proceeding'), clearly distinguishing this from sibling tools like uspto_ptab_proceedings (likely a list) by emphasizing 'specific' and 'by trial number'. The example trial number further clarifies the target entity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Clear context: this tool is for retrieving details when you already have a specific trial number. It doesn't explicitly name alternatives or when-not scenarios, but the 'by trial number' precondition and 'specific' wording make the intended use obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wb_searchA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation, lowering the bar for disclosure. The description adds keyword-based search and examples, but it does not explain what the search returns (e.g., indicator codes, names, metadata) or whether it is partial/fuzzy matching, which would be useful behavioral context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core action and resource, and each sentence adds value. The examples are concise and illustrative without extraneous detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With a single parameter and no output schema, the description is reasonably complete, but it omits any mention of return format or how results relate to sibling tools like wb_indicator. The examples hint at expected queries but not at the output structure (e.g., list of matching indicators with codes), which would be valuable for an agent to know how to proceed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides a clear description for 'query' ('Keywords to search for'), giving baseline 3 per high coverage. The description adds concrete examples of valid input values ('GDP', 'health expenditure', 'life expectancy', 'CO2 emissions'), which enriches the parameter semantics beyond the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Search') and the specific resource ('World Bank indicators') with keyword-based input. This distinguishes it from sibling tools like wb_indicator (likely for retrieving indicator data) and wb_compare, and the examples ('GDP', 'health expenditure') reinforce the intended scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys a clear use case: finding World Bank indicators by keyword. It implies when to use this tool (when you need to search for indicator names or terms) and the examples provide concrete queries, though it does not explicitly mention exclusions or alternatives like wb_indicator for fetching actual data.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wsdot_ferry_scheduleA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates safe read-only operation. The description adds context about the returned data fields but does not disclose potential limitations such as schedule availability ranges, error conditions, or whether all routes are included. It is consistent with annotations, so no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the main purpose and a concise list of return content. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one required parameter), the description covers the essential information: what it gets and what it returns. While there is no output schema, the description summarizes the response structure adequately for an agent to invoke and interpret the result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the single 'date' parameter, including format and example. The description only mentions 'specific date' and does not add extra semantics beyond the schema, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves Washington State Ferries sailing schedules for a specific date, with a specific verb ('Get') and resource ('sailing schedules'). It distinguishes from siblings like wsdot_ferry_vessels and wsdot_ferry_terminals by focusing on schedules and listing return contents (route descriptions, crossing times, individual sailing times).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use this tool when you need schedules for a specific date, and it indicates what is returned. However, it does not explicitly name alternative tools for related ferry data (e.g., vessels or terminals), so it lacks explicit exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_international_transactionsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare readOnlyHint=true. The description adds value by detailing the economic categories covered, listing valid indicator values with human-readable meanings (e.g., PfInvAssets, ExpGds/ImpGds), and explaining frequency codes (A, QSA, QNSA). It also points to bea_dataset_info for a fuller list. It does not disclose response format or pagination, but for a read-only data query the added context is meaningful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, starting with the core action and then using bullet lists for indicators and frequency codes. Every sentence carries useful information with no filler, and the structure makes the content easily scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the presence of 4 well-documented parameters and a read-only annotation, the description offers a strong overview of the data content and valid values. It lacks explicit return structure or pagination notes, but with no output schema and thorough schema parameter descriptions, it is sufficiently complete for typical usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with descriptions, giving a baseline of 3. The description amplifies indicator semantics by adding PfInvAssets and clarifying ExpGds/ImpGds as exports/imports of goods, plus reinforcing the balance-of-payments context. While it does not add much beyond the schema for year or area_or_country, the indicator examples provide extra practical meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Get U.S. international transactions (balance of payments) data.' It then clarifies the exact scope (goods/services trade, current account, financial account, capital transfers) and provides concrete indicator examples, making the tool's purpose unambiguous and distinct from sibling BEA tools like bea_gdp_national or bea_intl_services_trade.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for balance-of-payments data but does not explicitly state when to choose this tool over closely related siblings such as bea_intl_services_trade or bea_international_investment. It provides examples and data scope but no exclusions or alternative recommendations, so an agent must infer the usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_underlying_gdp_by_industryA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation, so the description adds valuable context beyond that: annual-only data, a 1997 start year, and a BEA caution about lower estimate quality. These are meaningful behavioral and data-quality disclosures not inferable from the annotation alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured. The core purpose is front-loaded in the first sentence, followed by two short sentences on temporal scope and data quality, and a final action-oriented pointer for prerequisites. Every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only, 3-parameter tool without an output schema, the description covers the necessary context: temporal availability, data quality caveat, and how to discover valid parameter values. It is nearly complete; a minor gap is not describing the response format or the fact that 'ALL' is the default for industry/year, though those are in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents all three parameters with clear descriptions (year, industry, table_id), achieving 100% coverage. The description repeats the tip to use bea_dataset_info for table_id/industry codes, which is already in the schema, so it adds no new parameter-level meaning. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear verb+resource structure: 'Get Underlying GDP by Industry.' It explicitly differentiates from the sibling tool by stating 'more industry detail than the main GDPbyIndustry dataset,' making the tool's unique scope immediately apparent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides context for when to prefer this tool (when more industry detail than the main dataset is needed) and directs users to bea_dataset_info for discovering valid TableIDs and Industry codes. It does not explicitly state when to choose the main GDPbyIndustry tool instead, but the comparison implies it, earning a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bls_series_dataA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint: true already covers the read-only nature. The description adds useful behavioral context by noting the frequency (monthly/quarterly/annual) and scope of data (employment, wages, prices). It does not contradict annotations and provides enough additional insight beyond the structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the core purpose. It includes a concise lead sentence, a bulleted list of popular series IDs with explanations, and a clear prefix legend. No unnecessary repetition; every element adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (many possible series IDs) and the absence of an output schema, the description provides substantial context through examples and prefixes. It could mention the response format, but the description is otherwise complete enough for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all parameters (100%), serving as a solid baseline. The description goes further by listing popular series IDs and explaining prefix meanings (CES, LNS, CU, etc.), which significantly aids in correctly constructing the series_ids parameter and understanding the start_year/end_year context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: "Fetch time series data from the Bureau of Labor Statistics." It specifies the resource (BLS) and the action (fetch), and provides concrete examples of series IDs and data types (employment, wages, prices), which distinguishes it from other BLS-related tools like bls_search_series or bls_employment_by_industry.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives. It implies usage by providing popular series IDs and prefixes, but gives no exclusions or references to sibling tools (e.g., 'use bls_search_series to find IDs'). This is adequate but lacks comparative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• caiso_signalA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile. The description adds minor context by listing the signal types, but it doesn't disclose additional behavioral traits such as update frequency, data latency, or response format. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured, with a clear opening sentence followed by a compact bullet list. Every sentence earns its place, and the format is easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter tool with a rich schema and readOnly annotation, the description is largely complete. It clearly states what data the tool returns. The only minor gap is that it doesn't explicitly state whether the response is a current snapshot or a time series, but this is not critical for tool selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the parameter fully (100% coverage), but the description adds extra nuance beyond the schema: it clarifies that 'rates' are time-varying, 'GHG' refers to carbon intensity, and 'FlexAlert' signals are active alerts with grid stress context. This adds meaning beyond the schema's enum descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('California ISO real-time grid signals'), and enumerates three distinct signal types (rates, GHG, FlexAlert). This distinguishes it from sibling tools like ercot_grid_conditions or isone_load, which target other grid operators.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this tool is for California ISO grid signals, and the enumerated signal types guide which parameter to use. However, it doesn't explicitly state when to avoid this tool or mention alternatives for other grid regions, so it falls short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• calc_search_ratesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations declare readOnlyHint=true, so the description is not burdened with restating safety. The description adds meaningful behavioral context by noting the data is refreshed daily and the search supports wildcard keyword, exact field matching, and browsing via filters. This goes beyond the schema's property descriptions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loads the primary action, and every sentence adds value. It avoids redundant restating of parameter names or schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 16 parameters and no output schema, the description covers the tool's purpose, use cases, and data freshness. It does not describe the return structure or pagination, but the schema handles parameter details. The description is complete enough for a search tool with rich schema documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, so the baseline is 3. The description adds a high-level summary of search modes (wildcard keyword, exact field match, filters) that maps to the keyword, search, and filter parameters, but does not elaborate on specific parameter syntax or interactions beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches GSA CALC+ ceiling rates for federal labor categories, with specific verbs ('Search', 'Find') and a resource. It distinguishes itself by specifying the data source and contract type, and the existence of sibling tools like calc_contract_rates reinforces the specificity of this tool's scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit use cases ('market research, IGCEs, and competitive pricing') and describes search modes (keyword, exact field, filters). It does not explicitly contrast with similar sibling tools like calc_contract_rates or calc_suggest, but the use cases make the intended context clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• calfire_incidentsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds value by listing the specific fields returned (name, location, acres burned, containment, etc.) and the update frequency for active fires, providing useful behavioral context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences: the first states the core purpose, the second summarizes return fields, and the third notes update cadence. Every sentence adds value with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read-only tool with no output schema, the description covers the purpose, modes, return content, and update behavior. It could explicitly mention that historical data starts from year 2000, but that is already captured in the schema's minimum constraint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both year and active. The description does not elaborate on parameter syntax or semantics beyond what the schema already states, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get California wildfire incidents from CAL FIRE', a specific verb+resource combination that clearly states the tool's function. It further specifies the two modes (active/historical by year), distinguishing it from the sibling tools, none of which deal with wildfire incidents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on the two modes (active fires vs. historical by year) and notes that active fires update frequently during fire season. However, it does not explicitly name alternatives or give when-not-to-use guidance, though the unique domain makes such exclusions less necessary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_drug_overdoseA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description does not contradict this. The description adds useful context about the time range and demographic breakdowns, but it does not disclose deeper behavioral aspects such as data suppression rules, rate calculation methodology, or any limitations. This is acceptable given the annotations but not enhanced.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the main action and enriched by scope and use case. Every sentence earns its place with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only query tool with four optional parameters and no output schema, the description conveys the dataset content, time range, and dimensions (state, sex, race, age). It omits explicit return format, but the schema's 'limit' description and the readOnly annotation provide enough context for an agent to expect a list of records. Minor gaps exist but are not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 meaning beyond the schema by noting that the data includes death rates by race and age group, which are not filterable parameters in the schema. This gives the agent useful context about the dataset's content and dimensions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves drug poisoning/overdose mortality data by state for 1999–2016, using a specific verb and resource. It distinguishes itself from sibling CDC mortality tools by explicitly focusing on drug overdoses, making its purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for when to use the tool ('Critical for opioid crisis analysis') and conveys the data scope. It does not explicitly name alternatives or exclusions, but the use case is sufficiently implied for an agent to recognize when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_places_cityA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile, and the description adds meaningful value beyond that by disclosing the data structure (one row per city, all measures as separate columns) and the population threshold. It does not mention pagination or rate limits, but for a read-only data lookup, the added scope and structure context is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two sentences, with the first sentence front-loading the verb, resource, and key measures, and the second sentence clarifying the row-level data shape. Every clause adds useful information, with no tautology or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (3 optional parameters, no output schema), the description covers the essential context: what data is returned, its granularity, and its structure. It complements the readOnlyHint annotation and detailed schema without needing to explain return values. The only minor gap is that it doesn't specify what happens when no city or state is provided, but the schema's parameter descriptions handle that implicitly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides detailed descriptions for all three parameters (city with partial match, limit with default, state with code examples), achieving 100% schema description coverage. The tool description does not add further parameter-specific meaning beyond what the schema already explains, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('Get'), resource ('city-level health indicators from CDC PLACES'), and scope ('every U.S. city with population > 50,000'). It lists specific measures and distinguishes itself from the sibling tool cdc_places_health by focusing on city-level data rather than a broader geographic scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool by emphasizing city-level granularity and the comprehensive set of measures, giving clear context for selecting it over other CDC tools. However, it does not explicitly name alternatives or provide exclusion criteria, so it stops short of offering direct guidance on 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.

• cdec_sensor_dataA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful domain context (sensor meanings, station examples) but does not disclose return format, pagination, or historical data behavior. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the purpose and then provides compact, well-organized reference lists. Every line adds value, with no fluff or redundant restatement of schema fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, so the description carries some burden to explain what the tool returns. It explains the key domain codes needed for invocation but does not describe the return structure or time-series format. Still, given the tool's simplicity and the schema's coverage, it is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 additional sensor numbers (30, 2) and more station ID examples (FOL, DNP, NML, BUL) beyond the schema's examples, making parameter selection more informed and accurate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get real-time sensor data from California Data Exchange Center (CDEC) monitoring stations,' identifying the specific verb, resource, and scope. It distinguishes itself from sibling tools like cdec_stations by focusing on sensor readings rather than station metadata.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context by listing common sensor numbers and station IDs, helping the agent know what values to use. However, it does not explicitly mention when to use this tool over alternatives or any exclusions, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdec_stationsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes the safe read-only nature. The description adds useful context about the kind of metadata returned (location, operator, river basin, sensors) but does not disclose additional behaviors like response format, pagination, or error handling. This is acceptable given annotation coverage, though 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences deliver the purpose, content, and usage guidance with zero redundancy. The information is front-loaded ('Get metadata for CDEC monitoring stations') and fully earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter lookup tool with a read-only annotation, the description is largely sufficient. It lists the metadata fields returned, which compensates for the absence of an output schema. A small gap exists in that it doesn't state that the response contains a single station's metadata or mention any error conditions, but these are minor for this tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with clear examples (e.g., 'SHA', 'ORO', 'FOL'). The description reinforces that the station_id is used to look up metadata, but adds no new parameter semantics beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves metadata for CDEC monitoring stations, listing specific content areas (location, operator, river basin, available sensors). It distinguishes itself from the sibling tool cdec_sensor_data by emphasizing metadata lookup and positioning this as a prerequisite step.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use the tool: 'Use this to find station IDs before querying sensor data.' This provides a clear usage context and implicitly contrasts with the sensor-data querying tool, offering directional guidance to the agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• census_populationA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already conveys the safe read-only nature, so the description's job is lighter. It adds context about the data source (American Community Survey) and geographic scope (U.S. states), but does not disclose details like response format, default behavior, or edge cases. This is adequate but not rich beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no filler. It front-loads the main purpose, then immediately provides the alternative tool reference. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with two well-documented optional parameters and no output schema, the description covers the essential usage context: what data it returns (population), the source (ACS), and when to prefer the general query tool. It does not explain the return format, but the low complexity keeps this from being a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for both parameters (year with range and default, state with FIPS examples). The description adds little beyond mentioning 'U.S. states' as the scope, so it does not significantly improve parameter understanding beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action and resource: 'Get population data for U.S. states using the American Community Survey.' It clearly distinguishes this tool from siblings by calling it a 'Quick shortcut' and pointing to census_query for more flexibility, which separates it from the general query tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance on when to use this tool versus an alternative: 'Quick shortcut — for more flexibility use census_query directly.' This tells the agent that census_population is for simple population lookups, while census_query is the better choice when more flexibility is needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• census_search_variablesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already discloses the safety profile. The description adds valuable context: it returns variable IDs, not data values, and that these IDs can be used with census_query. This goes beyond what annotations provide and does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, each earning its place: the first states the core action, the second explains the purpose, and the third explains the output and integration with census_query. There is no redundant or vague wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with full schema coverage and no output schema, the description adequately covers the core purpose, the output type, and the follow-up use. It does not describe result format or pagination, but this is acceptable given the tool's simplicity and the schema covering parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% description coverage, including examples for dataset and keyword. The description adds no additional parameter semantics beyond what the schema documents, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Search for Census variable names/codes by keyword.' It clearly distinguishes itself from the sibling tool census_query by stating it returns variable IDs for use with that tool, effectively differentiating a metadata discovery tool from a data query tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool by noting 'Helps discover what data is available in a given dataset' and explicitly connects the workflow: 'Returns variable IDs you can use with census_query.' This provides clear context but does not explicitly state exclusions or alternative tools beyond the implied census_query.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfpb_state_complaintsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description doesn't need to cover safety. It adds useful context about return behavior ('Returns complaint counts and data for each state') and filter compatibility with search, which goes beyond the minimal annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with purpose, then output, then usage context. Every sentence is informative with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple and the schema covers all parameters. Without an output schema, the description adequately explains the return format ('counts and data for each state'), though 'data' could be more specific. Overall, sufficient for a state breakdown tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by noting that filters align with search, but it doesn't expand on individual parameter 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose with a specific verb and resource: 'Get complaint information broken down by state (geographic view).' It distinguishes from sibling tools like cfpb_search_complaints and cfpb_complaint_trends by emphasizing the state-level geographic breakdown and utility for maps and comparisons.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context for when to use the tool: 'Useful for maps and state comparisons.' It also references the same filters as search, implying it's an alternative for state-level views. However, it does not explicitly name alternative tools or specify 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.

• clinical_trials_metadataA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only behavior is covered. The description adds useful context beyond annotations by explaining what information is exposed (field names, types, descriptions) and how the output is meant to be consumed in other clinical trials tools. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no filler. The first sentence establishes scope and output, the second provides concrete usage guidance. Every phrase earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only metadata tool with two optional boolean parameters and full schema coverage, the description is sufficient: it explains the tool's purpose, output content, and relation to sibling search/detail tools. A minor gap is not explicitly mentioning the include_* parameters, but the schema covers those.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both parameters (include_indexed_only, include_historic_only) already have descriptive text in the schema. The description adds no further parameter-specific detail, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Explore') and names a precise resource ('ClinicalTrials.gov study data model') with concrete outputs ('field names, types, and descriptions'). It clearly differentiates this metadata tool from sibling search/detail tools by framing it as data-model discovery.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit use cases: discovering fields for the `fields` parameter and building AREA[] filter expressions. It does not explicitly mention alternative metadata-related sibling tools (e.g., clinical_trials_field_values, clinical_trials_enums) or state when not to use them, but the primary use context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clinical_trials_statsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation covers safety, and the description adds that it queries 8 statuses in parallel, which is a useful behavioral detail beyond the annotation. It also discloses flexible input types (disease or drug), aiding the agent in anticipating 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, front-loaded with the main action, and contains no redundancy. Every sentence adds value, covering purpose, output nature, input flexibility, and implementation behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (2 params, read-only, no output schema). The description sufficiently conveys the output type (count breakdown by status), input types, and parallel querying behavior. It doesn't list the exact 8 statuses, but the examples and 'etc.' imply the breakdown is comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% parameter coverage with descriptions. The description's examples ('breast cancer', 'semaglutide') overlap with schema examples and don't add significant new meaning beyond what the schema offers. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the tool produces a trial count breakdown by recruitment status for a condition or drug, clearly identifying its function. It distinguishes itself from sibling clinical trial tools (search, detail, results) by focusing on aggregated statistics rather than lists.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is for count breakdowns by recruitment status and works with both diseases and drug names. It doesn't explicitly name alternative tools, but the 'breakdown' focus and mention of parallel status queries make the use case clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_reports_for_committeeA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description is consistent with the readOnlyHint annotation and adds context that the reports are formal committee reports accompanying legislation. However, it does not disclose return format, pagination behavior, or how it differs from other report endpoints beyond the committee scoping; given the annotation already covers the read-only safety, this is acceptable but thin.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise, front-loaded sentences convey purpose and a key prerequisite without redundancy. Every clause adds information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple filtered-list tool with a read-only annotation, the description covers the fundamental purpose and a required-parameter acquisition path. It does not detail the output structure, but the absence of an output schema is partially mitigated by the clear 'shows formal committee reports' phrase. Still, an agent might want more return-field information, so it's not perfect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents all five parameters with descriptions and formats. The description adds value by instructing to use congress_committees to discover the committee_code, which is the key parameter needed for correct invocation. This elevates it above a pure schema baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get reports published by a specific committee,' clearly identifying the action and object. It distinguishes from generic committee-level tools by specifying 'specific committee' and points to congress_committees for the code, which aligns with the known sibling set.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear context that this tool is for committee-specific reports and instructs the user to consult congress_committees for the required committee_code. It doesn't explicitly list exclusions for alternative report tools, but the specific-committee framing implies when to use it over broader report endpoints.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_daily_congressional_recordA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds context about sections and the two usage modes, but does not disclose response format or pagination behavior. With annotations covering safety, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two compact, well-structured sentences. The first states the verb and resource, the second explains usage. No redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with three optional parameters and no output schema, the description is adequately complete. It covers the primary usage modes and names key sections, though it doesn't detail return fields or clarify its relationship to the similarly named sibling congress_congressional_record.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 meaning by explaining the volume/issue combination for targeting a specific issue and limit for listing recent issues, which provides a conceptual framework beyond the bare schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves daily Congressional Record issues, naming specific sections (Senate, House, Extensions of Remarks, Daily Digest) and the ability to filter or list recent issues. It effectively distinguishes itself from the 'bound' Congressional Record sibling by emphasizing 'daily.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear usage context: filter by volume and issue for specific issues, or list recent issues. However, it does not explicitly mention alternatives like congress_congressional_record or congress_bound_congressional_record, so no direct comparison or exclusion is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_infoA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description adds useful context about the returned content (sessions, dates, chambers) and potential uses. It does not describe pagination or list limits, but those are already covered in the schema. Since the read-only nature is annotated, the description's additional behavioral context is sufficient. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that immediately states the tool's purpose and key data fields. It avoids redundancy with the schema and provides two concrete use cases without excess length. Every clause adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with three optional parameters and no output schema, the description covers the core purpose, returned data (dates, numbers, chambers), and target use cases. It does not explicitly mention the default 'list recent congresses' behavior, but that is present in the schema, so the description is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for all three parameters (limit, current, congress). The description does not add parameter-level detail but aligns with the meanings conveyed in the schema. With full schema coverage, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description specifies a concrete verb-resource pairing ('Get information about congresses and their sessions') and enumerates the data fields (start/end dates, session numbers, chambers). It clearly differentiates from sibling congress_* tools focused on bills, members, or votes. The inclusion of use cases ('look up when a congress was in session, or get current congress details') reinforces its distinct scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this for congress/session information and for current congress details. It does not explicitly name alternative tools or provide when-not-to-use guidance, but the focused scope implies the right conditions. The use case statement is actionable, so it merits a 4 rather than a 3.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_nomination_detailsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description aligns by describing a read operation. The description adds context about the included actions (committee referral, hearing, vote, confirmation/rejection), which discloses the tool's behavioral scope beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single, front-loaded sentence that states the purpose and key inclusions without waste. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple detail lookup with two parameters, the description adequately explains what the tool returns at a high level. It does not mention response structure (no output schema), but the inclusion of 'all actions' gives a reasonable completeness for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers both parameters fully with descriptions ('Congress number', 'Nomination number (PN number)'), so baseline 3 applies. The description does not add 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Get'), the resource ('detailed information about a specific presidential nomination'), and the scope ('including all actions...'), which distinguishes it from related search/list tools like congress_nominations. It is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'specific presidential nomination' implies use when you have a known congress and nomination number and need comprehensive detail, which is clear context. However, it does not explicitly mention alternatives like congress_nomination_full_profile or when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_search_membersA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds value by listing the endpoint shapes, which clarify how parameters combine (e.g., district requires state, congress can be used alone). It does not disclose return format or pagination behavior, but the added endpoint details are meaningful beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states the core purpose with key filters, and the second lists the exact endpoint patterns in a compact, scannable format. Every sentence earns its place, and it is front-loaded with the most important information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 7 optional parameters and no output schema, the description covers the main usage patterns comprehensively via the endpoint list. However, it does not mention behavior when currentMember is omitted (i.e., whether results include both current and former members) or pagination details beyond the limit parameter. Given the tool's moderate complexity, the description is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (all 7 parameters have descriptions). The description's 'Supports:' list echoes parameter combinations but does not add substantive new meaning beyond what the schema already provides (e.g., schema already notes state can be used with district, and congress 'Use alone to list all members'). Per the rubric, baseline 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Search for members of Congress by state, congress number, district, or get all current members.' It uses a specific verb ('search') and resource ('members of Congress'), and enumerates filter dimensions, which distinguishes it from sibling tools like congress_member_details (which fetches details for a specific member) and congress_member_full_profile.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on how to use the tool via the supported endpoint patterns (e.g., '/member/{stateCode}', '/member/congress/{congress}'), and mentions the 'get all current members' use case. It does not explicitly name alternatives or exclusions, but the supported patterns imply when each filter combination is appropriate. This meets the 'clear context, no exclusions' bar.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• co_water_stationsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint: true, so the description's job is lighter. It adds useful context about the return payload: station abbreviations, location, parameter type, and metadata, which helps the agent understand what to expect without an output schema. It does not disclose details like pagination or default values, but those are partially covered by the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a two-sentence, front-loaded summary. The first sentence states the core purpose, and the second provides return value information. There is no filler or redundant repetition of schema details, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential aspects: what the tool does, what it returns, and its relationship to co_water_readings. With no output schema, it provides enough context for a search tool. It could be slightly more complete by clarifying behavior when no filters are supplied, but overall it is sufficient for an agent to select and use it effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for all four parameters, including the filter fields (county, division, water_district) and limit. The description restates these filters but does not add new details such as how multiple filters interact or the default limit behavior, so it adds only marginal value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Search Colorado telemetry stations — find monitoring stations by county, water district, or division.' It uses a specific verb ('search'), a resource ('Colorado telemetry stations'), and the filtering scope, making it easy to distinguish from sibling tools like co_water_readings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly mentions that the tool 'Returns station abbreviations needed for co_water_readings,' which tells the agent when to use this tool (before querying readings). However, it does not explicitly state when not to use it or compare it to other alternatives like cdec_stations, though the Colorado focus provides some implicit differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dap_gov_wide_reportA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds meaningful context beyond that: it clarifies that data is aggregated government-wide and provides an example of parameter usage. It does not discuss response format or pagination, but with the annotation covering safety, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded, stating the main purpose in the first sentence. It includes a helpful example and no filler. Every sentence adds value, making it highly efficient for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 5 parameters, an output schema absent, and readOnly annotations, the description covers the essential scope, provides an example, and lists report types. It does not describe the response structure, but for a read-only reporting tool with well-documented schema and clear purpose, completeness is solid. Missing explicit pagination behavior is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the description adds an example (report='site', limit=50, after='2025-01-01') that illustrates parameter usage. It also summarizes report types, but the enum in the schema already lists all valid values. The description does not significantly deepen understanding of individual parameters beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get a government-wide web analytics report from the Digital Analytics Program.' It explicitly notes it returns 'aggregate data across all federal government websites,' distinguishing it from sibling tools like dap_agency_report and dap_domain_report which focus on narrower scopes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by emphasizing the government-wide, aggregate nature of the report, which implies when to use it over agency/domain reports. However, it does not explicitly mention alternatives or provide exclusion criteria (e.g., 'for a single agency, use dap_agency_report'), so it misses the explicit 'when-not-to-use' guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagov_search_datasetsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation. The description adds useful context: the catalog size, supported query dimensions, and the return fields. It does not discuss pagination behavior, rate limits, or potential empty-result scenarios, but with the annotation covering safety, the added detail is sufficient for a basic understanding.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the action and resource, and every sentence earns its place. Examples are integrated inline, and there is no redundant restating of the tool name or the readOnlyHint annotation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with six well-documented parameters and no output schema, the description covers the core purpose, filter usage, and return fields. It does not explain edge cases like pagination or facet usage, but the schema provides parameter-level details for those. Overall, it is sufficiently complete for an agent to select and invoke the tool for a typical search task.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with each parameter individually described. The description adds value by demonstrating fq syntax with concrete examples ('organization:nasa-gov', 'res_format:CSV') and explaining the semantic categories (keyword, topic, agency, format). It also clarifies the return payload structure, which complements the schema's parameter-level descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Search') and resource ('Data.gov federal open data catalog'), with clear scope ('400K+ datasets') and explicit return fields. It distinguishes itself from sibling tools like datagov_dataset_detail and list_datasets by focusing on the federal open data catalog search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates when to use the tool: to find datasets by keyword, topic, agency, or format. It provides concrete examples of fq filter usage, which helps the agent formulate effective queries. It does not explicitly name alternatives or state when not to use it, but the search purpose is clear and self-contained.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dol_osha_accidentsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare `readOnlyHint: true`, so the agent knows this is a safe read operation. The description adds that it returns event descriptions, dates, locations, and industry codes, which is useful context, but it does not disclose pagination behavior or any other operational details beyond what the schema already provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences long and every sentence earns its place: purpose, return fields, and a pointer to a sibling tool. It is front-loaded with the primary action and contains no redundant phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 does explain the return content (event descriptions, dates, locations, industry codes). It also points to a sibling for injury details. It does not explicitly distinguish from other OSHA tools like `dol_osha_inspections` or `dol_osha_violations`, but the tool names and other descriptions make those distinctions clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all 7 parameters, so the schema fully documents each parameter's meaning and defaults. The description adds no additional parameter-level information, which is acceptable under the baseline for complete schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Search OSHA accident and fatality investigations.' It clearly states the tool's scope and explicitly names the sibling tool `dol_osha_accident_injuries` for injury details, distinguishing it from that alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear alternative: 'Use dol_osha_accident_injuries to get injury details for a specific accident.' This tells the agent when to choose a different tool, effectively providing when-to-use vs. alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dol_osha_inspectionsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Given the readOnlyHint annotation already conveys safety, the description adds value by disclosing the return contents ('site details, inspection type/scope, open/close dates') and explaining inspection type codes. This goes beyond the annotation, though it does not discuss quotas, pagination behavior, or error cases.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured, with a front-loaded purpose statement followed by compact, useful filter and return information. Every sentence earns its place; no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 9-parameter search tool with no output schema, the description covers the core concepts: what it searches, key filter dimensions, type codes, and return fields. It doesn't mention defaults for limit/sort, but those are documented in the schema, and the tool is not overly complex. The description is adequate for an agent to decide whether to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 restates what the schema already contains (e.g., state, SIC/NAICS, inspection type codes) without adding new meaning or clarifying parameter relationships or syntax beyond the schema's descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Search OSHA workplace inspections,' clearly identifying the action and resource. It then lists specific filter dimensions (state, establishment, industry, type) and inspection types, which differentiates it from sibling tools like dol_osha_violations and dol_osha_accidents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on what can be searched (state, establishment, SIC/NAICS, type) and enumerates inspection types with their meanings. However, it does not explicitly mention when to use this tool over sibling tools (e.g., dol_osha_violations), so it lacks explicit exclusions or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dol_ui_claims_nationalA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation covers the safety profile, and the description adds useful context: the included metrics (insured unemployment rate, covered employment) and the interpretation (spikes indicate stress). No contradictory behavior is disclosed. It stops short of describing pagination or data formatting, but those are partially covered by the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short, front-loaded sentences each add value: what the tool gets, what extra metrics it includes, and how to interpret the data. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the purpose, key data elements, and economic significance. While there is no output schema, the description mentions the main outputs (claims, rate, employment). Pagination and sorting are covered by the schema. It could be more explicit about common use cases or data quirks, but overall it is sufficient for an agent to select and call the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already handles parameter meaning. The description adds no further parameter-level detail beyond the 'weekly' context, which is also in the schema's limit description. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get national weekly Unemployment Insurance (UI) initial and continued claims' – a specific verb, resource, and scope. It clearly differentiates from the sibling 'dol_ui_claims_state' by explicitly stating 'national'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Clear context is provided: it is a national indicator used to gauge labor market stress. However, it doesn't explicitly tell the agent to use the state-level sibling for state-level data, and no when-not-to-use guidance is given. The widespread sibling naming convention makes the alternative obvious, so a small deduction is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ecfr_searchA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds that results include sections with titles, parts, and context snippets, and explains the CFR is organized into 50 titles. This goes beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the action and outcome in the first sentence. The second sentence provides useful background about CFR organization without padding. Each sentence serves a purpose, and the overall length is appropriate for a search tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, so the description must convey return value. It states that matching sections with titles, parts, and snippets are returned. Pagination behavior is not described, but the schema covers page and limit parameters. Overall, adequate for a search tool with clear scope.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 meaning beyond what the schema already provides for query, page, and limit. It only mentions 'by keyword,' which aligns with the query parameter but doesn't enhance it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with a specific verb 'Search' and names the resource 'Code of Federal Regulations (CFR),' then states the output: matching regulation sections with titles, parts, and context snippets. This clearly distinguishes it from sibling tools like ecfr_title_structure and ecfr_section, which focus on structural retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context that this is a keyword-based search across all 50 CFR titles, implying use for topical queries. It does not explicitly name alternatives or exclusions, but the CFR organization background helps an agent understand scope. Lacks explicit when-not-to-use guidance, so not a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• epa_drinking_waterA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and description adds meaningful detail: explains the system type codes (CWS, NTNCWS, TNCWS) with examples, and indicates the tool returns population served and source type. This is valuable context beyond the annotation, though it does not discuss response format 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is compact yet informative: a lead sentence stating the resource, three sentences listing return fields and system type definitions, and a final sentence suggesting cross-reference use. No wasted words; each sentence adds distinct value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 explains what data is returned (population, source type, system type) and defines enum-like values inline. It could mention pagination or the rows parameter default, but that is already in the schema. Overall sufficient for a moderately simple read-only tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers both parameters (state and rows) with descriptions and defaults, achieving 100% coverage. The tool description reiterates the 'by state' nature but adds no extra parameter-level syntax or behavior beyond what the schema already provides. Per guidance, baseline 3 applies when schema coverage is high.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Get' and resource 'Safe Drinking Water Information System (SDWIS) data by state', clearly distinguishing it from other EPA tools like epa_facilities or epa_toxic_releases. It also summarizes the returned data types (population served, source type, system type), leaving no ambiguity about scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: use when needing SDWIS drinking water data by state, and suggests cross-referencing with CDC and Census for per-capita analysis. It does not explicitly name alternatives or when not to use, but the purpose is specific enough to infer appropriate usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• epa_greenhouse_gasA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey readOnlyHint=true, so the description does not need to restate safety. It adds behavioral context by noting the tool returns 'large emitters' only and lists the data fields included, giving agents a better sense of output content beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences: the first states the primary action, the second clarifies data source and return fields, and the third offers a cross-referencing suggestion. Each sentence earns its place, and the most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 2-parameter tool with no output schema, the description covers purpose, data source, and typical return fields, making it functionally usable. The only minor omission is an explicit statement about response format or pagination behavior, but the `rows` parameter hints at limits, so the description is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both `state` and `rows` have descriptive texts. The description does not add any parameter-level details beyond what the schema provides, so it meets the baseline without enhancing parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get Greenhouse Gas (GHG) emissions data by state.' It further clarifies the data source (GHGRP), key fields returned, and differentiates from sibling EPA tools like epa_facilities and epa_toxic_releases by focusing on GHG emissions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use this tool (state-level GHG emissions data from GHGRP) and even suggests cross-referencing with EIA and BLS data. However, it does not explicitly name alternatives or provide exclusionary guidance ('use epa_facilities for facility details instead'), falling short of a full when/when-not statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• epa_superfundA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true in annotations, the safety profile is already clear. The description adds useful behavioral context by explaining the NPL status codes and mentioning cleanup progress, which helps interpret results. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficient and front-loaded: first sentence states purpose, second lists return fields, third explains NPL statuses, fourth suggests cross-referencing. Every sentence adds value with no wasted text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, so the description must convey what the tool returns. It covers site name, location, NPL status, cleanup progress, and explains status codes. It omits pagination/result structure details, but given the simplicity and the rows parameter, it is sufficiently complete for most use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with 'state' and 'rows' both well-described (state code format, default/max rows). The description does not add additional parameter semantics, but the schema fully covers parameter meaning, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves Superfund (CERCLA) contaminated sites by state, using a specific verb and resource. It distinguishes this tool from sibling EPA tools by focusing on Superfund sites specifically, and it lists the key data returned.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use this to get Superfund sites by state, with NPL status explanation. It does not explicitly mention alternatives or exclusions, but the scope is unambiguous and the cross-reference hint suggests complementary usage with other datasets.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• epa_toxic_releasesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, which tells the agent this is a safe read operation. The description adds helpful context about the regulatory basis (EPCRA Section 313) and common sectors, helping the agent understand the data domain. Lacking an output schema, it could have added more about return structure, but the read-only nature and added domain context are sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a clear one-line purpose, a brief regulatory context sentence, a useful list of common sectors, and a practical cross-reference note. Every sentence contributes meaning, with no fluff or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with only 3 parameters, the description provides sufficient context: purpose, data source, sector examples, and related tools. Without an output schema, more detail on return fields would help, but the description gives enough for an agent to understand the domain and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (rows, state, county) already explained in the input schema. The description mentions 'by state' which reinforces the state parameter, but does not add new 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get Toxics Release Inventory (TRI) data by state', specifying both the resource and the scoping dimension. Mentions of specific sectors and cross-references with epa_facilities and epa_greenhouse_gas distinguish this tool from sibling environmental tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on what data is covered (chemical releases under EPCRA) and explicitly names alternative tools for complementary data (compliance status via epa_facilities, emissions via epa_greenhouse_gas), providing when-to-use guidance. However, it does not explicitly state exclusions like 'not for facility-level compliance' or mention when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ercot_pricesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true in annotations, the read-only safety is already known. The description adds domain context and common settlement point examples, which is helpful. However, the claim of 'real-time' seems at odds with the delivery_date_from/to parameters in the schema, implying historical data is also available—this is a slight behavioral inconsistency. No additional details on pagination, default scope, or return format are provided beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short paragraphs: one high-definition sentence about what the tool does, and one compact list of common settlement points. Every sentence earns its place, no filler, and the most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple read-only query tool with full schema coverage and no output schema, the description provides adequate context. It explains the domain, gives example parameters, and the annotations confirm safety. The main gap is not describing what the returned data looks like (since there's no output schema) and not clarifying the historical/real-time tension, but these are minor for a tool like this.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all five parameters are already documented. The description adds value by enumerating common settlement point values, directly supplementing the settlement_point parameter. It also clarifies the geographic scope (Texas) and data type (wholesale electricity prices). Minor point: 'real-time' could confuse the default-date behavior, but that's a description trait, not a param semantic.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get Texas (ERCOT) settlement point prices' with a specific verb and resource, and further defines the domain as 'real-time wholesale electricity prices at specific nodes, zones, or hubs.' This distinguishes it from sibling tools like ercot_grid_conditions, and gives concrete examples of settlement points (HB_HOUSTON, HB_NORTH, etc.), removing ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: this tool is for Texas ERCOT settlement point prices. It doesn't explicitly name alternatives or exclusions, but the domain-specific examples and the resource type make it evident when to use it. The gap is lack of explicit comparison to similar tools (e.g., ercot_grid_conditions), so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• faa_sigmetA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that it returns hazard advisories (turbulence, icing, convection, volcanic ash) and coverage scope, but does not disclose response format, pagination, or potential lack of output structure. This is consistent with the baseline for tools with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each contributing distinct information: definition, returned hazard types, and scope. No redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, so the description makes an effort to explain return content (hazardous weather advisories including types) and coverage. However, it does not convey the structure or fields of the returned advisories, which would be helpful for an agent to consume the response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema covers everything vacuously. The description implies no input is needed, which aligns with the empty schema, earning the baseline 4 for no-parameter tools.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Get active SIGMETs' with a specific verb and resource, expands the acronym, lists covered hazard types, and specifies national airspace coverage. This clearly distinguishes it from sibling tools like faa_metar and faa_taf.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context about when to use the tool (when active SIGMETs are needed, across national airspace) but does not explicitly contrast with alternatives such as nws_aviation_sigmets or state 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.

• fbi_agenciesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, so safety is covered. The description adds behavioral detail by noting the grouping by county and the included fields (ORI codes, coordinates, NIBRS participation dates). It does not mention pagination or error handling, but for a simple one-parameter list tool, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose and followed by return details and usage guidance. Every sentence contributes value without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description explains the return value concisely (grouped by county with specific fields) and how to chain the results into other FBI tools. It does not detail every possible edge case or formatting nuance, but it is complete enough for a single-parameter list tool with strong annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of the parameters, including the 'state' description with examples. The tool description does not add extra meaning beyond what the schema provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the action ('List'), the resource ('law enforcement agencies in a U.S. state'), and the source ('FBI CDE'). It also enumerates the returned data (grouped by county, ORI codes, coordinates, NIBRS participation dates), distinguishing it from sibling FBI tools that focus on crime statistics or employee data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: to obtain ORI codes for querying agency-level data in other FBI tools. It does not explicitly name alternatives or state when not to use it, but the guidance is sufficient for an agent to select this tool for enumeration tasks.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fbi_arrest_dataA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description aligns by stating 'Get arrest statistics' without implying mutation. The description adds useful domain context: offense codes are numeric and includes specific examples, plus 'all' for all offenses. It also discloses that returns are 'counts or totals' broken down by year, age, sex, race, ethnicity, which is valuable behavioral context beyond the annotation. It doesn't cover pagination or rate limits, but for a read-only stats tool with a clear annotation, this is solid.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose, and efficiently packs offense code examples and output dimensions without redundancy. Every clause adds value; no filler or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (6 params, 48 offense enum values, levels: national/state/agency) and no output schema, the description provides a strong overview: data source, levels, offense codes, and returned breakdowns. It doesn't enumerate all 48 offense codes (schema covers that) but gives enough examples to make the tool usable. It lacks exit conditions like date-range default values, but the schema covers defaults, and the description is complete for an agent to invoke with confidence.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (all 6 parameters have descriptions), so the schema already documents each parameter thoroughly. The description adds a bit of meaning by explaining offense codes are numeric with examples and the 'all' option, which complements the schema's enum list. However, it doesn't add substantial info beyond the schema's own descriptions for parameters like from_year/to_year defaults, which the schema also covers. Baseline 3 is appropriate because schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets arrest statistics from the FBI at national, state, or agency level, with a specific verb ('Get arrest statistics') and resource ('FBI'). It names the three coverage levels and the output dimensions (counts/totals by year, age, sex, race, ethnicity), distinguishing it from sibling tools like fbi_crime_summarized and fbi_hate_crime.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (for arrest statistics at national/state/agency level) and hints at data granularity, but it doesn't explicitly explain when not to use it or name alternative tools like fbi_crime_summarized or fbi_nibrs. The context is clear enough for an agent to select this tool for arrest-specific data, but it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fbi_use_of_forceA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds meaningful context about the incident criteria (death, serious injury, firearm discharge) and the two data levels. It does not cover response format or pagination, but with the annotation present, the additional behavioral context is adequate for a 4.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each contributing essential information: purpose, data coverage, and scope usage. It is concise, well-ordered, and free of filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a moderate 3-parameter tool with comprehensive schema descriptions and a readOnlyHint, the description effectively fills in the data domain and scope selection details. It does not describe the return shape, but given the absence of an output schema and the simplicity of the query, this is not a critical gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 repeats the scope guidance already present in the schema without adding new semantic details for year or quarter. No extra value is provided beyond what the structured schema documents.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get Use of Force data from the FBI' and defines the specific data coverage (incidents resulting in death, serious injury, or firearm discharge). It naturally distinguishes itself from other FBI tools by focusing on the unique Use of Force dataset and the federal vs national scope levels.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit instructions for choosing scope values: 'Use scope=\'federal\' for federal agencies, \'national\' for all agencies participation data.' This gives clear context for when to use each parameter, but it does not mention alternative tools or conditions for not using this tool, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_device_eventsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals the safe read-only nature, lowering the bar. The description adds the MAUDE domain context and example fields, but does not disclose additional behaviors like response format, pagination, or rate limits. This is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: a single purpose statement followed by two clearly formatted example queries. Every sentence earns its place, and there is no redundant filler. This is an appropriately sized description for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has only two well-documented parameters and a readOnly annotation, making it relatively simple. The description explains the MAUDE data source and provides field-specific examples. It does not mention the return format, which is a minor gap given there is no output schema, but the description is otherwise complete enough for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides thorough descriptions for both parameters (limit and search), so the baseline is 3. The description adds domain-specific example fields (device.generic_name, event_type) that are not in the schema, giving the agent concrete, relevant usage for this FDA dataset, which goes beyond the generic schema examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Search FDA medical device adverse event reports (MAUDE)' and enumerates the report types (injuries, malfunctions, deaths). It distinguishes this from sibling tools like fda_device_recalls or fda_drug_events by specifying the exact resource and scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for use—searching MAUDE adverse event reports—with two relevant example queries demonstrating how to search by device and event type. However, it does not explicitly mention when not to use this tool or name alternative tools, so it falls short of full differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_device_recallsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so safety is covered. The description adds context about the RES system and offers field examples, but does not disclose return format, pagination, or rate limits; however, for a simple search tool this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is brief, front-loaded with purpose, and uses examples efficiently. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides enough context to use the tool: dataset, query examples, and limit behavior in schema. It could mention return fields or default sorting, but is complete enough for a simple search tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters have descriptions in the schema (100% coverage), and the description adds domain-specific examples (pacemaker, software) that illustrate the search syntax. This augmentation helps the agent formulate correct queries beyond the generic OpenFDA examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Search FDA medical device recall reports (RES system)' with a specific verb and resource. It further specifies searchable dimensions (name, manufacturer, reason) and distinguishes from sibling tools like fda_device_events by focusing on recalls.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear search contexts via example queries (e.g., 'openfda.device_name:"pacemaker"') and identifies fields for recall searches. It does not explicitly mention when not to use this tool or point to alternatives such as fda_device_enforcement, but the domain and examples make usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_device_registrationsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety level is known. The description adds useful behavioral details like example query syntax and a count field, but it does not describe the response format, pagination, or any other operational traits. It neither contradicts nor deeply enriches the behavioral picture beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: the opening sentence states the core purpose, followed by a brief explanatory line, then illustrative examples, and a final note on count fields. Every sentence earns its place without unnecessary verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter search tool with no output schema, the description provides a solid overview, query examples, and data scope. It doesn't outline the exact result fields, but the statement about 'which devices are made at each establishment' implies the nature of the response. Overall, it is complete enough for an agent to select and use the tool effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes both parameters at 100% coverage; the description goes further by showing concrete search syntax for the 'search' parameter with FDA-specific fields (e.g., 'products.product_code:HQY'). It also notes a count field, giving practical meaning beyond the basic schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a search over 'medical device establishment registrations & listings' and explains the data's meaning ('Where devices are manufactured and which devices are made at each establishment'). This specific verb-resource pairing and the outline of the data distinguish it from sibling FDA tools like fda_device_events or fda_device_recalls.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for use by indicating the subject matter and includes concrete query examples (e.g., by product code or regulation number). However, it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions for other FDA queries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_device_udiA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so safety is covered. The description adds valuable behavioral context beyond annotations, such as booleans being stored as strings ('true'/'false') and the format of example queries. This helps avoid common errors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, front-loaded with purpose, and every sentence serves a purpose. The example searches are structured and relevant, and the count fields summary is useful without being verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only search tool with no output schema, the description covers record content, query examples, and field naming quirks. It lacks details on response structure or pagination, but the limit parameter is documented in the schema, making this reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for both parameters, but the description enriches the search parameter with concrete field examples (brand_name, is_rx, mri_safety) and count field examples. This goes beyond the generic schema description and provides actionable query syntax.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as searching the Global Unique Device Identification Database (GUDID) and lists the types of records returned (description, MRI safety, product codes, sterilization). This specific verb-resource pairing distinguishes it from sibling FDA tools like fda_device_510k and fda_device_recalls.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides example searches that imply how to use the tool, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. No sibling tools are referenced for comparison, leaving usage context mostly implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_drug_countsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds domain context (adverse events) and reinforces the aggregation behavior, but does not disclose additional behaviors like default limits, sorting, or pagination. It does not contradict the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficient: a one-sentence core purpose, a one-sentence alternative pointer, and a focused bullet list of common fields. Every sentence adds value, and the list uses compact, consistent formatting.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only aggregation tool, the description is well-rounded. It covers scope, key parameters with examples, and an explicit alternative. The absence of an output schema is mitigated by the clear 'count' semantics and the provided field examples. Minor gap: no mention of result ordering or default limit, but the schema carries the limit default.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, providing baseline 3. The description adds concrete example values for count_field (e.g., 'patient.reaction.reactionmeddrapt.exact') and search syntax, which are valuable beyond the schema's generic descriptions. This enriches parameter semantics enough to warrant a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Aggregate/count FDA drug adverse event data by any field.' It uses a specific verb ('aggregate/count') and identifies the resource ('FDA drug adverse event data'). It also distinguishes itself from siblings by explicitly naming fda_count as the alternative for other endpoints.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit 'when not to use' guidance by stating 'For counting other endpoints, use fda_count instead.' It also lists common count fields, which implies typical use cases. However, it does not explicitly contrast with fda_drug_events (raw event retrieval), leaving some ambiguity about when to choose counts over raw data.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_drug_recallsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds example query fields but does not disclose pagination behavior or result structure. Since annotations cover the safety profile and the schema covers limit, this is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One-sentence description plus three concise bullet examples. No filler, all information is actionable and front-loaded with the verb. Each example earns its place by demonstrating a different search dimension.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the readOnlyHint annotation and detailed schema for both parameters, the description provides sufficient context for an agent to select and invoke the tool. It lacks an output schema or mention of result fields, but for a straightforward search tool this is not a critical gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover both parameters thoroughly (search syntax and limit constraints). The description adds concrete field names (classification, recalling_firm, reason_for_recall) not present in the schema, giving extra semantic meaning beyond the generic OpenFDA query syntax.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Search' with a clear resource ('FDA drug recall enforcement reports') and states the key capabilities: finding by classification, company, or reason. This distinguishes it from sibling tools like fda_food_recalls or fda_drug_events by naming the exact report type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides concrete example searches for common use cases (Class I, company, reason), which clearly imply when to use this tool. However, it does not explicitly exclude alternatives or mention when not to use it, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_food_adverse_eventsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful context (CAERS database, example query fields) but doesn't disclose additional behavioral traits like pagination, rate limits, or result format. Beyond the annotation, it offers modest added transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: one intro sentence, two useful example searches, and a count-fields note. Every sentence earns its place with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 2-param read-only search without an output schema, the description covers the database, content type, example queries, and count fields. It doesn't describe the response format, but the examples and context are sufficient for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed search syntax and limit description. The description adds value by giving tool-specific example queries and mentioning count fields (reactions.exact, outcomes.exact), which helps the agent construct valid queries beyond the generic schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search FDA food adverse event reports (CAERS database)' with a specific verb and resource. It further specifies the content (illnesses, allergic reactions, injuries) and distinguishes from sibling tools like fda_animal_events or fda_drug_events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context on what the tool covers (foods and dietary supplements) and includes concrete example searches with field values (e.g., 'products.industry_name:"Dietary Supplements"'). It doesn't explicitly name alternatives, but the examples and scope make the intended usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_food_recallsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint: true, so the safety profile is already known. The description adds domain context by explaining the severity classes and provides query examples, but does not disclose additional behavioral traits such as pagination limits, rate limits, or result structure. This is similar to the mid-tier example where annotations cover the core and description adds modest extras.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the main purpose. Every sentence serves a purpose: defining the tool, explaining classification levels, and offering immediately actionable examples. There is no redundancy or fluff, making it highly efficient for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with two parameters and no output schema, the description covers the core usage well. It explains the classification system and gives example queries, which is sufficient for basic invocation. However, it does not mention how results are returned or note any limitations, leaving a small gap for a complete picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both 'search' and 'limit' having descriptions. The tool description adds value beyond the schema by providing concrete field examples (classification, recalling_firm, reason_for_recall) that are not listed in the generic schema description for the search parameter. This enriches the agent's understanding of how to construct queries.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches FDA food recall enforcement reports, using a specific verb ('Search') and resource ('FDA food recall enforcement reports'). It also defines recall classification levels (Class I, II, III) and provides example queries that reinforce the scope, distinguishing it from other FDA recall tools like fda_drug_recalls.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for use through example searches (e.g., by classification, firm, reason), but does not explicitly mention alternatives like fda_drug_recalls or fda_device_recalls. It implies the food-specific scope via the name and title, but lacks an explicit when-not-to-use statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fdic_depositsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation. The description adds useful context on data source (annual survey, June 30) and branch-level scope, which goes beyond the annotation's minimal safety signal. No mention of pagination internals, but that is not critical given the read-only nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four short, focused sentences. Each sentence adds distinct value: what it returns, data source, filtering ability, and use cases. No redundant or fill language.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only dataset query, the description conveys the nature of the data (branch deposits), relevant filters, and likely use cases. No output schema exists, but the description mentions 'deposit amounts at each bank branch,' which suffices for basic understanding. Minor gaps include pagination defaults, but those are already covered in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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. The description's 'Filter by state or institution' merely paraphrases the schema's filter examples and adds no new meaning. Baseline 3 is appropriate when schemas carry the parameter documentation burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get Summary of Deposits' with branch-level deposit data from an annual survey, showing deposit amounts per branch. It distinguishes itself from FDIC sibling tools (e.g., fdic_search_institutions, fdic_financials) by emphasizing branch-level granularity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: 'Useful for market share analysis and banking access by geography.' It also states filters by state or institution. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fdic_financialsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include readOnlyHint=true, so safety is covered. The description adds valuable context beyond that: data frequency (quarterly), unit of measurement (thousands), and the specific financial fields included. This is meaningful behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with no waste. The first sentence states the main purpose and data source; the second adds filtering options and units. Front-loaded and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only filtered data tool with a well-documented schema, the description covers the essential aspects: data type, included fields, filtering, and units. It does not describe pagination or defaults, but those are available in the schema, and no output schema exists to explain return values.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already explained in the schema. The description repeats the filtering concept (CERT or STALP) but does not add new meaning beyond what the schema provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states it retrieves quarterly Call Report financial data for FDIC-insured banks, listing specific data points (assets, deposits, net income, ROA, ROE, loan loss reserves). This distinguishes it from sibling tools like fdic_history or fdic_failures, which focus on other aspects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear usage context by explaining the data source (quarterly Call Reports), included metrics, and how to filter by CERT number or STALP. It does not explicitly name alternatives or exclusions, but the context is sufficient for selecting this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fdic_historyA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already signals this is a safe read operation. The description adds clarity about the nature of the data (merger/acquisition/name change events) and the primary filtering method. No behavioral contradictions exist, though it doesn't disclose rate limits or return format, which is acceptable given the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the main action, no filler. Each sentence contributes: the first defines the scope, the second provides a concrete use case.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list endpoint with full schema descriptions and annotations, this description is adequate. It explains the tool's primary purpose and usage pattern. However, since there is no output schema, it doesn't describe the return structure, which would be helpful but not essential given the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive parameter names and examples. The description's mention of 'Filter by CERT number' mirrors the schema's example 'CERT:3511', so it adds little beyond what the schema already provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get institution event history' with specific event types (mergers, acquisitions, name changes, charter conversions), and distinguishes from sibling tools like fdic_search_institutions by focusing on history rather than current institution details. The verb 'Get' and resource 'institution event history' are specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use this tool: to trace a specific bank's history via CERT number. While it doesn't explicitly name alternative tools, the focus on event history inherently distinguishes it from institution search or failure-specific tools. This qualifies as clear context without explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fec_search_committeesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals safe read-only behavior. The description adds an example output and workflow context but does not disclose pagination semantics, match behavior, or return structure beyond the schema. It provides minimal extra behavioral context over the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no fluff: it states the core purpose, then delivers a high-value investigation tip with an example, and points to the next tool. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (6 params, no output schema), the description covers the main search axes and provides a concrete output example (C00034595). It also links to a downstream tool, making the workflow usable. It doesn't fully describe pagination or all return fields, but the example compensates.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All six parameters are fully described in the input schema, giving a baseline of 3. The description adds strategic value by showing how to combine 'name' and 'committee_type' ('Q') to find corporate PACs, and the concrete example ('Wells Fargo') clarifies intended usage beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches for political committees (PACs, campaign committees, party committees) by name, state, or type, using a specific verb and resource. It also distinguishes itself from candidate-focused FEC tools by emphasizing committees, and provides a concrete example.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly gives a recommended use case: combining committee_type='Q' with a company name to find corporate PAC IDs, and directs users to fec_committee_disbursements for the next step. While it doesn't explicitly state when not to use this tool, the example and downstream link offer strong context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fooddata_searchA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds valuable behavioral context: it covers 300K+ foods including branded products, explains the four data types with examples, and notes that results include 'basic nutrient info.' This goes beyond the annotation by detailing content scope and result type, though it doesn't cover pagination or error behaviors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded. The first sentence states the purpose and output. The second paragraph efficiently explains the key data type enum values. Every sentence adds information, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich schema (100% coverage, enums) and the read-only annotation, the description is nearly complete. It explains the tool's purpose, coverage, and data types. It doesn't explicitly describe pagination parameters, but the schema covers them, and the description's mention of 'basic nutrient info' hints at return content. The tool is well-suited for its role as a search endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are already well-described. The description adds meaningful context for the dataType parameter by explaining what each enum value (Foundation, SR Legacy, Branded, Survey) means, which is not fully captured in the schema's brief 'Filter by data type.' It also clarifies the broad coverage of the search, aiding interpretation of query results.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('Search the USDA FoodData Central database for foods by keyword') and resource (USDA FoodData Central database). It also specifies the output scope ('Returns matching foods with basic nutrient info') and mentions coverage (300K+ foods including branded products). This distinguishes it from sibling tools like fooddata_detail and fooddata_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this is for keyword-based searching of foods, covering multiple data types. However, it does not explicitly mention when to use this tool versus alternatives (e.g., fooddata_detail or fooddata_list), nor does it state any exclusions or preconditions. Usage is implied but alternatives are not addressed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ftc_hsr_noticesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes a safe read operation. The description adds behavioral context by stating that it 'Returns notices with transaction details and dates,' which goes beyond the annotation. It also indicates filtering behavior. No contradiction exists. It doesn't discuss pagination or rate limits, but given the annotation coverage, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four lines, front-loaded with the main purpose, followed by filtering options, return content, and a concrete example. Every sentence contributes value; there is no redundancy or fluff. It is compact and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only search tool with a well-described schema and annotations, the description covers the core aspects: domain, filters, return content, and an example. It does not describe pagination behavior, but the schema provides page/page_size parameters. Given no output schema, mentioning 'transaction details and dates' is sufficient. Overall, it is complete enough for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already described (e.g., 'Company or transaction title to search', 'Results per page'). The description restates the filter parameters and gives an example (title='Google'), but it doesn't add substantial semantic meaning beyond the schema. This aligns with the baseline 3 for high coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Search FTC Hart-Scott-Rodino (HSR) merger early termination notices.' It clearly states the domain (FTC HSR) and the object (merger early termination notices), distinguishing it from sibling tools like ftc_dnc_complaints. The filter hints ('by company title or transaction number') further clarify scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when searching FTC HSR merger early termination notices. It specifies common filter criteria (company title or transaction number) and provides an example. However, it doesn't explicitly mention alternatives or exclusion cases, so it stops short of full guideline clarity. Still, the contextual domain is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fws_speciesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, so safety is covered. The description adds useful domain context (status code meanings and taxonomic groups) but does not disclose pagination, default behavior with no filters, or result format. Adequate but not rich beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences: purpose, filter options, and domain explanations. Every sentence contributes unique information, and it is front-loaded with the main action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers purpose, filters, and domain vocabulary adequately. Could mention the existence of fws_species_detail for follow-up details or the default limit behavior, but for a search tool with five optional parameters, it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters, but the description adds value by expanding the status codes (E, T, C, PE, PT) and providing taxonomic group examples, which are only tersely mentioned in the schema. Enhances understanding beyond parameter names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Search threatened and endangered species from the US Fish & Wildlife Service.' The verb 'search' and resource are specific, and it distinguishes from sibling fws_species_detail by focusing on the search/list capability.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context on how to use the tool via filterable dimensions (name, status, state, group), but does not explicitly mention alternatives like fws_species_detail for detailed records. Lacks exclusions but gives enough context for typical use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hmda_nationwide_aggregationsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, so the description doesn't need to reiterate safety. It adds useful context about aggregation and filtering, but does not disclose return format, pagination, or rate limits. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the main purpose, followed by scope and use case. Every sentence contributes without redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description conveys the nature of the result (aggregate statistics) and offers sufficient context for a read-only data retrieval tool. It lacks details on output structure and edge cases (e.g., empty years), but remains complete enough for typical use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds value by grouping filters into demographics, loan characteristics, and actions taken, and clarifies year as the required dimension. It does not go beyond the schema but enhances it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and identifies a concrete resource ('nationwide mortgage lending aggregation data from HMDA'). It explicitly scopes to 'the entire U.S.' and a given year, which differentiates it from sibling tools like hmda_filtered_aggregations and hmda_rate_spread.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies use for national-level mortgage trend analysis and fair lending patterns, and explicitly states nationwide scope. However, it does not mention alternatives or when not to use, such as pointing to hmda_filtered_aggregations for subnational queries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hud_list_metro_areasA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safe read nature. The description adds useful relationship context about CBSA codes as entity_id, but does not disclose the return shape, fields, or any other behavioral details beyond annotations. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no wasted words. The purpose is front-loaded and the second sentence adds genuinely useful cross-tool context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter reference/list tool with readOnly annotation, the description is adequate. It could mention the output format or fields, but the low complexity and annotation coverage make it sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Tool has zero parameters and schema description coverage is 100%, so the description need not document parameters. Baseline 4 applies for no-parameter tools.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'List' with resource 'metropolitan/CBSA areas', clearly distinguishing it from sibling HUD list tools for states and counties. Adding that CBSA codes can be used as entity_id in HUD tools further clarifies its role.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear usage context by explaining CBSA codes can be used as entity_id in HUD tools, implying when to use this tool for metro-level identifiers. It does not explicitly name alternatives or exclusions, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hud_list_statesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description is consistent with the readOnlyHint annotation and adds the practical detail that the codes are intended for reuse with other HUD tools. However, it does not describe the return format or whether non-state territories are included, and annotations already cover the read-only nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with no wasted words. The first sentence front-loads the core action and resource, and the second provides a clear usage directive.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only reference tool, the description adequately conveys what is returned (states and HUD codes) and why it matters. It could optionally mention the exact code format or scope, but the tool is simple and the description is sufficient for basic use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has no parameters, so the baseline is 4. The description adds value by explaining the meaning of the output (state names and HUD state codes), which is more relevant here than parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the action ('List') and the resource ('all U.S. states with their HUD state codes'). It distinguishes this tool from sibling HUD list tools like hud_list_counties and hud_list_metro_areas by focusing specifically on states.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use the tool: to obtain HUD state codes for use with other HUD tools. It does not name alternative tools or give exclusions, but for a simple reference list this is sufficient context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mbta_predictionsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds context beyond the readOnlyHint annotation by specifying that it returns arrival and departure times and covers specific transit modes. No behavioral surprises are disclosed, but the description is transparent about the tool's scope and output nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loaded with the main action and resource. Every sentence provides essential information without redundancy, making it well-structured and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description sufficiently explains the tool's purpose and return values for a simple read-only query tool with optional parameters. It is complete enough given the schema coverage, though it could benefit from noting what happens when no filters are provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents all parameters with examples, achieving 100% coverage. The description only restates the filtering capability without adding significant new meaning beyond the schema, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides real-time arrival/departure predictions for MBTA transit, using a specific verb 'Get' and a specific resource. It also distinguishes itself from sibling tools like mbta_vehicles and mbta_alerts by focusing on predictions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains how to filter by stop and/or route, giving clear usage context. It does not explicitly mention alternatives or exclusions, but the coverage of transit modes and the mention of filtering serve as sufficient guidance for a simple query tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_traffic_camerasA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context about return contents (IDs, locations, image URLs) but does not disclose potential behaviors like data freshness, pagination, or image accessibility.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core action and resource, followed by return value details. No redundant or extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, simple listing tool, the description adequately covers what it does and what it returns. Slight gap: 'locations' is ambiguous (coordinates vs. descriptive location), and no mention of whether all cameras are returned or if any limits apply.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific detail, but none is needed since the schema trivially covers everything.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Get' and resource 'traffic camera locations across Maryland highways', clearly stating what the tool returns (camera IDs, locations, image URLs). It distinguishes from siblings like md_traffic_incidents and md_traffic_speeds by focusing on cameras and visual monitoring.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  States the purpose of real-time visual monitoring, providing contextual use. Does not explicitly mention when not to use or name alternative tools, but the scope is clear enough among the Maryland traffic sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_traffic_closuresA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context about content (planned and emergency closures with start/end times) but doesn't disclose additional behaviors like data freshness, pagination, or response details. This is adequate but not exceptional.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the main purpose. The second sentence adds valuable detail about the content without redundancy. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description is reasonably complete: it states what is returned (closures), scope (Maryland highways), types (planned/emergency), and includes start/end times. It could mention return format or update frequency, but these are not essential given the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema is fully self-contained (100% coverage). The description doesn't need to add parameter details. Baseline for 0 params is 4, and the description correctly focuses on the tool's output rather than input.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('active road closures on Maryland highways'), clearly distinguishing it from sibling tools like md_traffic_incidents and md_traffic_cameras. It identifies the exact geographic scope (Maryland) and the type of data (closures).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by its clear resource focus—active closures vs. incidents. It doesn't explicitly mention alternatives or exclusions, but the Maryland-specific wording and tool name provide sufficient contextual guidance. A brief note about when to use this over md_traffic_incidents would elevate it further.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_traffic_weatherA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already conveys that this is a safe read operation, so the description does not need to repeat that. The description adds value by detailing the specific meteorological fields returned and their relevance to winter weather. However, it does not disclose potential limitations such as whether data is current-only, historical, or geographically scoped beyond the Maryland context implied by the tool name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loaded with the primary action and resource (Get road weather data from RWIS stations), followed by a list of included data types and a use-case statement. Every sentence earns its place, and there is no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description provides a solid overview of content and purpose. It lists the key data dimensions and explains why the data matters. It lacks explicit details about return structure, units, or temporal scope, but given the low complexity and no parameters, the description is sufficiently complete for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and schema description coverage is 100% (trivially, since there are no properties). The description adds no parameter-level details because none exist, which is appropriate. Per the baseline for 0 params, a score of 4 is reasonable since there is no parameter documentation burden to satisfy.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving road weather data from RWIS stations, with a specific list of included measurements (air/surface temperature, humidity, wind, precipitation, visibility). This distinguishes it from sibling tools like md_traffic_incidents, md_traffic_cameras, and md_traffic_speeds, which focus on incidents, camera feeds, and speed data respectively.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by noting the data is 'Critical for winter weather road condition assessment,' implying when to use this tool. It does not explicitly exclude alternatives, but the domain (RWIS road weather) is distinct from traffic incident or speed tools, making the intended use clear enough. No explicit exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mn_lake_detailA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds meaningful detail about the data categories returned (fish species, surveys, water quality, depth, consumption guidance). This goes beyond the annotation without contradicting it, though it does not describe pagination or error behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, no filler. The purpose, included content, and how to find the ID are all conveyed efficiently. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With one parameter, no output schema, and read-only annotations, the description sufficiently explains what the tool returns and how to use it. It could mention not-found behavior or response format, but the included data categories make it complete enough for normal use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with the 'id' parameter already documented as 'Lake ID (DOW number) from search results (e.g. '21005700')'. The description reinforces the source of the ID by pointing to search and nearby tools, but adds no new parameter-level information beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'Get full details for a Minnesota lake by ID,' clearly identifying the specific verb, resource, and scope. It also distinguishes this from sibling tools by noting that mn_lake_search and mn_lake_nearby are for finding lake IDs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says to use mn_lake_search or mn_lake_nearby to find lake IDs, providing concrete guidance on how to obtain the required parameter. It does not state exclusions or alternative detail tools, but for a simple detail endpoint this is sufficient context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mn_lake_nearbyA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, indicating safe read-only operation. The description adds behavioral details about the radius parameter (miles, default 5) and states that results are lakes within the radius. No contradictions with annotations; the only omission is what fields the returned lakes include, but this is not critical given the read-only nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose and immediately followed by the return behavior and radius parameter. Every word earns its place; no fluff or repetition exists.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 3-parameter tool with complete schema documentation and a readOnlyHint annotation, the description adequately covers the essential behavior: what it does, what it takes, and what it returns (lakes within radius). It does not mention the output format (e.g., lake names/IDs) but this is minor given the low complexity and annotation coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers 100% of parameters with descriptions (lat, lon, radius). The description merely reiterates the radius unit (miles) and default (5), which the schema already specifies. No additional semantic meaning is provided beyond the structured schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Find') and resource ('Minnesota lakes') with an explicit proximity qualifier ('near a latitude/longitude point'). This clearly distinguishes it from sibling tools like mn_lake_search (by name) and mn_lake_detail (by detail retrieval), making the tool's function unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states the intended use case: finding lakes near a point, with an adjustable radius in miles. While it doesn't explicitly mention alternatives or exclusions (e.g., when to use mn_lake_search instead), the proximity focus and sibling names provide strong contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• naep_compare_statesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already establishes the tool's safe, non-destructive nature. The description adds behavioral context by explaining that it performs significance testing and 'shows which states score significantly higher or lower than others,' giving the agent an idea of the output type. This goes beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: two sentences plus an example. It is front-loaded with the core action ('Compare NAEP scores across states/jurisdictions with significance testing') and each sentence adds essential detail (significance testing, output behavior, and a concrete example). No unnecessary words or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description gives a high-level indication of the return value ('Shows which states score significantly higher or lower than others'), which is sufficient for a read-only comparison tool. The schema covers parameter constraints comprehensively. However, it does not detail the output format or any limitations, but given the simplicity of the tool and the presence of good schema annotations, the description is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides detailed descriptions for all 5 parameters (year, grade, subject, variable, jurisdictions) with 100% coverage. The description's example implies parameter usage (e.g., Massachusetts and Mississippi as jurisdictions, reading as subject) but does not add new semantic information beyond what the schema already specifies. The baseline of 3 applies because the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Compare NAEP scores across states/jurisdictions with significance testing.' It specifies the resource (NAEP scores), the action (compare), and a distinguishing feature (significance testing). The example 'Compare Massachusetts vs Mississippi reading scores' makes the purpose concrete and unambiguous, and it differentiates this tool from siblings like naep_compare_years or naep_compare_groups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for use: comparing NAEP scores across states with significance testing, and the example illustrates a specific scenario. However, it does not explicitly mention alternatives or when not to use this tool. Since there are sibling tools with similar names, the lack of explicit exclusions is a slight gap, but the phrase 'across states/jurisdictions' offers sufficient implied guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• naep_compare_yearsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotation: it explicitly states that the tool performs significance testing and reports whether changes are statistically significant, which is a non-obvious output behavior. This adds value without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, each earning its place: the first states the core purpose, the second clarifies the significance-testing behavior, and the third offers a concrete use case. It is front-loaded and free of redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity, no output schema, and the richness of sibling tools, the description adequately covers the tool's purpose, key feature (significance testing), and a practical use case. It does not enumerate return fields, but the absence of an output schema makes some output ambiguity acceptable. It is sufficiently complete for an AI agent to select this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all five parameters, including format examples and valid values. The description does not add parameter-level detail beyond the schema, and the mention of 'years' in the description merely restates what the schema already documents. Baseline 3 applies because the schema carries the load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb ('Compare') and resource ('NAEP scores across assessment years'), and further clarifies the unique value proposition: significance testing of score changes. This clearly distinguishes the tool from siblings like naep_compare_states and naep_compare_groups, which focus on other comparison dimensions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear contextual guidance by noting it's 'Great for tracking the COVID learning loss and recovery,' implying when year-over-year comparisons are relevant. However, it does not explicitly state when to avoid this tool in favor of state or group comparison tools, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• naep_gap_variable_jurisdictionA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint, and the description goes beyond by explaining the output fields (innerdiff1, innerdiff2, and the gap between them). This adds useful behavioral context about what the tool returns.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, no filler, front-loaded with the main purpose and an illustrative example. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the straightforward read-only nature, 5 parameters with full schema descriptions, and the description's explanation of return values, the tool is well covered. Minor omissions like edge-case behavior do not detract significantly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All parameters are described in the schema with 100% coverage. The description adds an example of how subject and variable map to real-world use, but does not materially deepen parameter understanding beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool compares achievement gaps across states, with an example ('poverty gap in math bigger in Mississippi than Massachusetts?'). It distinguishes itself from sibling NAEP tools by emphasizing gap comparisons between jurisdictions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context for when to use the tool: comparing how achievement gaps differ across states. Gives a concrete example, but does not explicitly state when not to use or name alternative tools, so it stops short of full exclusionary guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nara_recordA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already communicates the read-only nature. The description adds behavioral context by stating what the response contains ('complete metadata, descriptions, creators, and links to digitized content when available'), which is useful beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with the key verb and resource up front. No filler or redundant wording; every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read tool with no output schema, the description adequately covers return values and the conditional nature of digitized links. It doesn't mention error behavior, but that is a minor gap for such a straightforward fetch operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema description already explains 'NARA record ID (from search results)'. The description repeats the parameter name without adding new semantic detail, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get full details') and a specific resource ('National Archives record') with a clear scope ('by NARA ID'). It unambiguously distinguishes itself from the sibling 'nara_search' tool, which is the search counterpart.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies the usage context: you need a specific NARA ID to fetch details. It doesn't explicitly mention 'use after nara_search' or list exclusions, but the context is clear enough for an agent to infer when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nasa_image_assetA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description supplements the readOnlyHint annotation by specifying the exact output (all rendition URLs with the five size categories). It does not disclose edge cases like missing renditions or rate limits, but for a simple read operation the annotation plus this output detail are adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short, front-loaded sentences convey the tool's purpose and prerequisite without unnecessary detail. Every clause adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read tool with no output schema, the description is concise and complete: it states what is returned, what input is needed, and where to obtain the input. It could mention error behavior if the nasa_id is invalid, but that is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the nasa_id parameter with a descriptive example. The description adds the source hint 'from search results,' which is useful but not essential, so it meets the baseline for 100% schema coverage without adding significant new meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: retrieving all rendition URLs (original, large, medium, small, thumbnail) for a NASA media asset. This specific verb-object pairing and enumeration of output distinguish it from sibling tools like nasa_image_search or nasa_image_metadata.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear prerequisite and usage directive: 'Use a nasa_id from search results.' This tells the agent when to call this tool, but it does not explicitly list when not to use it or name alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nasa_image_metadataA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, establishing it as a safe read operation. The description adds behavior beyond annotations by stating the return value is a URL to a JSON file, giving key context about the response. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 15 words, front-loaded with the verb 'Get', and contains no extraneous information. It is concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description clearly states that the tool returns a URL to a metadata JSON file, which is sufficient for a single-parameter, read-only tool. It fully conveys the purpose and output type, so it is complete for the task at hand.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (nasa_id described as 'NASA media ID'). The tool description does not add additional meaning beyond the schema, but the schema already fully documents the parameter, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('URL to the full EXIF/XMP/IPTC metadata JSON file') and clearly distinguishes this from sibling tools like nasa_image_asset (asset retrieval) and nasa_image_captions (captions). It precisely states what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when a NASA media ID is known and full metadata is needed. It provides clear context but does not explicitly mention alternatives or exclusionary conditions compared to sibling tools. The specificity of 'full EXIF/XMP/IPTC metadata JSON file' makes the use case evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nasa_neoA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful behavioral context by listing what the tool returns (close approach data, estimated diameter, velocity, hazard assessment). It does not contradict annotations and provides value beyond the structured metadata.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the action, and every word adds value. No repetition or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only search tool with two optional parameters and no output schema, the description adequately covers the return fields and the query scope. It could be slightly more explicit about the response format or pagination, but given the tool's simplicity, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both start_date and end_date fully documented in the input schema. The description only mentions 'date range' generically and adds no additional parameter-specific semantics, so the schema carries the full burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Search'), names the resource ('Near-Earth Objects (asteroids/comets)'), and specifies the primary scope ('by date range'), distinguishing it from related tools like nasa_neo_detail. It clearly conveys what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies usage for searching NEOs by date range, but does not explicitly state when to use this tool over alternatives like nasa_neo_detail or jpl_close_approaches. Context is clear, but exclusions/alternatives are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nc_linc_queryA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals the safe read-only nature. The description adds the prerequisite workflow (use search first) and scope (specific NC LINC datasets) but does not elaborate on behavior like pagination, return formats, or how filters affect results. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a clear purpose statement, a directive for prerequisite usage, and practical examples. No superfluous words or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple query tool with read-only annotations and fully described parameters, the description covers purpose, workflow, and examples. It lacks explicit return format details, but since no output schema exists and the tool is straightforward, this is a minor gap. Overall, it is sufficient for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are well documented. The description adds value by listing common dataset ID examples, which assists the dataset_id parameter. This goes slightly beyond the schema's generic description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool queries a specific NC LINC dataset with optional filters, and explicitly distinguishes from the sibling nc_linc_search by directing users to search first. It also provides concrete examples of common dataset IDs, making its resource scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description instructs users to use nc_linc_search first to obtain dataset IDs, establishing the appropriate workflow. It does not explicitly state when not to use this tool versus alternatives, but the dataset-specific naming and examples clearly define its context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nc_linc_searchA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description adds that it searches all datasets and returns metadata. No contradictions. However, it does not disclose pagination behavior, rate limits, or other operational constraints beyond what annotations already convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences: main purpose, return value summary, and cross-reference to companion. Efficient, 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description lists the key return fields and links to the companion data-fetching tool. It covers the essential workflow for a simple search tool, though it omits minor details like default limit behavior (already in schema) and search semantics (e.g., exact vs partial match).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters (query and limit) already described. The description adds no additional parameter-level details, so it meets the baseline but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches across all NC LINC datasets by keyword, specifies the return fields (IDs, titles, descriptions, record counts), and distinguishes itself from the companion tool nc_linc_query by explaining the workflow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs the user to use the dataset ID from results with nc_linc_query to fetch actual data, providing a clear when-to-use and how-to-chain with the sibling tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhtsa_car_seat_stationsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true, the safety profile is already provided. The description adds useful behavioral context by explaining the alternative search modes and the role of the `miles` parameter in geo searches, which is beyond what annotations provide. It does not disclose potential edge cases, but this is acceptable given the tool's simplicity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured, with the purpose stated upfront, followed by search modes, context, and a useful example. Every sentence earns its place, 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only search tool with no output schema, the description provides adequate context: it explains the purpose, search options, and gives an example. It does not cover what happens with conflicting parameters or the default behavior when no parameters are provided, but these are minor gaps for such a tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with descriptions for all five parameters, so the baseline is 3. The description reinforces the alternative search modes but does not add substantial new meaning beyond the schema. The example is helpful but not essential.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Find car seat inspection stations near a location.' This is a specific verb-resource pair that uniquely identifies the tool and distinguishes it from sibling tools, as no other tool targets car seat inspection stations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by listing search methods ('by ZIP code, state, or geographic coordinates') and includes a concrete example. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to understand when to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhtsa_complaint_detailA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers safety, and the description adds no major behavioral traits beyond that. It does not contradict annotations, but also does not disclose return format, limitations, or other operational details. Meets the baseline with the added provenance about ODI numbers.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the action, and includes an example. Every word earns its place with no unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read tool with no output schema, the description is nearly complete. It specifies the identifier and how to obtain it. A minor gap is not explicitly describing the return payload, but the tool name and 'get a specific complaint' imply full complaint details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, but the description adds context on where the ODI number comes from (complaint search results) and provides an example. This helps the agent understand how to find the parameter value beyond the schema's format description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get a specific complaint by its ODI number', which is a specific verb+resource+identifier combination. It distinguishes from sibling tools like nhtsa_complaints (search) and nhtsa_recall_detail (different resource type).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It says ODI numbers are found in complaint search results, implying the workflow of searching first then getting the specific complaint. This is clear context but does not explicitly name alternatives or exclusions, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhtsa_safety_rating_detailA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the read-only nature is already known. The description adds useful context about what is returned – 'crash test ratings, rollover risk, and safety technology assessments' – which goes beyond the annotation. No contradictory or hidden behaviors are disclosed, but no extra caveats (e.g., data availability) 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise, front-loaded sentences: purpose, prerequisite, and return contents. No redundant phrasing or wasted words; every sentence adds information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only detail tool with one parameter and no output schema, the description adequately covers the return categories. It explains what the tool does and how to get the required ID, but could be slightly more specific about the format or level of detail (e.g., how ratings are presented), though not essential.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the parameter description already states 'VehicleId from safety ratings search (e.g. 19950)'. The tool description repeats the same source ('Requires a VehicleId from nhtsa_safety_ratings search results') without adding new semantic detail, so it meets the baseline but does not elevate it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description opens with 'Get detailed NHTSA 5-star safety ratings for a specific vehicle variant' – a specific verb, resource, and scope. It distinguishes from sibling nhtsa_safety_ratings by emphasizing 'detailed' and 'specific vehicle variant', and it names the prerequisite search tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states 'Requires a VehicleId from nhtsa_safety_ratings search results', establishing when to use this tool (after a search has returned a VehicleId). It does not explicitly exclude alternatives, but the prerequisite clearly points to the correct preceding workflow, making usage context unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nih_search_publicationsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so the read-only safety is covered. The description adds behavioral context by stating the search keys (PMIDs, application IDs, core project numbers) and what is returned (PMID and linked project number). It does not contradict annotations and adds value beyond the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, with three sentences each earning their place: the resource, the search identifiers, and the return value. It is front-loaded with the core purpose and contains no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with no output schema, the description sufficiently states the domain, the accepted identifier types, and the minimal return fields. It does not explain edge cases like combining multiple parameter types or the behavior when no parameters are provided, but the schema covers pagination parameters and the read-only annotation covers safety.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already described with type and examples. The description reinforces the meaning of pmids, appl_ids, and core_project_nums but does not add new syntax or format details beyond the schema. Baseline 3 applies because the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as searching for publications linked to NIH-funded projects, using a specific verb and resource. It further specifies search modes (PMIDs, application IDs, core project numbers) and the return value, distinguishing it from project-level tools like nih_search_projects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for use: it is for finding publications associated with NIH-funded projects, and it lists the three accepted identifier types. It does not explicitly mention alternatives or exclusions, but the intended usage is evident from the search modes and the phrase 'NIH-funded projects.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nps_campgroundsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already signals a safe read operation, so the description doesn't repeat that. It adds useful behavioral context by listing the return fields (names, descriptions, reservation info, site counts, coordinates) and the supported filter dimensions. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short, information-dense sentences. The purpose is front-loaded, followed by return fields and filter options. Every sentence earns its place with zero fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of a search tool with four optional parameters, the description covers the core aspects: what is searched, what is returned, and how to filter. It lacks pagination or sorting details, but the limit parameter in the schema signals pagination, and the overall context is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema coverage is 100% with clear per-parameter descriptions (limit, query, state, park_code). The description mentions 'park code, state, or keyword' but doesn't add new semantic meaning beyond what the schema already provides. This is a baseline 3 since the schema carries the load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Search campgrounds in national parks.' It clearly distinguishes this tool from sibling NPS tools (nps_parks, nps_alerts, nps_events) and recreation.gov campground tools (rec_campsites) by focusing on NPS campgrounds, and it lists the specific data returned and available filters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: to search for campgrounds specifically within national parks, with filters by park code, state, or keyword. It doesn't explicitly mention alternatives or exclusions, but the scope is well-defined enough that an agent can infer when this is the appropriate tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nsf_awards_searchA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The read-only annotation already covers safety, and the description adds value by disclosing the return fields (award titles, PI names, institutions, funding amounts, dates), which is beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action, and contains no redundant information. It efficiently states purpose and typical return content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description appropriately lists the result fields. Combined with full parameter descriptions and the read-only annotation, the tool is adequately specified. A note on pagination (e.g., limit/offset) is absent but covered in the schema, so no major gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are well-documented in the schema. The description adds minimal extra meaning beyond grouping the search dimensions, which is already clear from parameter names and descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search NSF research awards by keyword, principal investigator, institution, or program' with a specific verb and resource. It also lists the output fields, distinguishing it from detail lookups like nsf_award_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool (when searching by keyword, PI, institution, program). It does not explicitly exclude alternatives or name sibling tools, but the intended use case is evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ntsb_aviation_accidentsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, which the description aligns with. Beyond that, it discloses specific return content (event details, injuries, aircraft info, probable cause, report status). This adds useful context about what the search yields, though it doesn't cover pagination or output format details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences front-load the purpose, followed by a brief returns list and three illustrative examples. No fluff—every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with three well-documented parameters and a readOnlyHint, the description covers the core purpose, search criteria, and return fields. It's slightly incomplete in that it doesn't explain pagination (limit/offset) or explicitly differentiate from the similar ntsb_query sibling, but these are minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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's examples ('Boeing 737 MAX', 'Cessna engine failure', 'helicopter New York') echo the schema's own examples and don't add new semantics beyond what's already in the parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search NTSB aviation accident investigation data' and 'Find accident reports', using a specific verb and resource. It differentiates from the broader ntsb_query sibling by explicitly narrowing to aviation accidents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on what to search (aircraft type, location, date, keywords) and provides concrete query examples. It doesn't explicitly mention when not to use this tool or name alternatives like ntsb_query, but the examples imply typical usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nws_observation_historyA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true already conveying safe read behavior, the description adds value by specifying that multiple observations are returned including temperature, wind, humidity, etc., and that date range filtering is available. This provides behavioral context beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the main action, and every sentence adds meaningful information without redundancy. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has four parameters and no output schema, the description covers the core purpose, return contents, and optional filtering. It omits details like default limit and relationships to sibling observation tools, but overall it is adequately complete for a simple data retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are fully documented (station_id, start, end, limit). The description mentions optional date range filtering and return contents but doesn't add new semantic 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' with a clear resource 'observation history from a weather station' and notes it returns multiple observations with weather fields. This distinguishes it from siblings like nws_observation_latest and nws_forecast, making the purpose immediately clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives context that this tool is for recent observation history with multiple observations and optional date range filtering, implying use when historical/current weather observation series are needed. It doesn't explicitly name alternatives or exclusions, but the context is sufficient for basic differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nws_observation_latestA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description does not need to restate safe-read behavior. It adds value by disclosing the exact returned measurements (temperature, wind, humidity, pressure, visibility, conditions) and the ICAO format for station IDs, which helps set data expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences each serve a distinct purpose: state the main function, list returned data fields, and clarify the parameter format. No filler or redundant phrasing—ideal conciseness for a simple tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only tool, the description is sufficient: it explains what the tool returns and how to specify the station. It correctly does not attempt to enumerate all possible output fields (no output schema needed). A small gap is that it does not mention how to discover station IDs (e.g., via nws_stations), but this is not essential for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage of the single parameter, including ICAO code examples. The description essentially repeats this information ('Station IDs are ICAO codes'), adding no new semantic detail beyond what the schema already communicates, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('latest weather observation from a station'), clearly distinguishing it from siblings like nws_observation_history (history) and nws_forecast (forecast). It also lists the returned fields, making the tool's function immediately obvious.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies clear use context: when you want the latest observation for a known station, as opposed to historical data or forecasts. However, it does not explicitly mention alternatives or exclusions, such as pointing to nws_observation_history for past observations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nws_zonesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds no extra behavioral details such as pagination, rate limits, or data volume, but for a simple read-only listing tool, the annotation covers the main safety concern.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, front-loaded with the core action. No wasted words; the filtering guidance directly follows the primary purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with three optional parameters and no output schema, the description sufficiently covers purpose and filtering. It does not describe the return format or default limit, but those are implied by the schema and the nature of the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing baseline 3. The description adds combination semantics ('and/or state') and enumerates the allowed zone types, which supplements the schema's individual field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('NWS forecast zones'), clearly distinguishing this from sibling tools like nws_forecast and nws_zone_forecast, which deal with forecast data rather than zone metadata. The filter options are mentioned, further clarifying scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states to use this to list zones and filter by type/state, giving clear context for its intended use. However, it does not explicitly name alternatives or when-not-to-use scenarios, so it stops short of the highest score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• oba_arrivalsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes a safe read operation. The description adds behavioral value by specifying that the tool returns predicted and scheduled times, route info, vehicle tracking, and distance from stop. This gives the agent a concrete sense of the response payload without needing an 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences with no filler. It front-loads the action (Get real-time predictions), then details return contents and coverage, with each sentence contributing useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only tool with a well-documented schema, the description is quite complete. It covers the purpose, geographic scope, agencies, and return contents. The only minor gap is the lack of explicit discussion of response structure or limitations, but that is not critical for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides a full description for stop_id, including an example format ('1_75403'), achieving 100% schema description coverage. The tool description does not add parameter-specific details, but the baseline score of 3 is appropriate because the schema handles the semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get real-time arrival and departure predictions' for a transit stop. It further distinguishes itself by explicitly scoping to 'Puget Sound (Seattle area)' and listing the covered agencies, which differentiates it from sibling transit tools like CTA, MARTA, and SEPTA. The return contents are also summarized.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by stating the geographic scope and transit agencies covered, making it evident when to use this tool. However, it does not explicitly mention alternatives or include 'when not to use' guidance, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ofac_filterA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers safety, and the description adds meaningful behavioral context by specifying 'substring match' and the requirement for at least one filter. However, it does not disclose what happens when no filter is provided, how multiple filters combine, or return format/pagination, so the additional transparency is limited.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two sentences, front-loaded with the primary action and resource, and contains no extraneous words. Every clause earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple filter with four optional parameters and no output schema, the description conveys the core purpose, filter dimensions, matching behavior, and a hard usage requirement. Minor gaps such as how multiple filters are combined (AND/OR) and what happens without any filter are not explicitly stated, but overall it is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all parameters at 100% coverage, so the baseline is 3. The description adds value beyond the schema by explaining that matching is substring-based, which applies to all filter parameters and is not evident from the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the action ('Filter'), the resource ('OFAC SDN list'), and the scope ('by program, entity type, or country'), which clearly distinguishes it from sibling tools like ofac_sdn_list. The 'substring match' note adds further precision.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies the tool is for filtering a subset of the SDN list, and the requirement 'At least one filter parameter should be provided' gives direct usage guidance. However, it does not explicitly contrast with siblings (e.g., when to use ofac_sdn_list instead), so it falls short of an explicit alternatives comparison.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• open_payments_by_physicianA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  ReadOnlyHint is already provided in annotations, so the description need not restate safety. It adds useful behavioral context by noting 'Pre-aggregated totals' and 'across all years,' which informs the agent that data is pre-summarized rather than raw records. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences deliver purpose, scope, and data nature without redundancy. Every word earns its place, making it easy to parse and understand quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple pre-aggregated list tool with one optional parameter and a read-only annotation, the description is largely complete. It lacks explicit return-field details (e.g., doctor name, NPI, total amount), but the phrase 'how much each doctor received from pharma overall' strongly implies a payment total, which may be sufficient given the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description covers 100% of the single parameter (limit: 'Number of physicians (default 20)'), so the baseline is 3. The description does not add any additional parameter 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get payments grouped by individual physician across all years.' It clearly states the aggregation dimension (by physician) and scope (all years), and is easily distinguished from sibling tools like by_company, by_hospital, or by_specialty.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: it returns per-physician total payments, implying it is appropriate when an agent needs doctor-level aggregated data. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• open_payments_researchA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No contradiction with the readOnlyHint annotation. The description adds value by clarifying the scope (research vs general) and disclosing output content (funding amounts, sponsors, principal investigators). It does not cover rate limits or pagination, but for a search tool with readOnlyHint, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences that front-load the purpose, add a key distinction, and describe output fields. There is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema fully documents parameters, and the description covers purpose, scope, and output content. The only minor gap is lack of explicit guidance for choosing among other open_payments sibling tools, but the research/general distinction handles most selection cases adequately.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All five parameters have descriptions in the schema, covering 100% of parameters. The tool description itself does not add parameter-specific guidance, so the baseline of 3 is appropriate given the schema's high coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Search' and the specific resource 'Open Payments RESEARCH payment data', and further clarifies the scope as 'grants, clinical research funding from pharma to doctors'. It explicitly differentiates from 'general payments', making the tool's purpose unambiguous even among many open_payments siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context that this tool is for research payments, separate from general payments, effectively telling the agent when not to use it. However, it does not explicitly name alternatives like open_payments_search or open_payments_by_company, so it lacks the explicit alternative references that would merit a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• open_payments_topA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so there is no contradiction. The description adds behavioral context by specifying 'sorted by amount descending' and noting it differs from 'basic search which returns results in default order', going beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with the main purpose, no filler or redundant information. Every sentence contributes to understanding or differentiation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with 6 optional params and readOnly annotation. Description covers purpose, use case, and sorting behavior, but lacks details on return format or pagination; however, given no output schema and clear intent, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters, so baseline 3 applies. The description references 'state or specialty' filters but does not add new semantic details beyond the schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states 'Find the HIGHEST pharma payments to doctors — sorted by amount descending', providing a specific verb, resource, and ordering. It also contrasts with 'basic search' which distinguishes it from sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Gives explicit use case: 'Use this to find the biggest consulting fees, royalties, and speaking fees in a state or specialty.' It also mentions the alternative 'basic search' for default order, offering clear context on when to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• open_payments_top_doctorsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, and the description adds valuable behavioral context beyond that: it aggregates all individual payments per doctor, groups by doctor, sums payments, and sorts by total descending. This clarifies the tool's computation approach, though it does not mention limits, pagination, or response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences: the first states the core purpose, the second explains the aggregation mechanism, and the third gives the practical use case. Every sentence earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 100% schema coverage and readOnly annotation, the description covers the essential behavior of aggregation and sorting. It doesn't specify the exact output structure, but for a list-returning read tool with well-documented optional filters, this is sufficient for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all 5 parameters with 100% coverage. The description does not add specific parameter-level meaning, but it does provide the overarching context that filters (state, company, specialty) feed into the per-doctor aggregation. This is baseline value, no significant enhancement.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose with a specific verb and resource: 'Find the HIGHEST-PAID doctors by TOTAL payments received'. It also distinguishes from sibling open payments tools by emphasizing the aggregation of all payments per doctor, making it the definitive tool for ranking doctors by total compensation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear use case: 'This is the key tool for finding doctors with the biggest pharma relationships.' However, it does not explicitly name alternative tools or state when NOT to use this tool, so it lacks full exclusionary guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openstates_bill_detailA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description aligns by using 'Get' and 'Returns'. It further discloses the return scope (sponsors, actions, votes, documents), which adds behavioral context beyond the annotation. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core purpose, and no filler. Every word contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter), annotations cover safety, and the description lists key return categories. Without an output schema, this is adequate for an agent to invoke and interpret results. Minor gaps like error handling are not critical here.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully documents the single parameter with an example and source hint. The description adds no new meaning beyond restating 'OpenStates ID', so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get full details') and names the exact resource ('specific state bill by OpenStates ID'). It clearly distinguishes from sibling tools like openstates_bills (likely a list/search tool) and openstates_legislators, and the return contents are enumerated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states the tool is for a specific bill when you already have an OpenStates ID, with an implicit prerequisite (retrieve ID from search results). It doesn't explicitly mention alternatives or when not to use it, but the context is clear enough for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openstates_billsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already assures a non-destructive read operation. The description adds value by disclosing what the response contains (bill identifiers, titles, sessions, sponsors) and that the search spans all state legislatures, which is not evident from annotations. It does not contradict annotations and provides behavioral context beyond the structured metadata.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences: the first states the main action, the second lists the primary filters, and the third states the return contents. Every sentence earns its place with no redundant or filler text. The key information is front-loaded in the first sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with 5 well-documented parameters, no required fields, and no output schema, the description is quite complete. It covers what the tool does, the main filter dimensions, and the return fields. It does not explain pagination or result limits, but those are captured in the schema. It also doesn't mention integration with the sibling 'openstates_bill_detail', but this is not essential for basic invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema describes all 5 parameters with 100% coverage, including examples for query ('climate'), session ('2023-2024'), and jurisdiction ('ca'). The description restates these filters ('state (jurisdiction)', 'keyword query', 'legislative session') but adds little beyond the schema. The only mild addition is connecting 'state' to 'jurisdiction' explicitly, but the schema already says 'State abbreviation lowercase'. Baseline of 3 is appropriate given the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description begins with a clear verb and resource: 'Search bills across all 50 state legislatures.' This specifies the scope (state-level, not federal) and distinguishes it from siblings like 'openstates_bill_detail' (single bill lookup) and 'congress_search_bills' (federal bills). The first sentence alone provides a precise, unambiguous purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool: searching state-level bills across all 50 legislatures. It lists the key filter dimensions (state/jurisdiction, keyword, session). It lacks explicit exclusions or named alternatives, but the scope of 'all 50 state legislatures' implicitly differentiates it from federal congressional bill search tools and from bill detail tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pubmed_relatedA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, so the safety of the operation is known. The description adds value by explaining the ranking methodology (NCBI's pre-computed similarity scores based on shared MeSH terms, co-citations, and content overlap), which goes beyond the basic annotation. It does not describe return format or error cases, but for a simple read-only tool this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each earning its place: the first states the core function, the second explains the underlying mechanism, and the third gives an application context. No repetition or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 is adequate. It explains purpose and methodology, and the schema covers parameters. However, it does not describe what the returned related articles look like or any potential failure modes (e.g., invalid PMID), which is a minor gap 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% description coverage for both parameters (pmid and max_results), including types, constraints, and defaults. The description only mentions 'given PMID' without adding new parameter semantics. Baseline 3 is appropriate since the schema does the heavy lifting and the description does not compensate with extra insights.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Find articles related to a given PMID, ranked by relevance score.' This uses a specific verb ('find') and resource ('articles related to a given PMID'), and the ranking detail distinguishes it from siblings like pubmed_cited_by or pubmed_summary.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear use case: 'Great for literature discovery — finding similar papers to a known article.' This indicates when to use the tool, though it does not explicitly mention alternatives or when-not-to-use scenarios. The context is clear enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pubmed_searchA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, which already establishes the operation's safety. The description adds useful behavioral context: it returns only PMIDs and search metadata (not full articles), and it supports Boolean operators and field tags like [MeSH Terms], [Author], [Journal]. These details go beyond the annotation and help agents craft correct queries without causing misunderstandings.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences long and every sentence earns its place: the first states the core purpose, the second clarifies the output and points to an alternative, and the third explains query syntax capabilities. No filler, no redundancy, and the most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential behaviors: what it searches, what it returns, and how to construct queries. It also points users to a summary tool for full details. While it does not explain pagination parameters or date formats, those are fully documented in the schema. Given 7 parameters and no output schema, the description provides sufficient context for an agent to use the tool correctly, though a bit more detail on return metadata would push it to 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage, with detailed descriptions for all seven parameters including example query formats. The description only reiterates that the query supports Boolean operators and field tags, which adds little beyond the schema's existing query description. Baseline 3 is appropriate because the schema fully documents parameter meaning, and the description does not materially enhance it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific action and scope: 'Search PubMed for biomedical articles by keyword, MeSH term, author, or date range.' It clearly states the output ('Returns PMIDs and search metadata') and distinguishes itself from sibling tools by explicitly referencing 'pubmed_summary' for full details, making it the canonical search tool among its siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance: 'Use pubmed_summary to get full article details for the returned PMIDs.' This tells the agent when to use this tool versus an alternative. However, 'pubmed_summary' is not in the provided sibling-tools list, which may confuse an agent attempting to invoke that alternative; this minor inaccuracy prevents a perfect score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pubmed_search_and_summarizeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds context by specifying the return fields (titles, authors, journals, dates, DOIs) and clarifying it's a combined call, going beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each earning its place: what it does, how it works, what it returns. Front-loaded and free of unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description appropriately lists the return fields and the tool's combined nature. It doesn't mention potential caveats like slower response due to chaining, but the essentials are covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 extra meaning to parameters beyond what is already in the schema, such as examples or constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool combines search and summary: 'searches PubMed and returns full article metadata in one call.' It explicitly names the chained tools (pubmed_search → pubmed_summary), distinguishing it from sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It identifies itself as a 'Convenience tool that chains pubmed_search → pubmed_summary,' implying use when both search and summary are needed in one call. It doesn't explicitly state when not to use it or mention alternatives, 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.

• rec_areasA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint: true, and the description adds behavioral context by specifying the search dimensions (keyword, state) and the return payload ('Returns area names, descriptions, and locations'). This goes beyond the annotation by explaining the data scope, although it does not discuss edge cases or limitations, which is acceptable for a simple read operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two sentences deliver purpose, scope, and return info. It is front-loaded with the primary verb and resource, and every sentence earns its place without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with no output schema and fully documented parameters, the description covers the essential aspects: what it searches, the conceptual hierarchy, and the return fields. It lacks details like default ordering or pagination behavior, but the schema covers limit/offset, and the read-only nature is annotated. Complete enough for low-complexity tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so all parameters are already documented. The description adds conceptual clarity by linking 'keyword' and 'state' to the search behavior, but does not provide additional syntactic or value-level detail beyond what the schema gives. Baseline 3 is appropriate when the schema carries the load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Search federal recreation areas by keyword or state.' It uses a specific verb (search) and resource (federal recreation areas), and explicitly distinguishes this tool from siblings by noting that 'Recreation areas are larger regions that may contain multiple facilities,' which differentiates it from rec_facilities and rec_campsites.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by stating the tool searches by keyword or state and that recreation areas are larger regions. This hints that for specific facilities, one should use a facilities tool, but it does not explicitly name alternatives or provide exclusion criteria. Clear context but lacks explicit when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• samhsa_treatment_searchA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint: true, and the description's 'Find' aligns with that, so no contradiction. The description adds the fact that the tool searches by location and that service type determines the type of facilities returned. It doesn't disclose details like default limit (though schema provides limit description), but the readOnlyHint covers safety. The description adds modest context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences: first states purpose and key input, second explains service types. No filler, front-loaded, every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple search tool with 3 parameters, 1 required, and a clear output type (facility list). With readOnlyHint annotation and 100% schema coverage, the description sufficiently covers purpose and service type. It doesn't describe the return format, but no output schema exists; however, given the simplicity and strong schema, the lack of return-format detail is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with 'address' described as 'Address, city/state, or ZIP code (e.g. 'Washington, DC' or '20001')' and serviceType fully explained via enum. The description adds a concise summary of service types, but it doesn't add 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Find substance abuse and mental health treatment facilities by location.' It names the specific resource (SAMHSA treatment facilities), the action (find/search), and the primary filter (location). It also briefly explains service types, distinguishing it from siblings like 'cms_search' or 'clinical_trials_search'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description indicates the tool is for searching treatment facilities by location and lists service types (SA, MH, BOTH), giving context for when it would be appropriate. However, it doesn't explicitly contrast it with other SAMHSA-related or health facility tools, nor does it state when not to use it. The guidance is clear but lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• septa_alertsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful return content types (messages, advisories, detours, snow alerts) and implies real-time current status, but it does not disclose update frequency, format, or behavior when no alerts exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two tight sentences with the primary action front-loaded. Every clause adds value: scope, route coverage, and return content. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, read-only alerts tool, the description covers the main purpose and output categories sufficiently. It does not explain update cadence or output structure, but given the simplicity and lack of output schema, the information provided is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is no parameter semantics to clarify. The description's mention of 'all SEPTA transit routes' reinforces that no filtering or input is needed, making this appropriate for a parameterless tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as fetching service alerts for SEPTA transit routes, specifying the geographic scope (Philadelphia) and all routes. It distinguishes well from sibling tools like septa_train_view and septa_bus_view by focusing on alerts rather than schedules or vehicle positions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies use when current SEPTA service alerts are needed, covering messages, advisories, detours, and snow alerts. It does not explicitly mention alternatives or when not to use it, but the purpose is specific enough that an agent would not confuse it with other transit tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• septa_train_viewA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals safe read-only operation. The description adds valuable behavioral context by specifying what data is returned (GPS coordinates, line, destination, current/next stop, delay minutes) and that it covers every active train. It does not mention rate limits or data freshness, but with the annotation covering safety, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose, and each sentence earns its place: the first states what it does, the second lists the returned fields. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description explains the return values (GPS coordinates, line, destination, current/next stop, delay minutes) sufficiently for an agent to know what to expect. It could add caveats like update frequency or data truncation, but for a simple 0-parameter read-only tool, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter information, but none is needed since the tool takes no inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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: all active SEPTA regional rail train positions. It also lists the exact data returned, distinguishing it from sibling tools like septa_bus_view (buses) and septa_next_to_arrive (arrivals) by focusing on train positions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (when you need real-time SEPTA train positions) but does not explicitly mention alternatives or exclusions. It lacks direct guidance such as 'for bus positions, use septa_bus_view' or 'for station arrivals, use septa_next_to_arrive', so context is present but not fully developed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_crimeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark readOnlyHint=true, and the description's verb 'Query' aligns with that. It adds valuable caveat 'Data varies by state' and 'may include...', warning users of inconsistent data availability across states—useful beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three efficient sentences: purpose, variability warning, and filter options. No redundancy or filler; 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema, but the tool is a straightforward query with thorough parameter documentation and a clear caveat about data variability. Sufficiently complete for an agent to select and invoke, though it stops short of detailing return structure or pagination.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has 100% coverage with clear descriptions for all 6 parameters. The description adds general filter categories (year, jurisdiction, full-text) but does not enrich meaning beyond what the schema already provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Begins with 'Query crime statistics for a US state' – a specific verb, resource, and geographic scope. The follow-up enumerates data types (violent crime, property crime, arrests) and granularity (county/jurisdiction), clearly distinguishing it from broader state_* siblings and crime-specific FBI tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Conveys clear usage context: querying state-level crime data with filters for year, jurisdiction, and full-text search. It does not explicitly name alternative tools (e.g., fbi_crime_summarized) or provide when-not-to-use guidance, but the scope is evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_queryA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already discloses the safe read nature. The description adds meaningful context: universal state coverage, no dependency on category mappings, and full SoQL support. It does not contradict annotations and provides useful behavior details beyond the structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four concise sentences, front-loaded with the primary purpose. Each sentence adds distinct value: what it does, scope flexibility, how to source dataset IDs, and SoQL capability. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a moderate-complexity query tool with no output schema, the description covers key context: purpose, universal state applicability, dataset ID discovery, and supported SoQL features. It lacks explicit return format or examples, but those are not essential given the schema richness and read-only nature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 lists SoQL parameters ($select, $where, etc.) as a group, reinforcing that they follow SoQL syntax, but does not add much meaning beyond the schema's per-parameter descriptions. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Query any state's Socrata open data dataset by its 4-character ID', which is a specific verb+resource+method. It also differentiates from sibling state_* tools by emphasizing it works for ANY state even without category mappings, making it the generic Socrata query tool among specialized siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you have a 4-character dataset ID and want to query arbitrary Socrata data. It also explains how to find dataset IDs by browsing state portals, which is actionable guidance. However, it does not explicitly name alternatives or provide when-not-to-use exclusions, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_alertsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true. The description adds that the data is current and includes specific alert categories, but does not disclose additional behavioral traits such as response format, rate limits, or whether no alerts returns an empty list. It adds some value beyond annotations but lacks rich behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the main action ('Get current space weather alerts and warnings from NOAA SWPC') and a second sentence adding useful detail. There is no waste or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, no-parameter, read-only tool with good annotations, the description covers the domain and content adequately. It does not describe return format, but given the simplicity and the lack of output schema, the description is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so schema coverage is trivially 100%. The description correctly omits any parameter details. Baseline for 0 params is 4, and no additional parameter explanation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets current space weather alerts and warnings from NOAA SWPC, and specifies the types (watches, warnings, alerts) and phenomena (geomagnetic storms, solar radiation, radio blackouts). This distinguishes it from siblings like swpc_kp_index, swpc_forecast, and nws_alerts_active.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: for current space weather alerts. It does not explicitly state exclusions or name alternative tools, but the specificity of 'current alerts from NOAA SWPC' provides clear context for when this should be used.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_aurora_forecastA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so the description's job is to add context beyond that. It adds the 24-hour time window, northern hemisphere scope, and OVATION model source. It does not describe exact return format or pagination, but for a zero-parameter read-only tool, the added context is useful and non-contradictory.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences and front-loaded with the primary purpose. The second sentence adds useful model and behavioral detail without redundancy or filler. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, no-parameter, read-only tool, the description covers the essential scope: time range, region, model, and a behavior note. However, since there is no output schema, it could have been more explicit about the return structure (e.g., probability values by latitude), which keeps it from full completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and schema description coverage is 100% by default; the baseline is 4. The description correctly does not attempt to document nonexistent parameters, so no further requirement exists.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a 24-hour northern hemisphere aurora probability forecast, using a specific verb ('Get') and resource ('aurora probability forecast'). Mentioning the OVATION model distinguishes it from sibling SWPC tools like swpc_forecast or swpc_kp_index.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for aurora forecasts but does not explicitly contrast with alternative tools such as swpc_forecast or swpc_kp_index. The note about higher probabilities at higher latitudes during geomagnetic activity provides context for interpreting results, but no direct when-to-use vs. when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_kp_indexA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation, and the description adds useful context about the Kp scale's meaning (quiet, unsettled, storm levels). It goes beyond the annotation by explaining the data's interpretation, but does not describe response format or update frequency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences: the first states the action and the second provides the Kp scale legend. It is front-loaded with the purpose and contains no filler or redundant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no params, no output schema), the description adequately conveys what the tool does and how to interpret the values. It could be more complete by mentioning the time range or output format, but these are not critical for understanding the tool's purpose.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters and 100% schema coverage, there is nothing the description needs to add about parameters. The baseline for no-parameter tools is 4, and the description appropriately focuses on the data being returned rather than parameter syntax.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Get') and resource ('recent planetary Kp index values'), which precisely identifies the tool's function. The naming convention and Kp scale explanation distinguish it from sibling SWPC tools like swpc_dst_index and swpc_solar_flux.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool over alternatives, nor does it mention when not to use it. However, the Kp scale interpretation implies use for geomagnetic activity questions, giving some situational context without explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_solar_fluxA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation. The description adds value by defining SFU units and activity thresholds, but does not disclose other behavioral aspects like return format, time range, or data source characteristics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the operation and resource, followed by useful interpretive context. Every sentence earns its place with no redundant or vague wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple no-parameter tool with annotations, the description sufficiently covers what the tool does and provides context for interpreting the values. It could briefly mention that the data is typically a time series, but this is not a significant gap given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description is not required to explain parameter semantics, and it appropriately focuses on the data returned rather than parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' with the resource 'F10.7 cm solar radio flux data', clearly identifying the tool's function. It also explains the significance of F10.7, which distinguishes it from other SWPC tools like swpc_kp_index or swpc_sunspots.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context by stating that F10.7 is a key indicator of solar activity and provides threshold interpretations (elevated vs high activity). However, it does not explicitly mention when not to use this tool or suggest alternative tools for other solar indices.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• traffic_511_queryA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation, and the description adds useful behavioral context by explaining what each action returns (e.g., camera image URLs, RWIS weather fields, sign content). It does not cover rate limits, pagination, or response format, but the added action semantics go beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, with a clear first sentence and a well-organized action list. Every line conveys necessary information without filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter query tool with readOnlyHint and action descriptions, the context is largely sufficient. The absence of an output schema is compensated by the action descriptions, though the response shape is not detailed and the '15 states' claim is not fully matched by the schema's listed state codes.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters described in the schema. The description adds meaningful semantics by elaborating the five action enum values, turning terse labels into understandable data types, though the state parameter is not further enriched.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Query real-time traffic data for a state' and lists five concrete action types, making the purpose specific and actionable. It distinguishes itself from state-specific siblings like md_traffic_incidents and the more general traffic_511_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by specifying 'for a state' and enumerating supported actions, but it does not explicitly contrast with alternative tools such as traffic_511_list or the Maryland-specific traffic tools. It lacks explicit when-to-use versus alternatives guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• travel_advisoriesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, covering safety. The description adds context that it returns advisory text, date published, and country information, and that no parameters return all countries. However, it does not disclose potential behaviors like pagination, rate limits, or output format, which are not covered by annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loaded with the core purpose. Every sentence adds information: what it does, the level meanings, and the return content. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description helps by listing the return elements (advisory text, date published, country information) and explaining the filter semantics. It lacks details on potential pagination or error conditions, but for a simple, read-only lookup tool this is adequate and fairly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 value by explaining the meaning of advisory levels (1–4) and clarifying that country_code is a filter for a specific country, plus the no-parameter behavior returns all countries. This goes slightly beyond the schema's brief field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' and explicitly names the resource: U.S. State Department travel advisories. It clearly distinguishes from any sibling tool by citing the specific government source and scope ('all countries or a specific country').

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 need U.S. State Department travel advisories) and clearly states the optional filters. It does not explicitly name alternatives or exclusions, but given the unique nature of the tool, the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usajobs_detailA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the description adds behavior beyond that by enumerating specific return contents: duties, qualifications, salary, location, application instructions, and deadlines. This helps the agent know what to expect without needing an 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the primary action and resource, followed by a compact list of content categories. Every word earns its place; no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter detail tool with a readOnly annotation, the description is sufficiently complete: it specifies how to invoke it (via control number) and what it returns. It doesn't discuss error cases or formatting, but these are minor gaps given the low complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the parameter description already states 'Job control number from usajobs_search results'. The description only repeats this concept, adding no new meaning. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get full details') and resource ('federal job listing'), with a clear method ('by its control number'). It clearly distinguishes itself from the sibling tool usajobs_search, which returns search results rather than full details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: the control number comes from usajobs_search, so the tool is the detail follow-up to a search. It doesn't explicitly name alternatives or exclusions, but the context is clear, so it earns a 4.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usgs_daily_water_dataA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers safety. The description adds that data are aggregated daily means and lists parameter codes, which is useful context, but does not disclose output format, pagination, or potential limitations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences, each providing distinct value: the primary function, a clarifying comparison, and parameter code semantics. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with six optional parameters and no output schema, the description covers the core purpose, data type, and parameter semantics. The absence of return-format details is a minor gap, but overall it is sufficiently complete for selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 parameter code meanings with units (cfs, ft, °C) and introducing 00010 (water temp), which is not in the schema description. This goes beyond the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves USGS daily value water data, specifically historical daily averages. It distinguishes itself from real-time instantaneous values, making its purpose and differentiation clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly notes that daily means are better for trend analysis and contrasts with real-time instantaneous values, giving clear context on when to use it. However, it does not explicitly name alternative tools, so it stops short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usgs_earthquakesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description adds return-field details (magnitude, location, depth, time, alert level, tsunami risk, felt reports) plus a magnitude scale interpretation. This provides useful context beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each with distinct purpose: purpose, returns, magnitude context. No filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 10 parameters and no output schema. The description covers the essentials and adds domain context (magnitude scale). It could mention pagination/limit default or that maxradiuskm requires lat/lon, but the schema covers those details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 100% parameter descriptions, so baseline is 3. The description adds the magnitude scale (2.5+ felt, 4.0+ moderate, etc.) which helps select appropriate minmagnitude/maxmagnitude values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search for earthquakes by magnitude, location, date range, and more' – a specific verb+resource+scope. It distinguishes from sibling tools like usgs_earthquake_count (count-only) and usgs_significant (significant earthquakes only).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context (search by filters) but does not explicitly mention alternatives or when not to use this tool. Siblings like usgs_significant and usgs_earthquake_count serve different purposes but are not referenced.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usitc_trade_dataA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds that it returns trade values, quantities, and product descriptions, which provides useful output transparency. It does not disclose limits or defaults, but the annotation lowers the burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences that front-load the primary purpose, then list search dimensions and output. No redundant content or unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 output, while the schema handles parameter details. It omits potential limitations (e.g., whether parameters are required or result limits), but given the straightforward query nature and annotations, it is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all four parameters with descriptions, so the baseline is 3. The description merely lists the parameter types without adding extra semantic detail beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Query') and identifies the resource ('U.S. import/export trade statistics from the USITC DataWeb'). It clearly states the search dimensions (HTS code, partner country, year, trade type), distinguishing it from other trade-related tools by source and scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a clear use case for querying USITC trade data, but it does not explicitly mention when not to use it or compare with similar tools like bea_intl_services_trade. The context is clear enough for the intended purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• uspto_ptab_proceedingsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, signaling a read operation. The description adds context about searchable facets and proceeding types, but does not disclose details like default result limits, pagination behavior, or exact response shape. Given the readOnlyHint covers safety, this is adequate but not enriched.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence stating the resource and purpose, followed by a compact list of search dimensions. Every phrase earns its place, with no filler or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with no required parameters, a 100% schema-covered parameter set, readOnlyHint=true, and no output schema, the description covers the core search scope, available filters, and domain context. It does not describe response format or pagination, but given the presence of rich annotations and complete schema, this does not create a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameter names and descriptions exist. The description reinforces which query fields are meaningful for this domain (e.g., trial number, patent owner, petitioner, technology center, status, date range), which helps an agent translate natural-language intent into schema-patterned queries like 'patentOwnerData.patentOwnerName:Apple'. It adds value beyond the schema by providing domain-specific search examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description begins with a specific verb ('Search') and a clear resource ('PTAB trial proceedings'), enumerating the proceeding types (IPR, PGR, CBM, derivation), and lists distinct search dimensions (trial number, patent owner, petitioner, technology center, status, date range). This distinguishes it from siblings like uspto_search_applications or uspto_ptab_proceeding_details, which target different data or granularity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys when to use the tool: when searching PTAB trial proceedings across specified proceeding types and by multiple criteria. It does not explicitly state when not to use it or name an alternative, but the clear scoping to PTAB trial proceedings with example query fields implies the appropriate context, which is sufficient for sibling differentiation among the many USPTO-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wmata_incidentsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description complements the readOnlyHint annotation by clarifying it returns current incidents without indicating side effects. It provides useful context about the types of incidents (rail delays, bus disruptions, elevator outages), but doesn't disclose details like pagination or response structure. Given the simple read-only nature, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, information-dense sentence. It front-loads the action and resource, then lists the key categories. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, read-only, single-parameter tool with no output schema, the description provides enough context for an agent to understand what it returns (current incidents) and how to filter. It doesn't describe the response format, but this is not critical for such a straightforward retrieval endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with an enum listing 'rail', 'bus', and 'elevator', plus a description noting 'default: all'. The description adds no additional parameter detail, but the schema already fully explains the single optional parameter, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Get') for a specific resource ('current WMATA service incidents') and enumerates the incident categories. This distinguishes it from sibling tools like wmata_train_predictions and wmata_bus_predictions, which focus on arrivals/positions rather than incidents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it clear that this tool retrieves current WMATA service incidents, covering rail, bus, and elevator/escalator issues. While it doesn't explicitly mention when not to use it (e.g., for non-WMATA transit systems), the scope is unambiguous and the context suffices for correct selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wqp_stationsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds useful context about data provenance (USGS, EPA, 400+ state agencies), which helps an agent understand the scope. It doesn't mention pagination or return format, but the readOnlyHint lowers the burden for behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the action and filters. No redundant information or filler. Every word earns its place, making it highly efficient and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only station search with no output schema and fully documented parameters, the description covers the core functionality and data sources. It doesn't describe the return shape or pagination, but given the tool's straightforward nature, this is sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters have detailed descriptions. The tool description merely echoes the filter types (state, county, HUC) without adding new semantics. Baseline 3 is appropriate when the schema carries the full parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool searches water quality monitoring stations by state, county, or HUC code, using a specific verb and resource. This differentiates it from sibling tools like bart_stations or cdec_stations by specifying 'water quality' and the filtering dimensions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the intended use case: finding water quality monitoring stations based on geographic filters. It does not explicitly mention alternatives like wqp_results or when not to use it, but the search-by-filter context is clear enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wsdot_ferry_terminalsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, so the safety profile is covered. The description adds some behavioral context by indicating the data is 'current' and includes estimated wait times for drive-up customers. However, it does not disclose details like data freshness, update frequency, or any limitations beyond what is implied. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the main action ('Get current terminal wait times') followed by a clarifying second sentence. Every word adds value, and there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description must convey what the agent can expect from the response. It covers the key data elements: terminal wait times, vehicle space availability, fullness per sailing, and drive-up wait estimates. Given the tool's simplicity (zero parameters, read-only), this is sufficient, though it could mention whether it covers all terminals or only specific ones.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there are no parameter semantics to elaborate. The description compensates by explaining what the returned data contains (wait times, space availability, fullness), providing value beyond the empty schema. Baseline 4 for zero-parameter tools is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get current terminal wait times and vehicle space availability at Washington State Ferry terminals.' It also specifies what data is shown (fullness, drive-up wait times), which distinguishes it from sibling tools like wsdot_ferry_schedule (schedules) and wsdot_ferry_vessels (vessels).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: when current terminal wait times or vehicle space availability at WSDOT ferry terminals is needed. It does not explicitly name alternatives or exclusions, but the domain context plus sibling tool names imply the intended use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bart_advisoriesA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds context about the data returned (alerts, delays, disruptions) but does not disclose extra behaviors like rate limits, pagination, or data source freshness. This is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences front-load the purpose and list what the tool returns. No filler or repeated schema information. Every word adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only tool with no output schema, the description fully explains what the tool does and what it returns. No additional prerequisites or return-value explanation is needed, making this complete for its simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so schema coverage is 100% by default. Per the rubric, 0 params gets a baseline of 4; the description appropriately adds no parameter details because none exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Get service advisories for BART', and clarifies the geographic scope (San Francisco Bay Area). It clearly distinguishes from sibling tools like bart_stations and bart_departures by focusing on alerts, delays, and disruptions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states the context for use (BART service advisories) but does not explicitly mention alternatives or exclusions. It implies when to use it via the specific resource and content type, earning a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_intl_services_tradeA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation already declares readOnlyHint=true, so the tool's read-only nature is known. The description adds the behavioral nuance of the parameter mutual exclusion, which is valuable context beyond the annotation. It does not mention output format or pagination, but the read-only hint covers the main safety aspect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and concise. It starts with a clear purpose sentence, then an important callout, followed by parameter value lists. Every line adds value, with no redundant text, and it is front-loaded with the core function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description explains the purpose, key constraint, and parameter values, but with no output schema, it does not describe what the response looks like or any return value structure. For a data-fetching tool, this is a notable gap, though the schema descriptions fill most parameter-level needs. The mention of bea_dataset_info for enumerating values is helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Since the schema descriptions cover 100% of parameters, the baseline is 3. The description adds a cross-parameter constraint (TypeOfService and AreaOrCountry cannot both be 'All') that is not visible in the individual schema descriptions. It also lists common values for TypeOfService, TradeDirection, and Affiliation, reinforcing the schema but providing extra semantic context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get U.S. international trade in services data (annual)'. This uses a specific verb and resource, distinguishing it from sibling BEA tools that cover GDP, personal income, or other metrics. The annual frequency is also explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance, especially the critical constraint that 'BEA requires either a specific TypeOfService or a specific AreaOrCountry' and that you cannot use 'All' for both. It also directs the user to bea_dataset_info for discovering valid values. However, it does not compare against alternative BEA tools or state when to choose this tool over others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_places_healthA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true already covering safety, the description adds useful behavioral context: it specifies the data source methodology (BRFSS-based estimates), the output unit (crude prevalence percentage), and the full set of measures available. This goes beyond the annotation's minimal signal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description opens with the core purpose and then provides a comprehensive but organized list of measures. The list is lengthy, but every item is relevant and aids parameter selection, and the structure is clear with a final return-format statement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (3 parameters, no output schema) and the readOnly annotation, the description is quite complete. It communicates the data source, available measures, and the nature of the return values. It could mention whether multiple years are covered or how pagination works, but these are not critical gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema describes all three parameters, but the description adds significant value by listing far more valid measure IDs than the schema's measure description and by clarifying that results are crude prevalence percentages. This helps the agent choose valid inputs and interpret output correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get', identifies a clear resource ('county-level health indicators from CDC PLACES'), and defines the scope with 'Returns crude prevalence (%) by county'. This fully differentiates it from sibling tools like cdc_places_city by explicitly stating county-level granularity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies the tool is for retrieving county-level CDC PLACES health indicators, giving the agent a strong contextual signal. However, it does not explicitly mention when not to use it or name alternative tools (e.g., cdc_places_city for city-level data), so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfpb_complaint_trendsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes the non-destructive nature. The description adds a valuable behavioral detail: the API rejects requests without trend_interval. It also explains sub-lens behavior. This goes beyond annotations but does not cover all potential edge cases 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: four sentences that front-load the purpose, then detail the endpoint, required parameter, lens options, and sub-lens. No filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the description covers the core concept and required parameter, it does not describe the return format or how filters (date range, state, company) affect the output. With no output schema, the agent might not know what to expect. The tool has 11 parameters, so a bit more contextual detail would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are already documented. The description adds semantic meaning by explaining the lens options (overview, product, issue, tags) and how sub_lens drills down into sub-categories, which is not fully captured in the schema's enum lists. It also emphasizes the required trend_interval.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get complaint trends over time using the CFPB Trends API.' It specifies the resource (complaint trends), the verb (get), and distinguishes from siblings (e.g., cfpb_complaint_detail, cfpb_complaint_aggregations) by emphasizing time-series and lens-based aggregation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool (for trends over time) and highlights the required trend_interval. However, it does not explicitly mention alternative CFPB tools or when not to use this one, so it stops short of full usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cftc_productsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds behavioral context by stating the tool lists/discover products and supports keyword search for specific commodities, currencies, or financial instruments. It does not contradict the annotation and discloses the primary behavior without unnecessary warnings.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences, front-loaded with the core purpose, followed by usage context and search guidance. Every sentence adds value with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one optional parameter, no output schema, and read-only annotation, the description fully covers what the tool does, when to use it, and how to use the search parameter. It also connects to sibling COT report tools via the 'before querying COT reports' note, completing the context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single 'search' parameter, which already provides example keywords. The description adds the phrase 'commodities, currencies, or financial instruments' to clarify the types of markets, but this is largely redundant with the schema's examples. The baseline of 3 applies since the schema handles the parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'List available products and markets tracked by CFTC' with a specific verb and resource. It further distinguishes the tool's purpose by explaining it is used to 'discover market names before querying COT reports,' which sets it apart from sibling COT report tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use to discover market names before querying COT reports,' giving clear context for when to use it. However, it does not provide explicit when-not-to-use guidance or name alternative tools, only implying the relationship to COT report queries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cms_searchA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds value by specifying return fields (dataset IDs, titles, descriptions) and the link to cms_query. No pagination or limit info is given, but this is a simple 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with no redundancy. The first states the action and resource, the second states output and next step. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter search tool with no output schema, the description adequately covers inputs, outputs, and the follow-up step (cms_query). Given the read-only annotation and simple scope, no major gaps exist.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a detailed description of the keyword parameter including examples. The description does not add any additional meaning about the parameter beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Search') and the resource ('CMS provider data datasets'), specifying that it returns dataset IDs, titles, and descriptions. This distinguishes it from sibling tools like cms_query (data fetching) and cms_hospitals/cms_nursing_homes (specific datasets).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs to use the returned ID with cms_query to fetch data, establishing a clear workflow. It does not explicitly list alternatives or exclusions, but the purpose and cross-reference make the usage context clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_amendment_textA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, and the description adds valuable context by stating the congressional range and the return contents (version types and PDF/HTML URLs). It does not contradict the annotations, and it transparently indicates that the tool returns metadata links rather than the actual amendment text.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the verb and resource, followed by return-value info. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple fetch tool with three required params and no output schema, the description sufficiently explains what it returns (version types and PDF/HTML URLs) and the only major limitation (117th+). This is enough for an agent to know when to use it and what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers all three parameters with descriptions (100% coverage), so the description does not need to repeat them. It adds no extra syntax or format details beyond the schema, but the congress parameter's '117th onwards' scope is mentioned in both. Baseline 3 is appropriate given high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation (get text versions), the resource (a specific amendment), and the scope (117th Congress onwards). It distinguishes itself from sibling tools like congress_amendment_details by focusing on text versions and format URLs rather than amendment metadata or lists.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states the exact use case (retrieving amendment text versions) and the applicable congressional range, giving an agent clear context for when to select it. It does not explicitly name alternatives or exclusions, but the context is sufficient for a focused data-retrieval tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bill_titlesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  While annotations already declare readOnlyHint=true, the description adds meaningful behavioral context by detailing the variety of titles returned and noting that titles can reflect different text versions. This enriches the agent's understanding beyond the safety profile. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, with two sentences that efficiently convey functionality and use case. No redundant information is included, and the structure is front-loaded with the primary action (Get all titles) followed by clarifying details and an example.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the absence of an output schema, the description adequately explains what the tool returns (types of titles) and provides a practical usage context. The parameter details are fully covered by the schema, and the description's level of detail is appropriate for this straightforward, read-only lookup tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with all four parameters individually documented. The description itself does not provide additional parameter-level meaning beyond implying that the bill must be identified, which is already evident from the schema. Thus, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the tool's function: retrieving all titles for a bill, enumerating the types of titles (short, official, display, and version-specific). It distinguishes itself from sibling tools like congress_bill_details or congress_bill_summaries by focusing exclusively on title data. The inclusion of a concrete example ('Inflation Reduction Act') further reinforces purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear use case (finding the popular name of legislation) and implies when to use this tool over others by emphasizing title-specific information. However, it does not explicitly mention when not to use it or name alternative tools, so it falls just short of the highest standard.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_crs_report_detailsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, so the safe read-only nature is covered. The description adds value by detailing what information will be returned (summary, authors, topics, legislation, format links), giving the agent expectations about the response content without contradicting the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, consisting of two short sentences that front-load the primary action and then list the return contents. No unnecessary words or repetition, achieving high information density.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple detail tool with one parameter, readOnly annotation, and no output schema, the description is complete. It clearly states the input (report number) and the output (summary, authors, topics, legislation, format links), which fully covers expected behavior without needing additional context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a well-described 'report_number' parameter including examples. The description only reinforces this by referring to 'report number/ID' and does not add significant new meaning beyond the schema. Hence, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Get detailed information about a specific CRS report by report number/ID', specifying the verb, resource, and scope. It also enumerates the output content (summary, authors, topics, related legislation, format links), which distinguishes it from sibling tools like congress_crs_reports which likely serve as a list/search function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies the tool is for retrieving details of one known report, given the requirement of a 'specific report number/ID'. It does not explicitly mention alternatives or when not to use it, but the context is clear enough for an agent to understand it should be used after obtaining a report number, likely from congress_crs_reports.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_member_detailsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses exactly what data is returned (full bio, party history, all terms, committee assignments, photo URL, official website) which is not available in the annotations or schema. It aligns with the readOnlyHint annotation (no mutation implied) and adds specific behavioral detail about the response contents.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first clearly states purpose and return contents, the second provides a helpful prerequisite. It is concise, well-structured, and every sentence adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only lookup tool with a complete input schema, the description effectively covers what the tool does, what it returns, and how to get the required ID. No output schema exists, but the return contents are listed in the description, making the tool's behavior fully understandable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter bioguide_id is fully documented in the schema with a description and example. The tool description also mentions 'BioGuide ID' in the opening line, reinforcing the parameter's meaning. With 100% schema coverage, the baseline of 3 applies; the description adds no extra semantic detail about the parameter itself beyond the workflow tip.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get detailed information about a specific member of Congress by BioGuide ID,' which clearly states the action and resource. It then lists the specific data fields returned (bio, party history, terms, committee assignments, photo, website), setting it apart from sibling tools like congress_member_bills and congress_member_full_profile.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs to 'Use congress_search_members first to find the BioGuide ID,' providing a concrete prerequisite and workflow. While it does not mention alternatives like congress_member_full_profile for comprehensive profiles, the guidance is sufficient for the primary use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_search_billsA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is disclosed. The description adds return fields (bill number, title, sponsor, latest action, status) but does not disclose any further behavioral traits like rate limits, pagination behavior, or required authorization. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured, with the purpose stated in the first sentence, return values in the same sentence, and helpful reference lists (congress numbers and bill types) following. Every sentence provides useful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 8 parameters but no output schema, the description compensates well by stating the return fields and providing crucial lookups for congress numbers and bill types. The schema handles the remaining parameter details. The description is sufficiently complete for an agent to select and use this tool effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameters, so the baseline is 3. The description adds extra semantic value beyond the schema by mapping congress numbers to year ranges (e.g., 118th = 2023-2024) and expanding on the bill type abbreviations (hr, s, etc.), which helps the agent interpret those parameters correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Search for bills in Congress') and clearly identifies the resource (bills) and the scope (by keyword, congress number, or bill type). It distinguishes itself from sibling tools like congress_bill_details by focusing on search, not details on a specific bill.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on what this tool does and the search criteria, making it obvious when to use it. It does not explicitly state when not to use it or mention alternatives, but the purpose is straightforward enough that no exclusions are needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_senate_votesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description adds meaningful context: data source (senate.gov XML), coverage (101st Congress to present), and output content (party breakdown). No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose in the first sentence, and the cross-reference list is dense but relevant. Slightly long due to the list, but every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with no output schema, the description provides source, coverage, content, and usage guidance. It doesn't describe return format, but that's not critical for a roll call vote query tool with clear semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (all 4 params have descriptions), so the description doesn't need to add parameter semantics. It doesn't, but the schema fully handles this baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource ('Get Senate roll call vote results from senate.gov XML'), states the scope (how senators voted by party on legislation, nominations, procedural motions), and explicitly distinguishes from the sibling tool 'For House votes, use congress_house_votes.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance on when to use this tool vs the House counterpart: 'For House votes, use congress_house_votes.' It also lists complementary cross-reference tools (FEC, lobbying_search, congress_member_bills) with context on what each adds.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cos_licensingA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, establishing this as a read-only operation. The description adds value by disclosing the return format ('license names, types, issuing agencies, and application URLs'), which is not covered by annotations or an output schema. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each earning its place: the first states the core function, the second lists return value components, and the third provides usage context. There is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with only two simple parameters and full schema coverage, the description is complete. It covers purpose, return contents, and use case. Given the low complexity and the presence of readOnlyHint, no additional behavioral or contextual information seems necessary.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with both parameters (state and keyword) fully described. The description does not add additional parameter semantics beyond restating the purpose ('by state'), so it does not exceed the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Look up licensing and certification requirements for an occupation by state.' This uses a specific verb ('Look up') with a clear resource ('licensing and certification requirements') and scope ('by state'). It also lists return contents ('license names, types, issuing agencies, and application URLs'), distinguishing it from sibling tools like cos_occupation_search which focuses on occupation search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for use: 'Useful for understanding state-specific professional requirements.' This implies when to use the tool, but does not explicitly mention alternatives or exclusion criteria. It lacks explicit 'when-not-to-use' guidance, which prevents a top score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• courtlistener_opinionA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, indicating a safe read operation. The description adds specific behavioral context by listing return fields (full text, case name, court, date filed, citations), which goes beyond the annotation. It does not disclose error handling, but this is acceptable for a simple get-by-id tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with no filler. It front-loads the verb ('Get') and resource, then immediately states the return values. Every sentence contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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), good read-only annotation, and clear schema, the description is complete. It explains the purpose and lists the return fields, which is sufficient even without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully covers the single parameter with a description ('CourtListener opinion ID (from search results)') and appropriate type. The tool description adds no additional parameter meaning, so the baseline score of 3 applies due to high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get the full text of a court opinion by its CourtListener ID.' It specifies the resource (court opinion), the action (get full text), and the unique identifier, distinguishing it from the sibling courtlistener_search tool which would be used to find IDs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'by its CourtListener ID' establishes clear usage context: this tool is for retrieving a specific opinion when an ID is already known. It does not explicitly mention alternatives or when-not-to-use, but the ID-based framing makes the intended use case clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cta_train_arrivalsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true. The description adds behavioral context by listing what is returned (predicted arrival times, destination, run number, direction, delay status), which goes beyond the annotation and helps set expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the verb, no redundant phrases. Every sentence adds relevant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description sufficiently explains the return fields and provides real-world station ID examples, enabling an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides complete documentation for station_id, including the numeric format and examples. The description repeats the same examples without adding new meaning, so it does not exceed the schema baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Specific verb 'Get' and resource 'L train arrival predictions for a CTA (Chicago) station' clearly define the tool's function. It distinguishes from siblings like cta_bus_arrivals by specifying 'L train' and 'CTA'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Clear context is provided: this is for CTA L train arrival predictions. However, it does not explicitly mention alternatives or when not to use, such as for bus arrivals or other transit systems.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• doj_press_release_detailA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by listing the fields returned (complete body, component, topic, date, URL), which helps the agent know what to expect. No contradictions or missing critical behaviors for such a straightforward read operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences: the first states the core purpose, the second lists return fields. No filler, no redundancy. The most important information (verb + resource) is front-loaded, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple: one parameter, read-only, no output schema. The description specifies the input source (UUID from search results) and the output content (body, component, topic, date, URL), which is sufficient context for an agent to invoke it correctly without ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the parameter 'uuid' is described as 'UUID of the press release (from search results)'. The tool description repeats this with 'by UUID' but adds little beyond the schema. Per guidelines, baseline 3 is appropriate when the schema carries the semantic load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: get the full text of a specific DOJ press release by UUID. It specifies the resource (DOJ press release) and the action (getting full text), and it distinguishes itself from sibling tools like doj_press_releases (which likely handles search/list) by focusing on a specific release's detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description and parameter schema provide clear context: the tool requires a UUID and explicitly notes '(from search results)' in the parameter description, implying it should be used after a search. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for a simple detail-fetch tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• epa_uv_indexA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint: true, so the safe read-only behavior is already known. The description adds value by providing the UV scale interpretation (0-2 Low, etc.), which helps the agent understand the output semantics beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences: purpose, UV scale, and health relevance. Front-loaded with the primary action, no wasted words, and the scale is a compact data table.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, with good annotations and full schema. The description provides the UV scale, which effectively communicates the expected output format. No output schema exists, but the description covers what a user/agent needs to know for this forecast tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with detailed explanations for zip, city, and state. The description repeats that location is 'ZIP code or city/state' but adds no new param-specific details. Baseline 3 is appropriate when the schema carries the burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Get UV index forecast for a U.S. location' with specific location types (ZIP or city/state). This verb+resource combination is unambiguous and differentiates it from weather or environmental siblings like nws_forecast or nrel_solar.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear use case: 'Useful for health recommendations -- high UV correlates with skin cancer risk.' It indicates when this data is relevant, though it does not explicitly name alternatives or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• faa_tafA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes this as a safe read operation. The description goes beyond this by revealing the response structure (forecast periods with conditions, wind, visibility, clouds) and the station ID rule, adding useful behavioral context without contradicting the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, each with a distinct purpose: what the tool does, what it returns, and how to specify stations. It is front-loaded with the core purpose and contains no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only tool with no output schema, the description is fully sufficient. It tells the agent what data to expect (forecast periods with conditions, wind, visibility, clouds) and how to construct the request (ICAO codes, comma-separated). The readOnlyHint and schema round out the context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the 'ids' parameter including ICAO code format and comma-separated multiple stations, so schema coverage is 100%. The description's mention of ICAO codes and comma-separation essentially mirrors the schema, providing no additional parameter meaning beyond the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get TAF') and resource ('for airports'), and specifies the key content returned (forecast periods with conditions, wind, visibility, clouds). It distinguishes itself from sibling weather tools like METAR or SIGMET by explicitly naming the TAF product, even though it doesn't mention alternatives by name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: when TAF forecasts are needed for specific airports identified by ICAO codes. It also explains station ID formatting and multi-station support, which guides correct invocation. However, it doesn't explicitly mention when not to use it or name alternatives like faa_metar.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_device_510kA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, establishing the safe read-only nature. The description adds valuable behavioral context: dataset size (174K+), the meaning of 510(k), example query syntax, and count fields for aggregation. This goes beyond the annotation and helps the agent understand scope and functionality.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with an opening statement, a brief explanation of 510(k), bulleted examples, and a count fields section. Every section adds value, though it is slightly longer than necessary—hence 4 rather than 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with two well-documented parameters and readOnlyHint annotation, the description provides essential context: what data is searched, example queries, and count fields. It could be more complete by describing the response format, but given the generic search schema and absence of output schema, it covers the key aspects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 domain-specific parameter semantics by showing real field names and values usable in the 'search' parameter (e.g., advisory_committee:cv, device_name:"pacemaker"). It also lists count fields, which clarify how the 'search' parameter can be used for aggregation-like queries.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search 510(k) premarket clearance decisions' with a specific verb and resource. It distinguishes itself from sibling FDA tools (e.g., fda_device_pma, fda_device_classification) by explicitly naming the 510(k) program and providing domain-specific examples.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool—when searching 510(k) premarket clearance decisions—and includes example searches that convey typical use cases. However, it does not explicitly mention alternatives or exclusions, keeping it a notch below a perfect score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_device_classificationA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, and the description adds useful return-field context but does not disclose additional behavioral traits such as pagination or rate limits. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, then returns, examples, and count fields. Every sentence adds value without unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description explains the return contents and demonstrates representative queries. Given only two parameters and a straightforward search tool, this is complete enough for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters, and the description enhances this with domain-specific examples for search values (regulation_number, product_code, device_name, device_class) and count fields. This goes beyond the generic query syntax in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Search medical device classification' followed by a scale estimate, and specifies outputs: device class, product codes, definitions. This clearly distinguishes it from other FDA device tools like 510(k) or enforcement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear query examples and count fields that show when to use this tool, but does not explicitly state when to prefer it over alternative FDA device tools or list exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_drug_shortagesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful behavioral context beyond that: it shows example query patterns, lists searchable fields, and mentions count fields for aggregations. This helps the agent understand how to interact with the API effectively.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately sized but well-structured: a clear purpose statement, a list of tracked fields, practical examples, and count field hints. Each section serves a purpose, though it could be slightly tightened.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description does a good job of explaining what data is available and how to search it. The examples and field list give the agent enough context to construct queries and interpret results, though a brief note on response structure would make it even more complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers both parameters with descriptions, so baseline is 3. The description adds value by providing dataset-specific example queries and listing fields that can be used in the search parameter, enhancing the agent's understanding of what values are accepted.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches FDA drug shortage listings and explains what information it tracks (status, dosage form, therapeutic category, company, shortage reason). This distinguishes it from sibling FDA tools like fda_drug_events or fda_drug_recalls, as it is specifically about shortages.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool by describing the dataset and giving concrete example searches. It does not explicitly name alternatives or exclusions, but the purpose is clear enough that an agent can infer when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fec_candidate_financialsA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the operation is a safe read. The description adds minimal behavioral context—only listing the returned fields—but does not disclose potential pitfalls like error handling, rate limits, or behavior for invalid IDs. This is adequate for a simple read with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the function and required input. Every word contributes useful information, with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two parameters and no output schema, the description covers the essentials: what it does, what it returns, and what prerequisite is needed. The schema provides parameter details, and the annotation ensures safety, so the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 telling users how to obtain a candidate_id (via fec_search_candidates), which is not in the schema. The cycle parameter is already well-described with an example, so the description does not need to add more.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get financial summary for a candidate' with specific metrics (total raised, spent, cash on hand, debt). This distinguishes it from sibling tools like fec_committee_financials, which focus on committees, and from fec_search_candidates, which is for finding candidates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states the prerequisite: 'Requires a candidate_id' and directs users to fec_search_candidates to obtain it. This gives clear context for when to use the tool, though it doesn't explicitly mention alternatives or exclusions (e.g., not for committees).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• foia_agenciesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds value by specifying the return content (agency names, abbreviations, submission details, websites) and noting it lists all agencies, which is useful behavioral context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loaded with the main action, then return details, then usage guidance. Every sentence earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple read-only list tool with one optional parameter and no output schema. The description covers purpose, return fields, and downstream usage, making it fully sufficient for an agent to understand and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%—the 'search' parameter is fully described with examples of case-insensitive partial matches. The description does not add additional parameter semantics, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all federal agencies with FOIA offices and contact information, using a specific verb and resource. It also distinguishes itself by explicitly connecting to the foia_report tool, making its purpose unique among siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: to discover agency abbreviations for the foia_report tool. It does not explicitly state exclusions or alternative tools, but the guidance is specific enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_endpoint_fieldsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: it returns schema-like metadata (field names, types, formats) rather than actual data, and it implies a non-mutating discovery action. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences provide complete information with no fluff. The main action and value are front-loaded, and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter, read-only metadata tool, the description is complete: it explains what the tool returns, when to use it, and why it matters. No output schema exists, but the description adequately conveys the return content. Low complexity means no further behavioral detail is necessary.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter 'endpoint' is fully described in the schema with examples, covering 100% of the parameter documentation. The description adds no additional parameter-level detail beyond restating that the endpoint is Treasury-specific, so the schema carries the weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('field names, data types, and formats for a specific Treasury Fiscal Data API endpoint'), clearly distinguishing this discovery tool from data-query siblings like query_fiscal_data and list_datasets. The second sentence reinforces its purpose as a pre-query discovery step.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states the usage context: 'before querying data.' It does not name alternative tools or provide exclusion criteria, but the intended workflow is clear enough for an agent to choose this tool over data-fetching alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hmda_check_digitA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description does not contradict it. The description adds useful behavioral detail by explaining that the tool appends the two-digit check digit to create a valid ULI, which clarifies the output format beyond what the annotation provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each serving a purpose: stating the action, describing the output, and providing the regulatory context. There is no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter, read-only computation with no output schema, the description fully covers input, output behavior, and usage purpose. It explicitly states what the tool does with the input and why it is used, making it self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers the parameter with 100% coverage, describing loan_id as 'Loan ID (LEI + institution-assigned loan identifier, without check digit)'. The description only repeats 'from a loan ID' and 'appends' without adding new parameter semantics, so it does not improve on the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Generate'), identifies the resource ('ULI check digit'), and defines the input ('loan ID'). It clearly distinguishes itself from sibling hmda_validate_uli, which is for validation rather than generation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states the context ('Used for HMDA reporting compliance') and the action (generating a check digit), which implies when to use the tool. However, it does not explicitly mention alternatives or exclusions, such as 'use hmda_validate_uli to validate an existing ULI.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• isone_loadA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description adds 'real-time 5-minute' and regional scope, which goes slightly beyond the annotation. However, it does not disclose limitations such as whether historical data is accessible, update frequency details beyond 'real-time', or any response format expectations, keeping transparency modest.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, the first stating exactly what the tool does with a leading verb and resource, the second giving necessary geographic context. No filler or redundant detail—every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only tool with no output schema, the description fully conveys the data source, the metric (system load/demand), the real-time nature, and the geographic region. There is nothing missing that would prevent an agent from correctly invoking it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, and the schema is empty, so parameter semantics are not applicable. Per the rubric, a baseline of 4 is given since no parameters exist to document; the description adds no parameter information because none is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get current ISO New England system load (demand)' and immediately distinguishes its real-time 5-minute nature. It also states the geographic scope (six states), clearly differentiating it from siblings like isone_fuel_mix.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies usage for current real-time load data but does not explicitly mention alternatives or when not to use it. The context is unambiguous—this is for ISO-NE demand—so an agent would not confuse it with other tools, but no exclusions are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jpl_small_bodyA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true. The description adds value by specifying the return categories: identity, orbital elements, physical parameters, and close approach data. This tells the agent what informational payload to expect, beyond the schema solely describing input. It does not mention rate limits or failure modes, but for a straightforward read-only lookup this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences plus examples. The first sentence immediately states the purpose and input method, the second covers return content. No fluff, 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.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter lookup with no output schema, the description adequately covers what the tool returns (identity, elements, physical properties, close approaches) and provides realistic examples. The readOnly annotation covers safety. There is no hidden complexity requiring further elaboration.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has full coverage (100%) including the parameter description and examples. The description's examples ('Apophis', '2023 DW') are also present in the schema property description, so the description adds no new parameter-level meaning beyond the schema. Baseline 3 is appropriate because the schema already does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Look up') and resource ('asteroid/comet orbital data'), and the scope (by name, designation, or SPK-ID) distinguishes this from sibling tools like jpl_close_approaches which focus solely on close approach data. The purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: use when you need orbital data for a known small body, with 'Apophis' or 'Bennu' as examples. It doesn't explicitly exclude alternatives or mention sibling tools like nasa_neo, but the usage situation is evident from the description and tool name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• loc_collectionsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already establishes it as a safe read operation. The description adds value by stating the return fields (names, descriptions, item counts) and the 'all' scope, which implies a potentially large response but not pagination details. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action, and each sentence adds necessary information. There is no waste or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool with no output schema, the description is complete. It fully conveys what the tool does and what the response will contain, which is sufficient for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema provides no room for ambiguity. The description does not need to explain parameters; the baseline of 4 is appropriate given the no-parameter context and complete schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and clearly identifies the resource ('all Library of Congress digital collections'). It distinguishes this from sibling tools like loc_collection_browse by emphasizing the 'all' scope and the metadata returned.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for getting an overview of collections, but does not explicitly contrast with alternatives such as loc_collection_browse or loc_search. No when/when-not guidance is provided, though the simple nature of the tool makes this less critical.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_traffic_signsA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that it shows 'current messages' and lists example content types, but doesn't disclose additional behavioral traits like data freshness, source, or formatting. Given the annotation coverage, this is acceptable but not exceptional.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with the primary action front-loaded: 'Get dynamic message sign (DMS) content on Maryland highways.' The second sentence adds useful examples without waste. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only tool with no output schema, the description is complete: it states exactly what data is returned (DMS content) and the scope (Maryland highways). The simplicity of the tool is matched by a sufficient description, and no critical information is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description needs no parameter explanation, and the empty schema is fully accurate. No additional semantic burden on the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Get dynamic message sign (DMS) content on Maryland highways' with a specific verb and resource. It further clarifies the content types ('alerts, travel times, events') and distinguishes it from sibling Maryland traffic tools like incidents or cameras.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: when you need current DMS messages on Maryland highways. It does not explicitly mention exclusions or alternatives, but the purpose is unambiguous enough that an agent would know to use this tool for electronic sign content.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_traffic_speedsA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the data content (average speed, traffic volume, lane occupancy) but does not disclose other behavioral aspects such as time ranges, pagination, or output format. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each serving a purpose: the first states the action, the second details the data content, and the third clarifies the use case. No redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema tool, the description fully covers what the tool does, what data it returns, and its practical application. It is sufficiently complete for an agent to select and invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters, the schema has 100% coverage vacuously, and the description needs to add no parameter-level detail. The baseline for no-parameter tools is 4, and the description provides enough context about the data returned.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'Get speed sensor data from Maryland highways.' It further specifies the data types (average speed, traffic volume, lane occupancy) and clearly distinguishes it from sibling traffic tools like md_traffic_incidents or md_traffic_cameras.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool ('Useful for identifying congestion and travel conditions') but does not explicitly mention alternatives or when not to use it. This meets the 'clear context, no exclusions' tier.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mn_lake_searchA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description need not repeat that. It adds valuable context by listing return fields (IDs, names, counties, acreage, max depth) and explaining the relationship with mn_lake_detail. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences, each serving a distinct purpose: purpose, return fields, and next step. No filler or redundant information, front-loaded with the core action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 compensates by listing return fields and pointing to the detail tool. Combined with the readOnlyHint annotation, an agent has everything needed to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with the parameter 'name' already described with examples. The tool description adds the context that searching is by name but does not provide additional syntax or format details beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Search') with a clear resource ('Minnesota lakes') and scope ('by name'). It differentiates from sibling mn_lake_detail by explicitly directing users to use the lake ID with mn_lake_detail for full information, and the tool name itself implies differentiation from mn_lake_nearby.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  States when to use (search by name) and provides a clear follow-up step (use lake ID with mn_lake_detail). It does not explicitly mention using mn_lake_nearby for location-based searches, but the context is clear enough for an agent to infer the tool's role.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhtsa_recall_detailA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true in annotations, the description adds value by specifying the return content: 'full recall information including affected vehicles, summary, consequence, and remedy.' It also provides campaign number format guidance. No mention of error handling or invalid inputs, but the annotations already cover the safety profile, so the added behavioral context is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences, each contributing essential info: what the tool does, the parameter format, and what the response includes. No wasted words, and the key information is front-loaded in the first sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple one-parameter detail lookup with no output schema. The description adequately compensates by listing the main return fields (affected vehicles, summary, consequence, remedy). It is complete for the tool's complexity and gives the agent enough information to understand what to expect without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema description already provides the campaign number format and examples. The description repeats similar examples ('23V838000', '12V176000'), so it does not add meaningful additional semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves recall details by NHTSA campaign number, using the specific verb 'get' and identifying the resource. The campaign number format examples ('23V838000', '12V176000') further clarify the scope, distinguishing it from other NHTSA tools like nhtsa_recalls or nhtsa_safety_rating_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it evident that this tool is for looking up a specific recall given a campaign number, with format examples. However, it does not explicitly mention alternatives like nhtsa_recalls for searching, so exclusions are not stated. The context is clear but not fully explicit about 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.

• nhtsa_safety_ratingsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful context beyond annotations: it states the output includes vehicle variants with VehicleId, explains the rating scale (5 highest, 1 lowest), and notes data availability from 1990 to present. This is meaningful behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences long, front-loaded with the primary purpose, followed by practical usage guidance, and a brief reference note. Every sentence earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple query tool with no output schema, the description adequately covers the return value (vehicle variants with VehicleId), the rating scale, data availability, and a clear next step. This is complete given the tool's complexity and the presence of readOnly annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the schema already describes each parameter with examples. The description only reinforces that the search is by make, model, and year, adding no new syntax or format details. Per the rubric, a baseline of 3 is appropriate when schema handles parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches NHTSA 5-star safety ratings by make, model, and year. It specifies the exact resource (NCAP safety ratings) and the scope, and it distinguishes itself from the close sibling nhtsa_safety_rating_detail by noting that it returns VehicleIds for subsequent detail lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance to use the returned VehicleId with nhtsa_safety_rating_detail, which highlights an alternative and a recommended workflow. However, it doesn't explicitly state when not to use this tool or mention other NHTSA tools, so it's clear context but lacks a full exclusion list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• noaa_datasetsA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the safe read-only nature. The description adds useful context about the types of datasets included, but it does not describe return format, pagination, or other behavioral traits. With annotations present, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that includes both the action and concrete examples. No wasted words; every element earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool with no output schema, the description is fully adequate. It states what the tool lists and gives examples of the dataset types, which is sufficient for an agent to understand its purpose and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema coverage is trivially 100%. Per the rubric, a no-parameter tool gets a baseline of 4. The description does not need to explain parameters since there are none.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('available NOAA climate datasets'), and provides concrete examples (GHCND daily, GSOM monthly, GSOY annual, normals). This clearly distinguishes it from sibling tools like noaa_locations, noaa_stations, and noaa_climate_data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies this tool is for discovering available datasets before querying climate data. The verb 'List' and the resource scope establish clear context for when to use it, though it does not explicitly name alternative tools or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nps_parksA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description needs to add context beyond that. It contributes useful behavioral details: the tool returns specific fields (names, descriptions, states, coordinates, weather) and that it serves as a park code discovery mechanism. This is more than the minimal scoping info, hence a 4.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with the primary purpose, followed by return fields and use case. Zero filler words, every sentence adds information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity, no output schema, and complete schema descriptions, the description fully covers what the tool does and why to use it. It lists return fields and the central use case (park code discovery), making it self-sufficient for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 four parameters. The description adds a high-level mapping ('by state, name, or keyword') but doesn't provide additional syntax or behavioral details beyond what the schema offers. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Search'), identifies the resource ('national parks'), and states the search dimensions ('by state, name, or keyword'). It also distinguishes itself from sibling NPS tools by noting it is used to 'discover park codes needed by other NPS tools.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states when to use this tool: 'Use this to discover park codes needed by other NPS tools.' This provides a clear context and rationale for preferring it over alternatives. It does not explicitly mention exclusions or 'when not to use,' but the purpose is well-scoped.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ofac_exportsA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds little beyond the readOnlyHint annotation. It states the tool lists exports, which is consistent with a read operation, but does not describe any additional behavior (e.g., pagination, format details). With annotations covering safety, this meets the baseline but offers limited extra context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no filler. Every word adds meaning, and it is front-loaded with the action verb and object.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only listing tool, the description completely conveys the tool's functionality. No output schema is present, but the description adequately communicates the return concept (a list of available exports and formats).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and schema coverage is 100%, so the description does not need to explain parameter details. The baseline for 0-param tools is 4, and the description appropriately focuses on what the tool returns.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and clearly names the resource ('available OFAC sanctions data export files and formats'). It distinguishes this tool from sibling OFAC tools like 'ofac_search' or 'ofac_sdn_list' by focusing on discovering available exports rather than querying sanctions data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Purpose implies when to use: when you need to see available export files and their formats. While it does not explicitly name alternatives or exclusions, the context is clear enough for an agent to select this over more specialized OFAC tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• open_payments_by_hospitalA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds that the output is aggregated totals ('Shows total pharma payments'), which clarifies the behavioral scope. This is useful context beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, the first states the core action, the second adds use case. No waste, front-loaded with essential information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description explains what the tool returns (payments grouped by hospital), its scope (teaching hospitals), and its usefulness. With no output schema and a single documented parameter, this is 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description covers the single 'limit' parameter at 100% ('Number of hospitals (default 20)'), so the description does not need to add parameter details. The tool name and description convey the grouping context, but no additional parameter semantics are provided beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets payments grouped by teaching hospital, using a specific verb and resource. It distinguishes itself from siblings like open_payments_by_physician and open_payments_by_company by focusing on the hospital grouping.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides context for use ('useful for identifying institutional conflicts of interest') but does not explicitly mention when not to use it or name alternative tools. This is clear context without explicit exclusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openstates_legislatorsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, and the description adds useful behavioral context by listing the returned fields (legislator names, parties, chambers, districts, contact info) and filter options. It does not disclose pagination behavior, but with the schema covering page/limit and annotations covering safety, the added value is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: two sentences that introduce the action, scope, filters, and return contents. Every sentence adds value, and there is no extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential aspects: what the tool searches, the geographic scope, available filters, and the type of data returned. Together with the 100% schema coverage and the read-only annotation, it provides a complete picture for a search tool of moderate complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 provides a small amount of extra semantics by mapping 'jurisdiction' to state filter and mentioning 'name' filtering, but the schema already fully documents each parameter. No significant addition beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Search' with a clear resource ('state legislators'), and states the scope ('across all 50 states'). It also distinguishes from the sibling tool 'openstates_bills' by focusing on legislators, and 'congress_search_members' by explicitly limiting to state level.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by specifying that it searches all 50 states and allows filtering by jurisdiction and name. It does not explicitly mention when to prefer alternate tools, but the scope is sufficiently clear to avoid misuse.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pubmed_databasesA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already set readOnlyHint: true, so the read-only nature is disclosed. The description adds that it lists 'all available' databases, which clarifies the exhaustive scope, and notes the tool's purpose of discovering databases 'beyond PubMed'. However, it does not disclose return format, pagination, or any limitations (e.g., whether 'all' truly means complete). Given the annotation coverage, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states the core function, the second gives practical use. No wasted words, information is front-loaded, and it is easy to parse. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, zero-parameter, read-only listing tool with no output schema, the description fully covers what the tool does and when to use it. It names the resource, gives examples, and states its purpose. There are no hidden parameters or complex behaviors to explain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description does not need to explain any. The schema coverage is 100% (empty properties). The description adds value by giving examples of what will be listed, but there is no parameter semantics to clarify. Per the rubric, 0 params gives a baseline of 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: 'List all available NCBI Entrez databases (PubMed, PMC, Gene, Protein, etc.)'. The verb 'List' and resource 'NCBI Entrez databases' are specific, and the examples make the scope unambiguous. It also distinguishes this from sibling tools like pubmed_search or pubmed_fetch, which operate on specific databases rather than listing them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: 'Useful for discovering which NCBI databases exist beyond PubMed.' This implies when to use the tool (when you need to know available databases) and hints at its scope relative to other PubMed tools. It does not explicitly name alternatives or exclusions, but for a simple list tool with no parameters, this is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• rec_facilitiesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds genuinely useful behavioral context: it returns facility names, types, locations, and IDs, and explains how to use those IDs downstream with rec_campsites. This goes beyond simple read-only labeling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences deliver the essential information without redundancy. The first sentence states the core purpose, the second covers filters, and the third explains return values and next steps. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with five optional parameters and no output schema, the description is complete: it explains scope, filtering options, return fields, and cross-tool usage. Pagination is already documented in the schema, so no additional detail is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already has 100% description coverage for all five parameters, so the schema is the primary source. The description reinforces the filter parameters (keyword, state, activity) but does not add new constraints or clarify formatting beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Search federal recreation facilities' and lists concrete examples (campgrounds, parks, trails, lakes). It clearly distinguishes this tool from the sibling rec_campsites by noting facility IDs should be used there next.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear filtering context (keyword, state, activity type) and explicitly ties results to rec_campsites via IDs. It does not state when not to use the tool or contrast with rec_areas, but the relationship to rec_campsites is a strong usage signal.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• septa_bus_viewA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds meaningful context by listing return fields (GPS coordinates, vehicle ID, direction, destination, delay), which is especially important given the absence of an output schema. It does not disclose additional behavioral traits like rate limits, but this is not critical for a read-only data retrieval.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loading the action ('Get real-time bus/trolley positions') and then immediately specifying the return content. Every word contributes value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description covers both the required parameter and the full set of return fields. For a simple one-parameter read-only tool, this is sufficient for an agent to select and invoke the tool correctly without additional information.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single 'route' parameter is fully described in the input schema with examples, so schema coverage is 100%. The description merely refers to 'route' generically and does not add significant meaning beyond the schema's own documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Get real-time bus/trolley positions for a SEPTA (Philadelphia) route,' clearly identifying the action, resource, and geographic scope. It differentiates from sibling tools like septa_train_view (trains vs. buses/trolleys) and septa_alerts (positions vs. alerts).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool (to fetch live vehicle positions for a SEPTA route) and implicitly excludes train routes by specifying 'bus/trolley.' However, it does not explicitly name alternatives or state when not to use it, so it falls short of the highest bar.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ssa_beneficiariesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint: true, so the description's job is lighter. The description adds valuable behavioral context by stating that the tool returns links to downloadable datasets (not the data itself) and specifying the geographic breakdown (state, county, ZIP). This goes beyond the annotation and helps the agent set expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two sentences. The first sentence front-loads the action and subject, and the second sentence explains the output format and scope. Every word contributes; there is no redundancy or irrelevant detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless tool with a readOnly hint, this is complete. It states the data domain (OASDI and SSI), the output type (links to downloadable datasets), and the coverage (by state, county, and ZIP). No output schema exists, but the description adequately describes the return value. No further context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. There are no parameter semantics to explain; the description is not lacking anything in this regard.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'Get SSA OASDI and SSI beneficiary data resources', providing a specific verb and resource. It further clarifies that the tool returns links to downloadable datasets by state, county, and ZIP code, which distinguishes it from other data-fetching tools and clearly communicates its function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: when one needs links to SSA beneficiary datasets by geographic area. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention any exclusions or when not to use it. The usage guidance is implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_listA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful behavioral detail about what the output contains (Socrata portals, dataset category counts, GIS availability). This goes beyond the annotation while remaining consistent with a read-only overview tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences: purpose, key output details, and usage guidance. No filler or redundancy; information is 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.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, read-only list tool with no output schema and one optional parameter, the description fully covers what the tool does, what information it returns, and when to use it. The optional parameter behavior is handled by the schema. No gaps are apparent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single optional parameter 'state' has 100% schema description coverage ('Optional: show detailed coverage for a specific state code'), so the description does not need to repeat it. The tool description implies the parameter's purpose in context ('before querying a specific state') but does not add new semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all US states in the registry with their data coverage. It distinguishes itself from siblings like state_query or state_crime by focusing on the registry overview rather than detailed state data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance: 'Use this to see what data is available before querying a specific state.' It implies the alternative of querying a specific state directly but does not name a specific sibling tool or provide 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.

• usace_locationsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotation, the description discloses the return fields ('Returns location name, coordinates, type, state, and county') and provides office code-to-city mappings, which helps set expectations. It does not mention limits or pagination, but the added context is valuable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loaded with the core action and followed by useful domain details (office codes) and return fields. Every sentence adds value with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with optional parameters and no output schema, the description covers the purpose, parameter usage guidance, and return fields. Coupled with the readOnlyHint annotation and full schema description coverage, it provides sufficient context for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all parameters with 100% coverage, including the office codes and wildcard support in names. The description adds city names for office codes, which is a minor enrichment, but it does not substantially go beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search CWMS monitoring locations by name, office, or type.' This identifies the action (search), the resource (CWMS monitoring locations), and the search criteria. It also lists the return fields, which distinguishes it from sibling tools like usace_timeseries and usace_levels that would handle data, not location metadata.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on what can be searched and includes a helpful list of valid office codes with corresponding city names. It does not explicitly compare to alternative tools or state when not to use it, but the context is sufficient for an agent to understand typical use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• uspto_application_detailsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that it returns 'all metadata' along with a specific list of fields, giving agents a concrete sense of what to expect in the response. No contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences. The first states the action and object, the second elaborates on the return fields. No wasted words or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With a single well-documented parameter and read-only annotation, the description sufficiently covers what the tool does and what it returns. The field list compensates for the absence of an output schema, making this complete for a simple lookup tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers the single parameter fully, with description and format examples for both regular and PCT numbers. The tool description adds no further parameter details, so the baseline of 3 for high schema coverage is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool retrieves full patent application data by application number, listing key metadata fields. This distinguishes it from related sibling tools like uspto_search_applications (search) and uspto_application_assignments (assignments).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The use case is clear: when you have an application number and need comprehensive details. It doesn't explicitly name alternative tools or exclusions, but the focus on 'full data' implies this is the detail endpoint versus search. No misleading guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• uspto_search_applicationsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already declares this as a safe read operation, lowering the bar for behavioral disclosure. The description adds useful context: it uses the POST method, supports OpenSearch DSL syntax, and that an empty search returns recent applications. No contradiction with annotations; it enriches beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, efficiently front-loaded with the core purpose and syntax details, followed by filter semantics and default behavior. Every sentence contributes essential information without redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex 8-parameter search tool, the description plus fully-covered schema is nearly complete. It provides the critical query syntax and default behavior, but does not describe the return format or pagination details. However, since the schema documents all parameters and this is a search tool, the description is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed examples for each parameter. The description adds significant value by explaining the q parameter's full syntax (booleans, wildcards, exact phrases, ranges, comparisons) and clarifying how filters and range filters work. This goes beyond the individual parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it 'Search USPTO patent applications' with a specific verb and resource. It distinguishes itself from sibling tools like uspto_application_details by focusing on search rather than retrieving a specific application. The mention of ODP query syntax further specifies the tool's scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on how to construct queries, filters, and range filters, and notes that all params are optional. However, it does not explicitly state when to use this tool versus alternatives like uspto_application_details or uspto_application_continuity. No exclusions or alternative tool mentions are present.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wb_countriesA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already discloses the safe read-only nature. The description adds the returned fields but provides no additional behavioral details such as ordering, pagination, or data completeness. With annotations covering the safety profile, this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It fully conveys the tool's purpose and output in minimal space.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless list tool with no output schema, the description sufficiently explains what the tool returns (countries with region, income level, and capital city). No additional context is needed for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters, so the description does not need to explain parameter semantics. The baseline for zero-parameter tools is 4, and the description provides all necessary context about what is returned.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (List), resource (World Bank countries), and the specific fields returned (region, income level, capital city). It distinguishes this from sibling tools like wb_indicator and wb_search, 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context that this tool is for retrieving country reference data, but it does not explicitly state when not to use it or mention alternative tools. However, with zero parameters and a specific list purpose, the usage is straightforward.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• calc_suggestA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral details on top: 'Uses contains matching (2 char min)'. This clarifies how the prefix parameter is interpreted, which goes beyond the annotation. No contradiction with the read-only hint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with purpose and then usage/behavior details. Every sentence earns its place; no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter, read-only suggest tool with no output schema, the description covers purpose, usage context, and key matching behavior. It does not explicitly describe the return format, but the purpose ('suggest values') implies the response shape enough for an agent. Minor gap only.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers both parameters (100% coverage), so baseline is 3. The description adds the crucial 'contains matching' behavior for the prefix parameter, which is not specified in the schema. The listed fields in the description align with the enum values, providing a slight interpretive boost.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('autocomplete/suggest'), identifies the resource ('GSA CALC+ data'), and specifies the fields (labor categories, vendor names, contract numbers). It distinguishes itself from the sibling calc_search_rates and calc_contract_rates by positioning itself as the suggestion/autocomplete helper.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly notes that the tool is useful for finding exact values to use in calc_search_rates, giving a clear when-to-use context. However, it does not explicitly mention alternatives or exclusions, so it falls just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_life_expectancyA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds the important behavioral limitation that data only goes through 2018, which is critical for setting user expectations. It does not mention pagination or default limits, but the core limitation is disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a single clear sentence stating the main function, a second listing valid values, and a third providing a temporal caveat and an alternative tool. Every sentence serves a purpose without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward lookup tool, the description covers the essential context: the source (U.S. life expectancy), the filters (race, sex), the time range, and a pointer to an alternative for newer data. The lack of an explicit return format is minor since the nature of the data is clear from the name and description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions and enums for all 4 parameters, giving 100% coverage. The description lists the enum values for race and sex, but these are already in the schema, so it adds no new semantics beyond what the schema provides. Thus, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the action ('Get'), the resource ('U.S. life expectancy at birth'), and the dimensions (race and sex) with a clear time range (1900–2018). It also distinguishes itself from sibling tools by explicitly mentioning cdc_mortality_rates as an alternative for more recent data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance by noting data ends in 2018 and directing users to cdc_mortality_rates for more recent mortality trends. This is a clear, actionable alternative that helps an agent choose the right tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cdc_weekly_deathsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so the safe read-only nature is established. The description adds valuable behavioral context: data is provisional (subject to change), updated weekly, covers 2020–present, and includes percent_of_expected_deaths for excess mortality detection. This goes well beyond the minimal read-only annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences. The first sentence front-loads the core purpose, and the second adds high-impact information about data freshness and the excess mortality metric. No words are wasted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Since there is no output schema, the description carries the burden of explaining what data is returned. It names the death categories and the percent_of_expected_deaths field, plus time coverage and update cadence. It does not specify the exact response structure (e.g., one row per week per state), but the essential return information is covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all three parameters (year, limit, state) with 100% coverage, including examples and default behavior. The description does not add further parameter-specific detail, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves weekly provisional death counts by state for specific causes (COVID-19, pneumonia, influenza, and total). It emphasizes the data is the most current CDC mortality data and includes percent_of_expected_deaths, which distinguishes it from sibling CDC tools like cdc_mortality_rates or cdc_causes_of_death.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides strong contextual cues for when to use this tool: when the user needs the most current weekly provisional mortality data, updated weekly, covering 2020–present. It does not explicitly name alternatives or state when not to use it, but the emphasis on 'most current' and 'weekly' clearly signals its intended use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cftc_cot_tffA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares safety, and the description adds a key behavioral constraint: the report covers financial futures only, which is beyond the annotation. It does not detail pagination or output format, but with annotation coverage and schema, the added scope information is valuable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, no wasted words. The tool's purpose, data scope, and use cases are front-loaded. Every phrase earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with 4 fully documented parameters and no output schema, the description covers purpose, scope, and usage examples. It does not explain return structure, but that is not required given the simplicity and annotation coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 meaning by explaining the report categories (Dealer/Intermediary, etc.) and listing example market names (S&P 500, Treasury bonds, VIX) that map to the market_name parameter, going beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with a specific verb+resource: 'Get Traders in Financial Futures (TFF) report data from CFTC.' It clearly distinguishes from sibling CFTC tools by stating 'Covers financial futures only' and listing the report categories, making the tool's scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit usage context: 'Use for S&P 500, Treasury bonds, Eurodollars, VIX, currency futures.' It implies exclusion of non-financial futures via 'Covers financial futures only,' but does not explicitly name alternative tools for those cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clinical_trials_detailA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful behavioral context by listing the returned sections (protocol, eligibility, arms/interventions, etc.) and explaining that fields reduces response size. It does not cover error cases, but the added info is solid.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, with the primary purpose front-loaded, followed by return contents and a usage tip. No wasted words; each sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description adequately covers the main return sections and optional filtering, which is sufficient for a read-only detail tool without an output schema. Minor omissions like missing-ID behavior don't significantly detract.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for both parameters, and the description adds value by explaining the purpose of the fields parameter (request only specific sections, reduces response size) beyond the schema's basic example.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('full details for a specific clinical trial by NCT ID'), and lists the content sections returned. This clearly distinguishes it from siblings like clinical_trials_search or clinical_trials_stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly indicates the tool is for fetching a detail by NCT ID and provides guidance on using the fields parameter for selective requests. However, it does not explicitly mention when not to use it or name alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_full_profileA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behavioral traits beyond the readOnlyHint annotation: it combines four endpoints in parallel and returns a composite profile. It also enumerates exactly what content is included (details, history, subcommittees, website, recent bills, reports, nominations), which adds transparency about the tool's scope. However, it does not discuss edge cases like missing data or pagination beyond the limit parameter, though the schema covers the limit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and concise: the first paragraph front-loads the core purpose and alternatives, while the second paragraph adds an ideal-use case and cross-referencing tip. Every sentence contributes meaningful information without unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a composite read tool with no output schema, the description adequately covers what data is returned and how it differs from calling endpoints individually. It also provides usage context. Minor gaps include not explicitly mentioning the limit parameter's effect or return format, but the schema covers the parameter and the tool is straightforward for a read-only profile.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already documents all three parameters (chamber, committee_code, limit) with descriptions and an enum. The description adds no additional parameter-level detail beyond what the schema provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get a COMPLETE committee profile in ONE call.' It clearly distinguishes this tool from siblings by explicitly naming the four individual endpoints it replaces (congress_committee_details, congress_committee_bills, congress_committee_reports_for_committee, congress_committee_nominations_for_committee), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: 'Use this instead of calling... individually' and 'Ideal for: Understanding a committee's jurisdiction, workload, and oversight activity.' It also suggests a cross-referencing workflow with other tools (congress_member_details, FEC, lobbying_search), giving clear context for when and how to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_house_votesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the data source fallback (Congress.gov to clerk.house.gov XML for older congresses) and coverage range (1990 to present), which are behavioral traits beyond the read-only annotation. It does not contradict the annotations, and the read-only hint aligns with 'Get'.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, with each sentence serving a distinct purpose: purpose, sources, and usage guidance. It avoids filler and front-loads the core function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only vote retrieval tool with a rich schema and no output schema, the description provides a solid overview of sources, coverage, and related data, though it doesn't elaborate on return structure or pagination. The cross-reference guidance adds valuable context for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% descriptive coverage for all five parameters, so the description adds minimal extra parameter detail beyond implying the year parameter for historical votes. Since the schema handles the heavy lifting, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves House roll call votes with member-level party breakdown, and explicitly distinguishes it from the Senate counterpart, naming congress_senate_votes as the alternative. It also specifies the primary source and coverage, leaving no ambiguity about its function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs to use congress_senate_votes for Senate votes, provides a cross-reference list for complementary data, and advises using the year parameter for historical queries. This gives clear when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_nomination_full_profileA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that this is a composite tool combining 4 endpoints in parallel, which adds behavioral context beyond the readOnlyHint annotation. It also clarifies the scope ('complete profile', 'full action timeline'). No contradictions with annotations. Could be more detailed about potential response size or performance, but it provides solid transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: the first sentence delivers the core value proposition, the second clarifies what it replaces, and the third gives use-case context. Every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's composite nature and lack of output schema, the description adequately explains what data is included and when to use it. It mentions the four sub-endpoints and the nomination lifecycle. Minor gap: it doesn't mention whether the response is paginated or large, but the description is sufficient for an agent to select and invoke successfully.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with descriptions for both parameters ('Congress number' and 'Nomination number (PN number)'). The description does not add deeper parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get a COMPLETE presidential nomination profile in ONE call' and enumerates the exact components (nomination details, full action timeline, committee referrals/activity, and associated hearings). It distinguishes itself from sibling tools by explicitly naming the individual endpoints it replaces.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit usage guidance: 'Use this instead of calling congress_nomination_details + congress_nomination_committees + congress_nomination_hearings individually.' It also provides an 'Ideal for' scenario (tracking nominations) and suggests a cross-reference with lobbying_search, giving clear context on when to choose this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_nomination_nomineesA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already declares this is a safe read operation, so the description doesn't need to restate that. It adds useful context about the multi-position ordinals and the prerequisite tool, but it does not disclose return format, pagination behavior, or error conditions. This is similar to the TDQS 4.3 example where annotations cover safety and the description adds some scope context, warranting a 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences. The main verb and resource are front-loaded, followed by a necessary caveat and a clear pointer to the prerequisite tool. There is no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with 4 parameters (3 required), no output schema, and a readOnlyHint annotation. The description covers the purpose, the ordinal context, and the prerequisite workflow. It doesn't explain response format, but the schema covers the limit parameter and the absence of an output schema lowers the burden. It is complete enough for effective use, though slightly less than a fully self-contained description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive text for each parameter (e.g., 'Position ordinal (typically 1)'). The description adds value beyond the schema by explaining why the ordinal is needed ('Some nominations contain multiple positions') and how to discover the correct value ('Use congress_nomination_details first'). This extra context elevates the baseline from 3 to 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get the list of nominees for a specific position within a nomination.' It specifies the verb (get), resource (list of nominees), and context (specific position within a nomination). It also distinguishes itself from siblings like congress_nomination_details by focusing on nominees and referencing ordinals.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: 'Use congress_nomination_details first to see the ordinal numbers.' This tells the agent when and how to use this tool relative to an alternative, including a prerequisite step. It also explains the need for the ordinal parameter with 'Some nominations contain multiple positions (ordinals).'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_summaries_searchA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds value by noting 'Sorted by last update date' and 'Results include the associated bill reference,' which convey behavioral details beyond the schema and annotations. No contradictions found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is five short, information-dense sentences. Each sentence earns its place: purpose, differentiation, filtering, sort order, and result content. No filler or redundancy, and the most critical information (scope and contrast) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 provides useful context about sort order and result contents, but it doesn't specify full return fields or pagination behavior. The limit parameter is documented in the schema, so this is a minor gap. Overall, it gives a solid understanding of what the tool does and returns.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 mentions 'Filter by congress, bill type, and date range,' which groups parameters but adds no new semantics beyond the schema. Each parameter already has a clear description in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Search bill summaries across all bills and congresses,' clearly stating the action and resource. It explicitly contrasts with congress_bill_summaries, which requires a specific bill, thereby distinguishing this tool's broader scope from a sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The sentence 'Unlike congress_bill_summaries (which requires a specific bill), this searches CRS summaries across the entire collection' provides explicit guidance on when to use this tool versus an alternative. It also lists filterable dimensions, giving clear context for typical use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_treaty_full_profileA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is established. The description adds useful behavioral context by revealing it combines '3 endpoints in parallel,' implying potential latency and composite data fetching. It does not describe error handling or response format, but for a read-only composite, this is acceptable and adds value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two efficient sentences plus a short 'Ideal for' line. Key information about the tool's purpose and advantage is front-loaded ('Get a COMPLETE treaty profile in ONE call'), with zero filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a composite tool with no output schema, the description adequately communicates the contents (details, timeline, committees) and the recommended usage. It could be slightly more explicit about what 'full action timeline' entails or any limitations, but the description is sufficient for an agent to decide and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 100% coverage with descriptions for both congress and treaty_number. The description does not add any parameter-specific semantics beyond what the schema already provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get a COMPLETE treaty profile in ONE call' and enumerates the combined components (treaty details, full action timeline, committee assignments). It explicitly distinguishes from sibling tools by naming congress_treaty_details and congress_treaty_committees, making the composite nature obvious.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: 'Use this instead of calling congress_treaty_details + congress_treaty_committees individually.' It also gives concrete use cases ('International agreement research and Senate Foreign Relations Committee tracking'), making alternative selection unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• courtlistener_searchA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint: true in annotations, the safety profile is covered. The description adds useful return-value context: 'Returns opinion metadata including case name, court, date filed, and citation.' It also explains court codes, which helps set expectations. There are no contradictions with the annotations, and the added info goes beyond what annotations alone provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, each earning its place: purpose, filters, court codes, and return fields. It is front-loaded with the core action, and the details are relevant and non-redundant with the schema. No filler words or extraneous content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 5 optional parameters, no output schema, and readOnlyHint annotation, the description covers the essential context: what is searched, what filters are available, the court code format, and the return metadata. It does not mention pagination or the limit default, but these are already in the schema. For a search tool of this complexity, the description is sufficient and helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 meaning beyond the schema by expanding the court codes from the schema's examples ('scotus', 'ca1', 'ca9', 'cadc', 'cafc') to the full set ('ca1'-'ca11') with descriptions of each circuit. This provides richer semantic context for the 'court' parameter. The description also reinforces that 'keyword', 'court', and date range are the primary search axes.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the exact action: 'Search case law opinions across federal and state courts.' It also mentions key filters (keyword, court, date range), which clearly distinguishes it from the sibling tool 'courtlistener_opinion' (which presumably retrieves a specific opinion). The verb 'Search' and the resource 'case law opinions' make the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description says 'Find opinions by keyword, court, or date range,' providing clear context on when to use the tool. It does not explicitly mention alternatives or when not to use it, but the differentiation from 'courtlistener_opinion' is implied by the tool name and overall purpose. No exclusions are stated, which is fine for a search tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cpsc_penalty_searchA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds valuable context beyond the readOnlyHint annotation by emphasizing that penalty_type is mandatory and providing a concrete example of use. The mention of using cpsc_penalty_companies implies that company name inputs must be valid, which is a useful behavioral detail not present in the schema or annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: a one-sentence purpose, a requirement, a cross-reference to a companion tool, and an example. Every sentence earns its place with no filler or redundant restatement of the schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only search tool with 100% schema coverage and no output schema, the description sufficiently covers the searchable fields, required parameter, and companion tool. It omits details like pagination or response format, but these are not demanded by the context signals and the description remains practical for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  While the schema already provides 100% parameter descriptions, the description reinforces the requirement for penalty_type and gives a clear example ('penalty_type='civil', company='IKEA''). This adds practical meaning to the parameter values, especially for users unfamiliar with the domain.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search CPSC penalty records by type, company, product, fiscal year, or ID', which combines a specific verb with the resource. It distinguishes itself from sibling tools like cpsc_recall_search and cpsc_penalty_companies by focusing on penalties and listing distinct search dimensions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states that penalty_type is required, which is a critical usage constraint. It also directs users to cpsc_penalty_companies for discovering valid company names, providing a concrete alternative for one of the parameters. However, it does not explicitly contrast with cpsc_recall_search, but the naming convention makes the intended domain clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cta_bus_arrivalsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, so the description already builds on that safety profile. It adds value by disclosing the return contents (predicted arrival times, route, direction, destination, delay status) and noting that stop IDs are numeric. This sufficiently covers behavior beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the primary action and resource. The second sentence lists return fields and includes a note about stop ID format. No redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with no output schema, the description adequately covers what it does, what it returns, and how to get the input. It could mention error handling for invalid stop IDs, but given the tool's simplicity, the information provided is sufficient for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers stop_id with a clear example and type. The description adds guidance on where to find stop IDs (bus stop signs or the CTA website), which helps the agent obtain a valid value. This is a modest but useful supplement to the schema's 100% coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get bus arrival predictions for a CTA (Chicago) bus stop.' It specifies the resource (CTA bus arrivals) and distinguishes it from sibling rail/transit tools. The scope is precise (CTA bus, not trains or other transit systems).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: when you need CTA bus arrival predictions. It provides practical guidance on obtaining stop IDs (from signs or the CTA website). However, it does not explicitly name alternatives or state when NOT to use this tool, though the CTA-specific wording is clear in context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ecfr_title_structureA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation already declares readOnlyHint=true, so the safety profile is covered. The description adds that the tool returns the hierarchical structure (parts, subparts, sections), which informs the agent about the return content. Since there is no output schema, this is valuable behavioral context. It does not mention potential large payloads or other edge behaviors, but for a read-only structure listing, this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, with a clear first sentence stating purpose, a second sentence giving usage context, and a short list of common titles. No fluff; it's front-loaded with the most important information. The list is a useful addition rather than needless padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (2 params, 1 required) and the description covers what the tool returns (parts, subparts, sections) and when to use it. The annotation covers safety. There is no output schema, but the description provides enough return information. Minor gap: it doesn't clarify whether the output is just headings or includes any metadata, but this is not critical for the tool's purpose.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for both title and date. The description adds a list of common titles with their subject areas, which helps agents select an appropriate title number beyond the schema's generic range. This extra context justifies a score above the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the verb 'Get' and identifies the resource as 'organizational structure of a CFR title,' further specifying it 'shows all parts, subparts, and sections.' This clearly distinguishes it from siblings like ecfr_search (search) and ecfr_section (reading a specific section), especially with the note 'before reading specific sections.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states it is 'useful for browsing what regulations exist within a title before reading specific sections,' giving a clear use case and implicitly pointing to ecfr_section as the follow-up. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_covid_serologyA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations include readOnlyHint=true, and the description consistently describes a search operation. It adds context about the data content (sensitivity/specificity, sample material, manufacturer) and count fields, which is useful beyond the annotation. It does not mention rate limits or result format, but that is a minor gap given the read-only nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: one sentence stating the main purpose, two example queries, and one line mentioning count fields. Every sentence contributes meaningfully, with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter search tool with no output schema, the description covers the core purpose, provides usage examples, and highlights count fields. It lacks explicit details about result structure or pagination, but these are not critical for a straightforward search API and the provided information is sufficient for initial use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both parameters. The description adds value by giving concrete example field values (e.g., 'antibody_truth:"Positive"' and 'manufacturer:"Abbott"') and listing count fields, which enriches the understanding of how to construct queries.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Search COVID-19 serology test evaluation results', specifying the verb and resource. It further clarifies it covers FDA's antibody test performance (sensitivity/specificity), which distinguishes it from other FDA tools like fda_drug_events or fda_device_clearances.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context about what the tool searches and includes example queries to guide usage. However, it does not explicitly state when to use this tool over alternatives or when not to use it, making it solid but not fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_drug_labelsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint: true, so the read-only nature is already known. The description adds value beyond this by showing search syntax, count fields, and the scope of label content, which helps the agent craft effective queries and understand what the search can do.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized: a clear one-line purpose, a brief content list, four illustrative example queries, and count fields. Every section adds useful information without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with two parameters and no output schema, the description is reasonably complete. It explains query syntax through examples, lists content covered, and mentions count fields. Minor omission: no mention of pagination or result format, but the limit parameter in the schema covers result size.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for both parameters (search and limit). The description enhances this by providing concrete search examples (e.g., quoted phrases, _exists_, date ranges) and listing count fields, which give practical meaning beyond the schema's basic field:value description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search FDA drug product labeling (package inserts / prescribing information — SPL)' with a specific verb and resource, and lists contents (indications, warnings, boxed warnings). This distinguishes it from sibling tools like fda_drug_events (adverse events), fda_drug_recalls, and fda_drug_counts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: this tool is for drug labeling, with example searches demonstrating query patterns and specific uses (e.g., brand name, boxed warning, date range). It does not explicitly name alternatives or say 'use this instead of X', but the content focus and examples make the intended use case unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_drug_ndcA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: the dataset has 132K+ records, each entry contains product data, active ingredients, packaging info, and openfda annotations. It also discloses count fields and example query syntax. It does not mention rate limits or pagination, but with read-only annotation the safety profile is clear.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: an overview sentence, a list of searchable fields, example queries with explanations, and count fields. Every line earns its place, and the format makes key information scannable. It is concise given the richness of query-syntax guidance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with no output schema, the description explains the data scope, typical fields, and query patterns. It does not explicitly mention pagination behavior of the 'limit' parameter, but the schema already describes that. Overall, it gives an agent enough context to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (both params have descriptions), so the baseline is 3. The description adds domain-specific search examples for the 'search' parameter and lists count fields, enhancing meaning beyond the generic schema examples. This provides practical guidance on constructing effective queries.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Search the NDC Directory — National Drug Code product listings.' It clearly identifies the tool as a search over drug products and distinguishes it from sibling FDA tools by mentioning the NDC focus and listing searchable fields like brand name, DEA schedule, and pharmacological class.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool via examples like searching for brand names, DEA schedules, and dosage forms. However, it does not explicitly mention alternatives or state when not to use this tool, so it lacks explicit exclusionary guidance relative to siblings like fda_drug_labels or fda_approved_drugs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_nsdeA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description consistently frames the tool as a search operation with no contradiction. It adds behavioral context beyond the annotation by revealing that marketing_end_date presence/absence determines on-market vs. discontinued status via _missing_/_exists_ syntax, which is valuable operational knowledge.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is five compact lines with a clear front-loaded purpose, two search tips, and two examples — every sentence earns its place. There is zero filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 2-parameter search tool with no output schema and full schema coverage, the description covers domain, query syntax for market status, and concrete examples. It doesn't describe result shape or pagination, but given the low complexity and read-only annotation, the gaps are minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, providing a baseline of 3. The description adds value with dataset-specific examples like 'package_ndc:"55700-019-60"' and '_missing_:"marketing_end_date"', which demonstrate real field names and query patterns beyond the generic schema examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Search NDC SPL Data Elements — comprehensive drug product data,' using a specific verb (Search) and a precise resource (NDC SPL Data Elements) that distinguishes it from FDA siblings like fda_drug_labels or fda_drug_ndc. The example queries ('package_ndc:"55700-019-60"') reinforce the domain-specific scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit query patterns: 'Use '_missing_:marketing_end_date' for products still on market' and '_exists_:marketing_end_date' for discontinued products, giving clear context for different search intents. It does not explicitly name alternatives or exclusions among siblings, so it stops short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_substanceA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation; the description adds specific query syntax for this dataset (e.g., names.name, unii, structure.formula), which guides the agent beyond generic schema descriptions. No side effects or hidden behaviors are disclosed, but none are needed for a read-only search.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the purpose, followed by four concrete examples. Every line adds value, and the format is scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only search tool with two parameters and no output schema, the description adequately covers what the tool does and how to query it. It lacks explicit info about response structure, but for a search tool, the search syntax and purpose are the critical parts; the schema handles parameter details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema coverage, the baseline is 3; the description enhances the search parameter by showing domain-specific field syntax (CAS, UNII, molecular formula) beyond the generic OpenFDA query examples in the schema. The limit parameter is already fully documented in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the tool 'Search FDA substance data' and specifies searchable identifiers (name, CAS code, UNII, molecular formula), clearly distinguishing it from sibling FDA tools for events, labels, and NDCs. The example queries reinforce the specific resource and search scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context that this tool is for substance-level ingredient lookups and shows example queries for different identifier types. However, it doesn't explicitly exclude other FDA tools or mention alternatives when a different dataset is needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fdic_search_institutionsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds valuable context beyond this: it clarifies that assets and deposits are in thousands of dollars and provides example filter syntax (e.g., STALP:"CA", ACTIVE:1). This provides useful behavioral information about how to construct queries, though it does not detail response format or pagination behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (four short sentences) and well-structured. It front-loads the main purpose, then lists filter types, shows example syntax, and closes with the units clarification. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description adequately conveys what the tool does, what filters are available, and key units. It does not explicitly describe the response shape, but the 'fields' parameter in the schema hints at returned columns. For a search tool with good schema coverage and annotations, this is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage with descriptions for all 7 parameters. The description adds meaning beyond the schema by explaining that assets and deposits are in thousands of dollars, which is not stated in the schema. It also gives example filter values that illustrate how to use the 'filters' parameter, enhancing comprehension.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches FDIC-insured banks and savings institutions with a specific verb ('Search') and resource ('FDIC-insured banks and savings institutions'). It distinguishes itself from sibling tools like fdic_failures, fdic_financials, and fdic_history by focusing on institution search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes clear the tool is for searching institutions with filters by state, name, charter type, asset size, and active status. It provides concrete filter examples but does not explicitly contrast with alternative tools or state when not to use it, so it lacks explicit exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• foia_reportA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true in annotations, the tool's read-only nature is already disclosed. The description adds contextual behavior by specifying the content included in the report and the dependency on a valid abbreviation from foia_agencies. It doesn't contradict annotations and provides sufficient behavioral context beyond the structured hint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, each contributing value: purpose, data contents, and usage prerequisite. There is no redundant wording, and the main purpose is front-loaded. It is appropriately sized for a simple tool with one parameter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although there is no output schema, the description lists several output categories (request volumes, processing times, backlog, exemption usage, compliance metrics), giving the agent a good sense of the return data. It also points to foia_agencies for the required input. Minor gaps like whether historical years are available are not critical given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers the parameter with 100% coverage, listing example abbreviations. The description enhances this by instructing 'Use foia_agencies first to find the correct agency abbreviation,' which tells the agent how to source a valid value. This extra guidance justifies a score above the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get annual FOIA report statistics for a specific federal agency.' It further enumerates distinct data categories (request volumes, processing times, backlog data, exemption usage, compliance metrics), making the tool's function concrete. This clearly distinguishes it from the sibling tool foia_agencies, which focuses on agency identifiers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides direct usage guidance: 'Use foia_agencies first to find the correct agency abbreviation.' This establishes a prerequisite workflow and implies that this tool is used after obtaining the abbreviation. While it doesn't explicitly list when not to use the tool, the guidance is clear and actionable, meriting a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fooddata_detailA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal readOnlyHint=true, and the description adds useful context about the return payload (calories, protein, vitamins, etc.) and that it is a detail lookup requiring an FDC ID. It does not describe exact response units or error behavior, but the annotation lowers that burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences, each earning its place: what it does, what it returns, and how to get the required ID. Information is front-loaded and there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read tool, the description covers purpose, return scope, and prerequisite workflow. The lack of an output schema is partially offset by enumerating the nutrient breakdown, but exact response formatting, units, and edge cases (e.g., unknown FDC ID) are not addressed. This is sufficiently complete for common usage but not exhaustive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and both the schema and description state that fdcId comes from fooddata_search results. The description reinforces the parameter's source but does not add meaningful semantics beyond what the schema already provides, so a baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb phrase ('Get complete nutritional details') and identifies the exact resource and identifier ('specific food by its FDC ID'). It explicitly distinguishes from search tools by naming fooddata_search and lists the nutrient categories returned, so purpose is unambiguous and distinct from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  'Use fooddata_search first to find FDC IDs' gives explicit sequential guidance and names the alternative/prerequisite tool. This makes the intended workflow and when-to-use clear, which is better than vague context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• isone_fuel_mixA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description states it shows 'real-time megawatt output by fuel category', adding specificity beyond the readOnlyHint annotation by explaining the data granularity and temporal nature (real-time). While annotations already indicate a safe read operation, the description provides useful context about what data is returned without needing to explain return structure since there is 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (two sentences) yet information-dense, front-loading the action ('Get current ISO New England generation fuel mix') and immediately providing detail on the breakdown by fuel type. Every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the zero-parameter, read-only nature of the tool and rich sibling context (e.g., presence of isone_load in siblings), the description adequately covers what the tool does, the data it returns, and the region. It doesn't explain the response format, but with no output schema and a simple data view, this is acceptable. Slight gap: no note on update frequency or data source reliability.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema coverage is 100% (no params). With no parameters, the schema requires no explanation, and the description provides full context by detailing what data the tool returns. The description compensates fully for the empty schema by explaining the data content.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves the current ISO New England generation fuel mix, listing specific fuel types (natural gas, nuclear, hydro, wind, etc.) and specifying the region (New England). This verb+resource+scope construction distinguishes it from siblings like isone_load and ercot_grid_conditions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates this is for current/realtime fuel mix data for New England, which implicitly differentiates it from similar tools like ercot_grid_conditions (Texas) or isone_load. However, it doesn't explicitly state when to avoid this tool or name alternatives, reserving full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jpl_close_approachesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes safety, and the description adds valuable context beyond that: the unit conversion (1 AU ≈ 150M km) and an example invocation. It does not contradict annotations and helps the agent understand the meaning of distance values. It could mention response format or pagination, but the description is still informative.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: three sentences that front-load the core purpose, then provide necessary unit context and an example. Every sentence serves a purpose. It is neither verbose nor under-specified.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity and the presence of a detailed schema, the description covers the essential details: what it does, how to filter, units, and an example. It does not state the return type, but 'close approaches' implies a list. For a read-only query tool, this is sufficient, though a note on the output format could make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, so parameters are already well-documented. The description adds a concrete example showing the combined use of date_min, date_max, and dist_max, which helps clarify parameter interaction. The unit conversion is also reinforced, though partially redundant with the schema. This adds practical value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Get asteroid/comet close approaches to Earth.' This clearly differentiates from sibling tools like jpl_small_body or jpl_fireball. It states the exact subject and action, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: filtering by date range, distance, and result limit. It does not explicitly mention alternatives or when not to use the tool, but the context is unambiguous. The example usage further clarifies how to combine parameters, giving an implicit 'how to use' guide.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• marta_train_arrivalsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint: true, and the description adds meaningful behavioral context: 'real-time', 'all stations', 'all active trains across the entire MARTA rail network', and details the returned data fields. This goes beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states the primary function and scope, the second lists the output fields. Every sentence provides useful information, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description effectively explains what the tool returns (destination, direction, line, station, arrival time, wait seconds, GPS). It could mention the output structure (e.g., array of predictions), but for a zero-parameter read-only tool, it is sufficiently complete for an agent to use correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, and schema coverage is 100%, so there is no parameter documentation burden. The description correctly omits parameter details, and no parameter semantics are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get real-time MARTA rail arrival predictions') and names the resource ('all stations in Atlanta, GA'), clearly distinguishing it from sibling transit tools. It also enumerates the returned fields, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is specifically for MARTA rail arrivals across the entire network. It does not explicitly mention alternatives or when not to use it, but the scope is unmistakable, differentiating it from other transit arrival tools in the sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_traffic_travel_timesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description correctly describes a read operation. It adds value by detailing exactly what data is returned (travel time vs free-flow, average speed, route distance), which goes beyond the annotation. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the main action, no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, read-only tool, the description is sufficient to understand what data is returned and the geographic scope. With no output schema, the description provides the key fields. Minor ambiguity about which 'major' highways are included, but overall complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description carries no burden for parameter semantics. Baseline 4 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' with a clear resource ('travel time data for major Maryland highway routes') and distinguishes itself from sibling tools by focusing specifically on travel metrics (travel time, free-flow time, average speed, distance) rather than incidents or closures.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool—whenever travel time data for Maryland highways is needed—but it does not explicitly name alternatives or exclusions. However, the specificity of the data (travel time vs speed vs incidents) makes the usage context unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_transit_feedsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations already declaring readOnlyHint=true, the description adds useful behavioral context by specifying output formats (ZIP archives with GTFS CSVs, protobuf) and the included modes. It does not cover rate limits or response structure, but for a parameterless URL lookup, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four sentences, each delivering a distinct piece of information: purpose, static data format, modes, and real-time feed URLs. There is no redundancy or filler; the description is tightly written and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there is no output schema, the description covers the essential content: static schedule URLs, modes, and real-time feed URLs. It would benefit from a sample response structure, but the tool's simplicity means the description is reasonably complete for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and schema coverage is 100% (vacuously), so the baseline is 4. The description appropriately avoids discussing parameters and focuses on the output, which is all that is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get Maryland MTA GTFS feed URLs for all transit modes,' naming the specific agency, resource type, and scope. It also enumerates the modes and differentiates static schedule downloads from real-time feed URLs, clearly distinguishing it from sibling tools like md_transit_vehicles or md_transit_trip_updates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it clear that this tool returns feed URLs rather than actual transit data, implying when it should be used (to obtain endpoints). However, it does not explicitly name alternative tools or provide exclusions, so the guidance is clear but not fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• naep_gap_variable_yearsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, so safety is covered. The description adds behavioral detail by specifying return fields (innerdiff1, innerdiff2, and the gap between them) and clarifying that it computes group gaps for two years. This adds value beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences: purpose, example, return description. Every sentence is informative and there is no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description compensates by explaining the return values. It also provides an illustrative example. It doesn't cover edge cases like ordering, but given the schema covers parameters, this is adequate for most uses.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are documented. The description enriches 'years' by explaining focal and target year semantics, and helps understand the output mapping. This lifts it above the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool compares achievement gaps between demographic groups over time, with a specific verb 'compare' and resource 'achievement gaps'. It distinguishes from siblings like naep_compare_years and naep_compare_groups by focusing on gap change over time, and includes a concrete example.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides a clear context with an example ('Is the racial achievement gap in reading getting bigger or smaller since 2017?') indicating when to use. However, it does not explicitly name alternatives or exclusions, so it stops short of full usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhtsa_complaintsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true already provided by annotations, the description adds the important context that all three params are required by the NHTSA API, signaling an external constraint. The example further clarifies expected input format, though it doesn't disclose return structure or pagination.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences and an example, no filler. The most critical information (verb, resource, parameters, requirement, helper tool) is front-loaded and every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with 3 params and no output schema, the description covers the essential operational details: required params, helper sibling, and an example. It stops short of describing response fields, but that may be acceptable given the sibling nhtsa_complaint_detail exists for individual records.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and descriptions exist for each parameter. The description adds a concrete example (make='tesla', model='model 3', model_year=2023) and reinforces that all parameters are mandatory, which aids correct invocation beyond the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'Search NHTSA vehicle complaints by make, model, and model year' with a specific verb and resource, distinguishing it from sibling tools like nhtsa_recalls and nhtsa_complaint_detail. It also includes a concrete example, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly communicates that all three parameters are required, preventing invalid calls, and points to nhtsa_models for finding valid models. While it doesn't explicitly exclude alternative tools, this guidance is sufficient for correct usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhtsa_model_yearsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare readOnlyHint=true; the description adds behavioral context by stating that it lists years with recalls or complaints and by giving the 1949–present date range for recalls. This goes beyond the structured annotations, though it does not describe return format or pagination.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short, front-loaded sentences with zero filler. Every sentence earns its place: what the tool does, how to set the key parameter, and when to use it.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only listing tool with one param and no output schema, the description conveys purpose, parameter behavior, and use case. It could mention the exact output shape or empty-result behavior, but that is not strictly necessary for an agent to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema already documents issue_type enum (r/c) with descriptions at 100% coverage. The description adds extra semantic value by clarifying usage with concrete examples and the recall date range, helping the agent map the parameter to real-world meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description opens with a specific verb and resource: 'List model years that have recalls or complaints in the NHTSA database.' This clearly differentiates from sibling NHTSA tools like nhtsa_recalls (which return recall records) and nhtsa_makes/models (which return other catalogs).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit direction on when to use it: 'Useful for discovering available data before querying' and how to choose issue_type ('r' for recalls, 'c' for complaints). It does not explicitly name alternative tools or exclusions, but context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhtsa_recallsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds the constraint that 'All three parameters are required by the NHTSA API,' which is useful contextual behavior beyond the annotation. It does not contradict annotations, though it does not detail return format or pagination.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences plus a concrete example. The main purpose is front-loaded, and every sentence earns its place by adding required-parameter info, alternative tool references, or an illustrative example.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search tool with readOnlyHint and complete schema, the description adequately covers purpose, required parameters, alternatives, and an example. Since there is no output schema, a fuller description of the return shape would be ideal, but the tool is straightforward and the existing context is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has 100% coverage with descriptive property text and examples. The description's example mirrors schema values ('tesla', 'model 3', 2024) and does not add meaning beyond what the schema already provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description opens with a specific verb+resource: 'Search NHTSA vehicle recalls by make, model, and model year.' It clearly defines the tool's scope and distinguishes it from siblings by pointing to nhtsa_recall_detail for specific campaigns.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states that all three parameters are required, and names alternatives: 'Use nhtsa_models to find valid models for a make, or nhtsa_recall_detail for a specific campaign.' This provides clear when-to-use guidance and alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nih_spending_by_categoryA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, and the description adds meaningful behavioral details: it 'Uses RCDC spending categories with an agency-based fallback for more accurate counts' and returns 'estimated funding', indicating approximate values. This goes beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three tightly written sentences plus a note: purpose, methodology, and alternative. Every sentence earns its place and there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-param read-only tool, it clearly conveys what the tool returns (project counts and estimated funding), common category IDs, and an alternative. Minor gaps: how to discover non-common category IDs or a more detailed output shape, but these are not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema already covers both parameters with descriptions and examples (100% coverage), but the tool description enhances them by listing additional common category IDs (e.g., 30=Cardiovascular, 85=Mental Health) and explaining the agency-based fallback, which gives extra semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get NIH project counts and estimated funding for a disease/research area across fiscal years', naming a specific verb, resource, and scope. It also distinguishes itself from the sibling nih_projects_by_agency by suggesting that tool for more reliable disease-area counts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for use: it retrieves category-based spending across fiscal years. It explicitly names an alternative (nih_projects_by_agency) and when to consider it ('For the most reliable counts by disease area'), but stops short of a full when-not-to-use statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nrel_utility_ratesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the read-only nature is already known. The description adds transparency by disclosing the output content: the local utility and rates in $/kWh. It also implies the tool performs a geographic lookup to identify the applicable utility, useful behavioral context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with the key action and input requirement front-loaded. Every phrase adds value: the types of rates, the geographic scope, and the unit of rate output. No redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with only two required parameters and no output schema. The description provides enough context for an agent to select and invoke it: it covers the data type (electricity rates), the return unit, and the input format. It does not specify if all three rate classes are always returned, but given the description lists them, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with examples in parameter descriptions, giving the baseline of 3. The description adds semantic value by explicitly tying the coordinates to the lookup of the local utility, clarifying that the parameters are not just numbers but geospatial locators. This exceeds the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 ('residential, commercial, and industrial electricity rates for any U.S. location'). It distinguishes itself from sibling tools like nrel_solar and nrel_fuel_stations by scoping to utility rates, and also notes the input coordinate system.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states the required input ('Provide latitude/longitude') and the expected outcome ('to get the local utility and their rates'), giving clear context for when to use the tool. It does not explicitly mention alternatives or exclusions, but the 'any U.S. location' phrasing and focus on rates makes usage conditions unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nws_forecastA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation is consistent with the 'Get' verb. The description adds useful behavioral context by specifying the return content: 'Returns forecast periods with temperature, wind, and conditions.' It also clarifies that lat/lon auto-resolves the grid, complementing the schema description.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loaded with the main purpose. Each sentence adds value: what it does, how to invoke it, and what it returns. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 5 parameters and no output schema, the description compensates by covering both input modes and describing the return structure. It could mention units or timezone, but for a read-only weather forecast with clear annotations, this is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing descriptions for each parameter. The description adds crucial semantic meaning by stating the EITHER/OR relationship between the two input groups, which is not evident from individual schema descriptions and helps avoid invalid combinations.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get 7-day weather forecast.' This clearly states what the tool does and the 7-day scope distinguishes it from sibling nws_forecast_hourly. No ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly explains two mutually exclusive input modes: office+grid coordinates (from a point lookup) OR latitude/longitude to auto-resolve. This gives clear when-to-use guidance for parameter selection. However, it does not explicitly mention alternatives like nws_forecast_hourly when hourly data is needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nws_radar_stationsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds useful behavioral context by listing the kind of data returned (station IDs, names, types, and coordinates). The readOnlyHint annotation already signals a safe read operation, and the description enriches that without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences: the first states the action and scope, the second enumerates the output fields. Every word contributes value and there is no unnecessary detail or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter list tool with a readOnly annotation and no output schema, the description covers purpose, scope, and result content. A mention of potential pagination or output format would improve completeness, but it is not essential for this simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters in the schema, so parameter semantics are not a concern. The baseline for zero-parameter tools applies, and the description's mention of returned fields provides sufficient semantic context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('List'), a specific resource ('NWS radar stations'), and geographic scope ('across the U.S.'). It distinguishes itself from sibling tools like nws_stations by focusing on radar stations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly sets the context for when to use this tool: when a list of NWS radar stations in the U.S. is needed. It does not explicitly mention alternatives or exclusions, but for a simple zero-parameter list tool its usage is readily inferable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opm_status_typesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds that it returns reference data for a fixed set of categories, with examples. This is helpful but doesn't disclose additional behavioral details such as return format or pagination, though those are less critical for a simple parameterless list.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences; the first states the purpose and the second enriches with examples. Every sentence earns its place, with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless read-only tool with no output schema, the description sufficiently conveys what data is returned and what the values look like. It doesn't explain integration with other OPM tools, but that's not required for this simple reference endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is empty (0 parameters), and schema description coverage is 100%. The description adds no parameter-specific details, but with no parameters the schema needs no further explanation, so the baseline of 4 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb ('List') and resource ('all possible federal government operating status types'), and the second sentence clarifies it returns reference data for named categories. This distinguishes it from sibling tools like opm_current_status and opm_status_history, which report current/historical status rather than the enumerated set.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly positions the tool as a reference-data list ('List all possible...') and gives examples of status categories, allowing an agent to infer when to use it. However, it doesn't explicitly mention alternative tools like opm_current_status or opm_status_history, nor provide exclusion criteria, so it stops short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pubmed_fetchA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by specifying the return content ('title, authors, affiliation, and abstract body') and available formats ('plain text or XML'), which goes beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences with no redundancy. The first states purpose, the second details output, and the third gives usage guidance. Every sentence earns its place and is front-loaded with the most important information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only fetch tool with well-documented parameters, the description covers what it returns, when to use it, and how it differs from the sibling. It lacks potential caveats like error handling or rate limits, but the essential selection and invocation context is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with clear descriptions for both 'pmids' (comma-separated) and 'format' (enum with default). The description does not add parameter-specific details beyond what the schema already provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Get full article abstracts as plain text or XML for one or more PMIDs.' It clearly distinguishes from sibling pubmed_summary by emphasizing 'full' abstracts and mentioning the alternative tool directly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use this tool: 'Use for reading full abstracts when pubmed_summary metadata is not enough.' This provides a clear comparison to the sibling tool and signals when this is the appropriate choice versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_gis_boundariesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint annotation already covering safety, the description adds meaningful behavioral context: layer IDs are state-dependent, output may include multiple boundary types, and the tool queries ArcGIS. This goes beyond a bare read-only declaration and helps set expectations for data variability.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core purpose, and no filler. The state-specific caveat and pointer to sibling are packed into the second sentence, keeping the description efficient and structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity and lack of output schema, the description covers the essentials: what it queries, possible data types, and state-dependent layer IDs. It doesn't describe response format or error behavior, but those could be inferred from the query nature and the pointer to state_gis_services.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 valuable semantics beyond the schema by explaining that layer_id varies by state and the appropriate way to discover it (use state_gis_services). This gives the agent essential context for correctly parameterizing the call.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Query political boundaries for a US state via ArcGIS.' This clearly distinguishes the tool from siblings like state_gis_parcels (parcels) and state_gis_services (service discovery). Adding the likely content types (counties, municipalities, districts) further clarifies scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context for use (querying political boundaries) and gives actionable guidance: 'Layer IDs vary by state — use state_gis_services to check available layers.' This points to a specific sibling for a prerequisite step. It doesn't explicitly state when not to use it, but the purpose is specific enough to infer.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• state_gis_queryA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the description doesn't need to restate safety. It adds valuable context by disclosing support for attribute and spatial queries with SQL-like where clauses, and by flagging that not all states have GIS services. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four sentences, each earning its place: first states core function, second elaborates query capabilities, third points to discovery, fourth warns about state coverage. No redundant wording or padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 7 parameters and no output schema, the description covers the main workflow (discover, check state, query) but omits details about return format, pagination via limit, or handling of the geometry parameter. The reference to sibling tools partially compensates for this gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 enriches parameter understanding by linking 'where' to SQL-like clauses and explaining that service and layer_id can be discovered via state_gis_services. This goes beyond the schema's field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Query any ArcGIS REST service layer for a US state', which clearly states the verb (query), resource (ArcGIS REST service layer), and scope (US state). It also distinguishes from siblings by referencing state_gis_services for discovery, making the tool's specific role obvious.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides actionable guidance: use state_gis_services to discover services and layer IDs, and use state_list to check whether a state has GIS services. This covers prerequisites but stops short of explicitly contrasting with other query tools like state_gis_parcels or stating when NOT to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swpc_forecastA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates a safe read operation. The description adds value by specifying the output is 'forecast text' and enumerating the covered domains (solar activity, geomagnetic, radiation), giving the agent a clear expectation of the result content without contradicting the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the verb 'Get,' and every word contributes meaning. There is no redundancy or filler, making it an model of conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only tool, the description is adequately complete: it names the source (NOAA SWPC), the time horizon (3-day), the format (text), and content areas. It does not detail the exact text format, but given the tool's simplicity, this is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the schema provides no parameter detail. The baseline is 4, and the description enriches the tool's semantics by explaining what the returned forecast includes, which helps the agent understand the output despite having no inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get 3-day space weather forecast text from NOAA SWPC.' It specifies the resource (NOAA SWPC) and the output (3-day forecast text), and lists the content areas (solar activity, geomagnetic, and radiation environment forecasts), which distinguishes it from siblings like swpc_alerts or swpc_kp_index.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when you need a 3-day space weather forecast in text form. It does not explicitly mention alternatives or exclusions, but the clarity of '3-day forecast text' provides enough context to differentiate it from other SWPC tools like alerts or indices.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• transit_statusA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as read-only, and the description adds meaningful context about the fallback behavior for unsupported systems. This goes beyond what annotations provide, though it doesn't detail response formats or other edge cases.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the operation and followed by supported systems and fallback behavior. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 adequately covers the main purpose, supported systems, and fallback behavior. With no output schema, a bit more detail on return format could be added, but it is sufficient for selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds semantic value by clarifying which system IDs yield alerts versus arrivals data. This explains behavior based on the parameter value beyond the schema's simple ID list.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool gets service alerts and incidents for a transit system, using a specific verb and resource. It distinguishes itself from sibling tools by listing supported systems and noting the fallback behavior for unsupported ones.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by listing supported systems (bart, mbta, septa, wmata) and indicating that others return arrivals data instead. While it implies when this tool is appropriate, it doesn't explicitly mention alternative tools or exclusions for per-system alert tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• transit_systemsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description's 'List' aligns with this. The description adds the specific count (12) and the included fields (regions, capabilities), providing useful context beyond the annotation. No safety concerns or side effects need disclosure for a simple list operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that immediately conveys the tool's purpose and output. Every word earns its place, with no redundancy or extraneous detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, parameterless list tool with readOnlyHint annotation, the description is complete. It specifies the exact set of systems, the included attributes, and implicitly signals that no other inputs are needed. There is no output schema to document, and the description covers the return value sufficiently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the description compensates by clearly explaining what the response contains (all 12 transit systems with regions and capabilities). Since there is no schema to document parameters, the description fully carries the semantic burden and does so effectively.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 'all 12 available US transit systems', specifying the output includes regions and capabilities. This distinguishes it from sibling tools like bart_stations or septa_train_view, which operate on specific systems, making it a unique catalog tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is used to discover available transit systems, but it does not explicitly compare it to alternatives or state when not to use it. Given many transit siblings exist, more explicit guidance would be helpful, but the context of listing systems is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• uscis_case_statusA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates a safe read-only operation. The description adds meaningful behavioral context by naming the output fields (status, form type, latest action) and the input format. It does not disclose potential errors or rate limits, but for a simple status lookup with a read-only hint, this is adequate and goes beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each earning its place: the first states the core purpose, the second lists the return values, and the third explains the input format. It is front-loaded and contains no filler or repetition, achieving maximum efficiency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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) and the read-only annotation, the description is largely sufficient. It explains the input and expected output, providing enough context for an agent to use the tool correctly. Minor gap: it does not mention error behavior for invalid receipt numbers, but that is not critical for a basic status lookup.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides a description for the only parameter, achieving 100% coverage, so the baseline is 3. The description enriches the parameter semantics by explaining the exact format ('13 characters: 3-letter center code + 10 digits') and giving a concrete example, which helps the agent construct a valid receipt_number value more accurately than the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Check the status'), the specific resource ('USCIS immigration case'), and the required input ('by receipt number'). It also details what is returned (status, form type, latest action), making it unmistakable what the tool does. Since no sibling tool covers USCIS case status, it is inherently distinguished.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context by specifying the exact receipt number format and an example, indicating when to use this tool (when you have a valid receipt number). It does not explicitly exclude alternatives or say 'use this instead of X,' but the absence of sibling tools for USCIS status makes such exclusion unnecessary. The usage context is sufficiently clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usda_ag_queryA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers safety, and the description adds valuable behavioral context: the hard 50,000-record maximum and a recommendation to pre-count for large queries. No contradictions with annotations. Slightly more detail (e.g., pagination or error behavior) would be useful, but the limit is a key constraint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences with no filler. The core purpose, a critical limit, and usage guidance are all front-loaded, making it easy for an agent to parse quickly. Every clause contributes.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the schema fully documents parameters and readOnlyHint is set, the description covers the essential purpose, a key limit, and a pre-query strategy. It doesn't describe the return format or fields, but for a query tool this is acceptable since the schema and annotations carry most context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% since all 8 parameters have descriptions, so the baseline is 3. The description adds value by clarifying that parameters are combinable as filters ('any combination of filters'), which is not stated in the schema. This helps the agent understand parameter interactions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states it performs a 'Custom query to USDA NASS QuickStats' with 'any combination of filters.' This is a specific verb (query), resource (USDA NASS QuickStats), and scope (arbitrary filters), which clearly distinguishes it from specialized USDA siblings like usda_prices, usda_crop_data, and usda_livestock.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: 'Use usda_ag_count first for large queries' and discloses the 50,000-record limit. This tells the agent when to use a preliminary count tool, but it doesn't contrast with other USDA query tools that might be more appropriate for specific data types.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• usgs_significantA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, and the description adds useful context beyond that: the 30-day fixed window, the 'typically M4.5+ or felt/damaging' selection criteria, and worldwide scope. It does not mention return format or pagination, but for a simple read-only list tool this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary purpose and followed by a concise qualifier about magnitude. No filler words; every phrase earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only tool with no output schema, the description covers the key context: time window, magnitude threshold, and scope. It could go further by specifying the return format (e.g., list of earthquakes with location/magnitude), but the essential decision-making information is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so schema description coverage is 100% by default. Per the rubric, a baseline of 4 applies. The description adds no parameter-specific details because none exist; it correctly describes a fixed behavior rather than parameterizable options.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 ('significant earthquakes'), and the time window ('past 30 days'), with a specific magnitude threshold ('typically M4.5+ or felt/damaging events'). It distinguishes this from sibling tools like usgs_earthquakes by emphasizing 'significant' and 'notable' events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool ('Quick way to see the latest notable seismic activity') and sets expectations with the magnitude threshold. However, it does not explicitly name alternatives or state when NOT to use it, leaving some ambiguity versus sibling tools like usgs_earthquakes.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bart_departuresA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds value by disclosing the exact return fields (departure times, platform, direction, train length, color) and the special 'ALL' station option, going beyond what the annotation provides. No contradictions exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary action and resource, and every clause adds useful information. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only tool with a 100%-covered schema, the description covers the return fields (since there is no output schema), the input format, and the special 'ALL' behavior. It is fully self-sufficient for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes the 'station' parameter with examples at 100% coverage, so the baseline is 3. The description adds the general rule that abbreviations are 4 letters and explains the 'ALL' special value, enriching the schema's example-based documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get real-time departure estimates for a BART station,' which is a specific verb+resource with clear scope. It also confirms the return payload (departure times, platform, direction, train length, color), which distinguishes it from sibling tools like bart_advisories and other transit arrival tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states what data this tool provides (real-time departures for a BART station) and gives station abbreviation conventions. It does not explicitly say when not to use it or name alternatives, but the context makes its purpose unambiguous among the many transit sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_fixed_assetsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds useful behavioral context by disclosing update frequency and the annual nature of the data, which helps set expectations. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured. It leads with the primary purpose, then provides scope details and common table names in three short paragraphs. Every sentence is informative, with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter data retrieval tool with no output schema and no nested objects, the description covers all relevant aspects: what data is included, update schedule, example tables, and how to discover more. It is sufficient for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 beyond the schema by naming common table examples (FAAt101, FAAt201, FAAt401, FAAt801) and indicating that table_name defaults to FAAt101, giving users concrete starting points.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the tool's function: 'Get Fixed Assets data — net stock, depreciation, and investment tables.' It names specific categories (private/government fixed assets, equipment, structures, IP products) and distinguishes it from sibling BEA tools by focusing on the FixedAssets dataset, listing common table names.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: 'Annual data only, updated once per year (late August – early October)' and directs users to 'Use bea_dataset_info to discover all table names.' It doesn't explicitly state when not to use this tool relative to other BEA datasets, but the scope is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clinical_trials_resultsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Read-only behavior is already indicated by readOnlyHint=true. The description adds the hasResults=true constraint and enumerates the response content categories, which are not visible in the annotations. This provides useful behavioral context beyond the structured metadata.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences: the first states purpose, the second lists return contents, and the third gives the precondition and alternative search tool. Every sentence earns its place with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only lookup with full schema documentation, the description is complete. It covers what the tool does, what it returns, the precondition, and how to find eligible trials. The listed result sections provide sufficient expectation despite 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole parameter nct_id is fully documented in the schema with an example ('NCT00841061'), so schema coverage is 100%. The description only restates 'by NCT ID', adding little beyond what the schema already provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' plus the resource 'posted results for a completed clinical trial by NCT ID', clearly stating what the tool does. It also lists the returned data sections (outcome measures, adverse events, participant flow, baseline characteristics), which distinguishes it from search and detail siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states the precondition 'Only works for trials where hasResults=true' and directs users to 'clinical_trials_search with agg_filters='results:with' to find them', providing an alternative tool. This gives clear when-to-use guidance and a concrete search strategy.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clinical_trials_searchA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true. The description adds value by stating the return fields (trial ID, title, status, phase, sponsor, conditions, enrollment, hasResults flag) and giving examples of specialized query syntaxes (Essie expressions and aggregation shorthands). It does not cover pagination or rate limits, but the schema already documents page_size and page_token.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is five sentences, front-loaded with purpose, followed by return fields and targeted usage examples. Every sentence contributes meaningful information without redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (17 optional parameters, no output schema), the description provides a solid overview of search capabilities, return fields, and advanced usage examples. It complements the rich schema descriptions and gives an agent enough context to select and invoke the tool correctly for common use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description goes beyond by providing concrete examples for sponsor ('Pfizer', 'Moderna', 'NIH'), filter_advanced ('AREA[StartDate]RANGE[2024-01-01,MAX]'), and agg_filters ('results:with,sex:f,healthy:y'), which enhance practical understanding of how to use these parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description begins with 'Search ClinicalTrials.gov for clinical trials' and lists specific search facets (condition, drug/intervention, sponsor, status, phase, study type, location, title, or free text). This clearly distinguishes it from sibling tools like clinical_trials_detail and clinical_trials_stats, which have different primary functions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context for use, including a concrete use case ('Use sponsor filter to track pharma company research') and guidance for advanced parameters (filter_advanced, agg_filters). However, it does not explicitly mention when to use alternative sibling tools (e.g., clinical_trials_detail for full trial details), so it lacks an explicit when-not-to-use statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clinical_trials_size_statsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description complements this by outlining the specific read-only outputs. It adds value by listing what statistics are returned, though it does not mention whether there is any size limit on results or if the 'largest studies' list has a cap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences that front-load the main purpose and then add a clarifying note about 'quick overview'. Every phrase earns its place and there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description enumerates exactly what kinds of statistics will be returned, covering scope (total count), volume (average size, size distribution), and outliers (largest studies). For a zero-parameter, read-only stats endpoint, this is sufficient context for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema reflects that with no properties. Description compensation is unnecessary, so the baseline of 4 applies. The description explains what the tool computes without any parameter details, which is appropriate for a no-input tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning database statistics with specific output types (total study count, average JSON size, size distribution, largest studies). This distinguishes it from sibling tools like clinical_trials_search or clinical_trials_detail, and even from clinical_trials_stats by focusing on size-related metrics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context for use: 'Quick overview of the ClinicalTrials.gov database scope and data volume' tells the agent this is for high-level summaries rather than detailed record lookup. However, it does not explicitly name alternative tools for when the user needs individual trial data, so it stops short of providing exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_bill_textA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already communicates that this is a safe read operation. The description adds that the tool returns version types and format URLs, and implies (via the govinfo_bill_text reference) that it does not return full text content. However, it does not disclose potential pagination, rate limits, or error behavior, so it falls short of a 5.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loaded with the tool's purpose, includes concrete examples of version types, and provides a cross-reference to an alternative tool. Every word contributes value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with three required parameters and a readOnly annotation, the description fully covers the tool's purpose, output (version types and format URLs), and provides an alternative for full text. No output schema exists, but the description adequately states what is returned, making it complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all three required parameters (congress, bill_type, bill_number), achieving 100% coverage. The description adds no additional parameter-level 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: retrieving available text versions for a bill (e.g., introduced, reported, engrossed, enrolled) and returning version types and format URLs. It explicitly distinguishes itself from govinfo_bill_text, which provides full bill text content.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly directs users to govinfo_bill_text when they need full bill text content, providing a clear alternative and establishing appropriate usage context. This guidance is specific and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_committee_details_by_congressA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, so the safety profile is covered. The description adds behavioral context about what kind of data is returned (membership for that specific congress vs. all-time), which is useful beyond the annotation. It could mention additional response characteristics, but for a read-only lookup tool with this contrast, the added context is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with 'Get detailed information', and every sentence earns its place. The first sentence states the core action, the second adds the distinction from an alternative, with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (3 required params, no output schema, read-only annotation), the description fully covers what the tool does, when to use it, and how it differs from the sibling. It provides enough context for an agent to select and invoke it correctly without further elaboration.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter having a description. The tool description explains the role of the congress parameter as the filtering dimension, but doesn't add semantic details beyond the schema. Per the rubric, baseline 3 applies when schema already covers parameters; the description doesn't elevate it further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses clear verb 'Get detailed information' with a specific resource 'committee' and a specific filter 'by a specific congress number'. It also explicitly differentiates from sibling tool congress_committee_details by contrasting 'for that specific congress vs. all-time details', making it distinct from similar tools in the family.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states exactly when to use this tool: when you need committee details for a specific congress. It also provides an explicit alternative (congress_committee_details) for all-time details, giving clear when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• congress_member_full_profileA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, so the safety profile is known. The description adds valuable behavioral context by revealing the composite nature (3 endpoints in parallel), listing specific data categories returned (party history, terms, committees, photo, website, legislative activity). While it doesn't discuss rate limits or response structure, it goes well beyond the annotation baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded. The first sentence states the core value, the second paragraph gives explicit usage guidance, and the third gives contextual use cases. Every line earns its place without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a composite tool with no output schema, this description is remarkably complete: it explains the composite nature, enumerates return contents, provides usage alternatives, and connects to adjacent tools for accountability research. All key aspects (purpose, alternatives, data categories) are addressed for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents both parameters. The description does not add deeper parameter meaning beyond what the schema already includes, such as format or examples for bioguide_id and default behavior for bill_limit. It meets the baseline but doesn't exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets a complete member of Congress profile in one call, explicitly listing combined components (bio/details, sponsored and cosponsored legislation) and contrasting with individual sibling tools. This strongly distinguishes it from congress_member_details, congress_member_bills, and similar tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: 'Use this instead of calling congress_member_details + congress_member_bills (sponsored) + congress_member_bills (cosponsored) individually.' It also describes ideal use cases for accountability research and references related tools for cross-referencing, making both when-to-use and alternatives clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cpsc_recall_detailA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and description aligns by saying 'Get'. Description adds valuable context about the scope of returned data (products, remedies, images, contact info), going beyond the raw annotation. No contradictions, but doesn't discuss potential pagination/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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core purpose, then a concise list of returned content. Every word earns its place with no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 1-param lookup with readOnly annotation and no output schema, the description fully covers prerequisite workflow, return contents, and purpose. Nothing meaningful is missing for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema fully documents recall_id as 'Recall ID from search results' with 100% coverage. Description repeats this implicitly via 'Use cpsc_recall_search first to find RecallIDs', adding no new syntactic detail beyond what schema already provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Get' and resource 'CPSC recall details by RecallID', clearly distinguishing from search sibling. It enumerates the rich content returned, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states 'Use cpsc_recall_search first to find RecallIDs', providing clear when-to-use guidance and pointing to the correct alternative for discovery. This perfectly situates the tool in the workflow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_approved_drugsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint: true, and the description adds valuable behavioral context by stating it 'shows approval history, active ingredients, and marketing status' and including example query syntax. This goes beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, front-loaded with the core purpose, and uses three example queries to illustrate usage without unnecessary verbosity. Every sentence serves a clear purpose — stating what it does, what it shows, and how to use it.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with only two parameters and no output schema, the description is complete: it names the database, the searchable entities, the result fields (approval history, active ingredients, marketing status), and provides concrete query examples. It fully equips an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both limit and search. The tool description adds domain-specific examples (e.g., 'openfda.brand_name:"Ozempic"') that illustrate how to use the search parameter, which is more meaningful than the generic schema examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches FDA-approved drugs using the Drugs@FDA database, and specifies it finds drugs by brand name, sponsor, or application number. This distinguishes it from sibling tools like fda_drug_labels or fda_drug_recalls by focusing on approved drugs and their approval details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on what can be searched (brand name, sponsor, application number) with concrete example queries. However, it does not explicitly exclude alternative tools like fda_drug_labels for label information, so it lacks explicit when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_drug_eventsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, and the description does not contradict this. It adds valuable behavioral context about the dataset size and shows realistic query syntax, helping the agent understand what kind of searches are supported.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with a clear purpose statement, followed by a focused list of example searches. Every sentence and example earns its place, providing high value without unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description partially compensates by explaining what kind of data is available (side effects, hospitalizations, deaths) and how to query it. It does not describe the response structure, but the examples and tool name make the expected content reasonably clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers both parameters with descriptions (100% coverage). The description goes further by providing domain-specific example queries with actual FAERS field paths (e.g., patient.drug.openfda.brand_name), making the search parameter much more actionable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it searches FDA adverse drug event reports (FAERS) and lists relevant content areas (side effects, hospitalizations, deaths). This specific verb+resource combination distinguishes it from sibling tools like fda_drug_labels or fda_animal_events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool (searching adverse event reports) and even gives example search patterns. It does not explicitly name alternatives or state when not to use it, but the scope is well-defined enough for an agent to select appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_historical_docsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds useful behavioral context beyond the readOnlyHint annotation: it notes the date range, that the text is OCR-derived (which signals possible OCR errors), and demonstrates query syntax. It does not disclose response format or pagination, but the annotation already covers read-safety.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the core purpose, followed by three well-chosen examples that each illustrate a different query pattern. Every sentence adds value without redundant fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is fairly complete for a search tool: it covers the resource, time scope, existing parameter semantics, and provides practical examples. The main gap is the lack of any mention of the response format or expected fields, which would matter more due to 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.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema descriptions alone cover the basic parameter formats, but the tool description goes further by providing concrete example queries using fields like doc_type, text, and year. These examples give real semantic meaning to the 'search' parameter and are especially valuable for understanding how to combine terms.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Search') and resource ('historical FDA documents — press releases from 1913 to 2014'), making the tool's purpose unambiguous. It also implicitly differentiates from sibling FDA tools by highlighting the historical press-release scope and OCR 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly conveys when to use the tool: for searching historical FDA press releases from 1913 to 2014. However, it does not explicitly name alternatives or exclusions for more current FDA data, so it lacks formal 'when-not' guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fr_agenciesA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, so the safety profile is known. The description adds value by specifying the return fields and noting the database size ('470+ agencies'), which sets expectations. It does not mention pagination or rate limits, but for a simple list endpoint this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, tightly written, and front-loaded with the main action. Every sentence earns its place: purpose, return fields, and scale. No redundant or vague wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, list-style tool with no output schema, the description is complete: it states what the tool returns and the intended use of slugs for filtering. This is sufficient for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, and the schema coverage is effectively 100% (no properties). The description adds no parameter information, but with no parameters this is a baseline 4; there is nothing more to explain.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it lists federal agencies that publish in the Federal Register, with a specific verb ('List') and resource ('federal agencies'). It also identifies the return fields (names, short names, slugs, URLs) and scale (470+ agencies), distinguishing it from other FR tools that search rules or documents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through 'slugs (for filtering)', suggesting this tool is used to obtain slugs for filtering other Federal Register endpoints. However, it lacks explicit when-to-use versus alternatives or exclusions, but the context is clear enough for a no-parameter list tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_datasetsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds context beyond that by specifying the exact return fields (dataset name, data table name, API endpoint path, description) and the exact counts. This helps set expectations without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the key action and resource, then detailing the return fields. Every word adds value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 explains what the tool returns. The simple, no-parameter design means the description is sufficient for an agent to understand the tool's scope and output. No critical information is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has 0 parameters, so the baseline is 4. The description doesn't need to explain parameter semantics and doesn't attempt to invent any. Schema coverage is effectively 100% since there are no properties.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') with a clear resource ('U.S. Treasury Fiscal Data API datasets') and includes concrete details (53 datasets, 181 endpoints). It also lists the return fields, distinguishing it from sibling tools like query_fiscal_data or get_endpoint_fields.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you need a catalog of all Treasury datasets and their endpoints. It doesn't explicitly mention alternatives or exclusions, but the zero-parameter design and 'all' keyword make the intended usage evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• path_arrivalsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the safe-read nature is covered. The description adds useful behavioral context: it is 'real-time', returns specific data (station names, line info, projected arrival times, train status), and requires no API key. This goes beyond the annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each earning its place: the first states the core action, the second lists return contents, and the third provides geographic scope and access requirements. It is front-loaded, concise, and free of filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only tool with no output schema, this description is complete: it covers what is returned, the geographic scope, real-time nature, and authentication requirements. An agent has all necessary information to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, and the description appropriately states 'for all stations', clarifying that there is no filtering or input customization. With no parameters to document, the baseline is 4, and the description effectively communicates the no-input nature.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('real-time PATH train arrival times'), clearly distinguishing this from other transit tools by naming PATH and its service area (NY/NJ metro, Manhattan to Jersey City, Hoboken, Harrison, Newark). It also states what is returned, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: it is for PATH trains, covers all stations, and requires no API key. While it does not explicitly mention alternatives or exclusions, the tool's scope is obvious given its name and content, so an agent can correctly decide when to use it over other transit tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pubmed_infoA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  ReadOnlyHint=true already signals the tool is a safe read operation. The description adds behavioral context beyond annotations by specifying the exact categories of statistics returned (record count, last update, searchable fields, link types). It does not contradict annotations and offers sufficient transparency for a parameter-less info tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, both informative and free of fluff. The first delivers the core purpose and output content; the second immediately conveys practical utility. No unnecessary words or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, no-parameter informational tool, the description fully covers what the tool returns and why an agent would use it. No output schema exists, but the description enumerates the return categories sufficiently. The presence of sibling search tools makes the boundary clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema provides complete coverage. Per the rubric, a zero-parameter tool gets a baseline of 4. The description appropriately focuses on return content rather than parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('PubMed database statistics'), then enumerates exactly what is included: total record count, last update, searchable fields, and link types. This clearly distinguishes it from sibling tools like pubmed_search or pubmed_fetch, which perform article retrieval rather than database-level info.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear use case: 'Useful for discovering which fields are available for targeted searches (e.g. [MeSH Terms], [Author], [Journal]).' While it does not explicitly name alternatives or state when not to use it, the context is obvious given its meta/info nature and sibling tool names.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pubmed_summaryA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide readOnlyHint; the description adds meaningful behavior: it returns summaries for multiple PMIDs, lists the included fields, and caps the batch at 200. It does not contradict the read-only annotation. Lacking rate-limit or error-behavior details, but sufficient for a lightweight 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short, purposeful sentences: first states the operation and output, second gives workflow context, third states the batch limit. No repetition or filler; every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter, read-only endpoint with no output schema, the description is complete: it tells what comes back, how many PMIDs are accepted, and how it fits into the PubMed search workflow. No additional return-format details are necessary.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes the single pmids parameter thoroughly, so the baseline is 3. The description adds 'up to 200 PMIDs at once' and 'one or more', which are not in the schema and help clarify usage. This extra constraint justifies a score above baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Get article summaries' for PMIDs, and lists the exact fields returned (title, authors, journal, date, DOI). It clearly distinguishes from sibling pubmed_search by framing itself as the follow-up metadata step, and from other PubMed tools via the summary scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states a usage workflow: 'Use after pubmed_search to get full metadata for returned PMIDs.' This is strong practical guidance. It does not explicitly mention when to avoid using this tool or compare it with alternatives like pubmed_fetch, so it falls shy of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wsdot_ferry_vesselsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds meaningful detail about the returned data (vessel names, GPS coordinates, speed, heading, dock status, departure/arrival terminals), going beyond what the annotation provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two tight sentences: the first states the primary function, the second lists the key returned fields. No wasted words or redundant restatements.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description carries the full burden of explaining the return value, and it does so by explicitly listing the fields returned. For a zero-parameter real-time data tool, this is highly complete and leaves little ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters in the input schema, so the baseline of 4 applies. The description adds no parameter-specific semantics, but none are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Get') and resource ('real-time positions of all Washington State Ferry vessels'), and lists the returned fields. It effectively distinguishes from sibling tools like wsdot_ferry_schedule and wsdot_ferry_terminals by focusing specifically on vessel positions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the intended use case obvious: retrieve live WSDOT ferry vessel positions. It does not explicitly mention alternatives or exclusions, but for a zero-parameter data-fetch tool the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bea_nipa_underlying_detailA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already signals a safe read operation, and the description adds a valuable caution that the detailed estimates are lower quality than published aggregates. This is behavioral context beyond what annotations provide, though it doesn't discuss other behaviors like response size 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose, followed by a key caveat and practical examples. Every sentence contributes useful information (purpose, quality warning, common tables, discovery hint) with no filler or repetition of schema content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no output schema and only 3 optional parameters, the description covers the essential context: what the tool returns, quality caveats, how to choose a table, and where to find more tables. It doesn't detail the exact return structure, but the examples and caution make it sufficiently complete for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameter descriptions, so the baseline is 3. The description adds semantic value by mapping common table IDs to their economic concepts (e.g., U20305 → PCE current $), which helps the agent understand the table_name parameter. It does not add detail for year or frequency, but the schema already covers those adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('NIPA underlying detail data') and clarifies it provides 'more granular national account breakdowns.' This distinguishes it from aggregate-level BEA tools and gives concrete examples of common tables, removing ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly contrasts this tool with 'published aggregates' (implying use the other BEA tools for those) and directs users to bea_dataset_info for table discovery. It also provides a list of common tables with what they represent, giving clear guidance on when to use this tool and how to select parameters.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• md_transit_trip_updatesA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds useful behavioral context: the API key requirement and the meaning of each agency enum value. It does not detail response format or rate limits, but for a read-only data-fetch tool with a single parameter, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences. The first sentence states the purpose; the second delivers the API key requirement and the full agency mapping. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one parameter and no output schema, the description covers the essential aspects: what it does (real-time delays/cancellations), the required credential, and the valid agency identifiers. It is self-contained enough for an agent to invoke correctly without additional context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only says the agency is a 'Swiftly agency key'. The description enriches this by mapping each enum value to a human-readable service (e.g., 'mta-maryland' = Local Bus). This greatly improves the agent's ability to pick the correct parameter value beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 'real-time trip updates (delays, cancellations) for Maryland MTA transit', which is specific and distinguishes this tool from transit tools for other agencies or different data types like vehicles or alerts. It also enumerates the exact agency keys with friendly names.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use for delays and cancellations on Maryland MTA services. It also mentions a prerequisite (SWIFTLY_API_KEY) and lists the four agency options. However, it does not explicitly name alternative tools or when not to use this tool, but the context is strong enough for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• epa_facility_detailA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description reinforces this with 'Get' and 'Returns'. It adds useful context about the returned content categories, though it doesn't mention rate limits or other constraints. Credit for describing return value in absence of 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with the verb 'Get', and every sentence provides value: what it does, what it returns, how to use it. No redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter detail tool with no output schema, the description adequately covers the response content and usage sequence. It lists specific sections of the report and the prerequisite step, making the tool self-contained for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has only one parameter with a detailed description and example, so coverage is 100%. The tool description adds the workflow context that this ID comes from epa_facilities results, reinforcing the parameter's origin and use.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets a detailed facility report from ECHO by registry ID, listing specific data categories (permits, enforcement actions, compliance summaries, NAICS/SIC codes, inspection history). This distinguishes it from siblings like epa_facilities which is the search/list counterpart.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states to use epa_facilities first to find a RegistryID, then pass it here for the full report. This provides a clear workflow and context for when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fda_countA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so no need to restate safety. The description adds valuable behavioral context: it returns 'top terms with counts' and explains the critical '.exact' suffix behavior (word splitting vs full phrase counts), which is essential for correct use. It also lists all supported endpoints, giving a full picture of the tool's coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with a brief summary, an IMPORTANT note, an endpoints list, and per-endpoint examples. Although longer than typical, every section is purposeful and improves usability without unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description fully covers the tool's scope (all endpoints), return shape (top terms with counts), and critical usage nuances ('.exact'). The input schema covers parameter details, so the description completes the mental model without needing to repeat schema fields. No output schema exists, but the return description is adequate for this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (each parameter has a description), so baseline is 3. The description adds extra value by providing concrete count_field examples per endpoint (e.g., 'pharm_class.exact' for drug/ndc) and explaining the '.exact' convention in more detail than the schema's one-line hint.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Count/aggregate') and identifies the exact resource ('any OpenFDA endpoint by a specific field'), which clearly distinguishes it from the many endpoint-specific sibling tools. The statement 'Works on ALL FDA endpoints' further sharpens the scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains when to use this tool (for counting/aggregating across any FDA endpoint) and provides critical usage details like the '.exact' suffix requirement and per-endpoint count_field examples. It doesn't explicitly mention alternatives or exclusions, but the 'Works on ALL FDA endpoints' phrasing and the comprehensive examples make the intended usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fec_committee_disbursementsA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description does not contradict this. The description adds context about the data scope (itemized disbursements) and hints at filtering, but does not disclose pagination behavior or rate limits. With annotations covering the safety profile, the added context is sufficient for a 4.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded. It combines the main purpose, a workflow section, an example, and common PAC IDs in a compact, high-value format. Every sentence earns its place with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description carries the burden of explaining results. It does so explicitly ('shows exactly which candidates and committees received money, how much, and when') and enriches context with workflow, example, and common IDs, making it complete for practical investigative use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 meaningful value by explaining the workflow around committee_id and recipient_name, providing example values (e.g., committee_id='C00004275', recipient_name='Crapo'), and suggesting cycle variations ('election year ± 1 cycle').

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Get itemized disbursements from a PAC or committee' – a clear verb+resource+scope. It explicitly states what data is returned (recipients, amounts, dates) and distinguishes itself as the 'KEY tool for conflict-of-interest investigations.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete WORKFLOW referencing fec_search_committees as a prerequisite step, instructs to 'Try multiple cycles', and includes an example call. This explicitly guides when and how to use this tool versus searching for committees first.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• govinfo_bill_textA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds substantial behavioral context: bill size ranges (5k to 500k+ chars), default max_length of 100k, preview_only behavior (returns metadata only), and version suffix meanings. This goes beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Well-structured with a clear lead sentence, an IMPORTANT usage note, and a concise bullet-like list of version suffixes. Every sentence adds useful information; no filler or repetition. The length is justified by the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, but the description covers what is returned (full text or metadata with preview_only), character limits, version options, and the relationship to sibling tools. The tool has 6 parameters and the description addresses them all through a combination of text and schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are already documented. The description adds value by explaining version suffix semantics in text (e.g., 'enr' = enrolled/signed), and elaborating max_length usage ('Most bills fit within 100k... Set higher for omnibus bills'). This enriches the bare schema definitions without redundancy.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool retrieves the full legislative text of a bill from GovInfo, specifying the content type ('actual law language with section numbers, dollar amounts, legal citations, and provisions'). This is a specific verb+resource and clearly distinguishes it from congress_bill_summaries, which the description explicitly contrasts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: try congress_bill_summaries first for quick CRS summaries, and use this tool only when exact language, provisions, or dollar amounts are needed. Additionally recommends preview_only=true first to check bill size. This is clear when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sec_company_searchA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context: it returns specific company details and a recent filings list, and it emphasizes that the lookup is by CIK number only. It does not mention edge cases like unknown CIKs or response format limitations, but for a read-only lookup tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a clear one-sentence purpose, followed by a bulleted list of useful examples, and a closing pointer to the sibling tool. Every element serves a purpose, and there is no redundant or fluff content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a single parameter and read-only annotation, the description is thoroughly complete. It states the input, the output fields, provides common examples, and explains how to find the CIK if needed. Given the simple complexity and that no output schema exists, this description fully equips an agent to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% because the cik parameter has a detailed description including format and examples. The tool description adds value beyond the schema by providing a curated list of common CIK numbers (Apple, Microsoft, etc.) and reiterating that leading zeros are optional, which helps the agent quickly recognize valid inputs without needing to consult external knowledge.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Look up a company on SEC EDGAR by CIK number.' It specifies the verb, resource, and lookup method, and lists the returned fields (company name, tickers, SIC code, state, recent filings). It also distinguishes itself from the sibling tool sec_filing_search by directing users to that tool for name-based searches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells users when to use this tool (when you have a CIK) and when to use an alternative: 'To find CIK: search by company name using sec_filing_search.' This provides clear guidance and prevents misuse.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• smithsonian_detailA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotation, the description adds useful behavioral context by enumerating the types of data returned (images, provenance, dimensions, extended metadata). It does not disclose rate limits or error behavior, but for a simple read-only detail endpoint, this is sufficient and exceeds the baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary action and resource, and includes only necessary information. No redundant or vague language.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one required parameter, read-only annotation, no output schema), the description covers the purpose, the required input, the content scope, and the correct workflow. It is complete for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides a 100% description of the single 'id' parameter, and the description reinforces it by explaining the ID comes from search results. This adds contextual meaning beyond the schema (e.g., provenance of the ID) rather than simply restating the field.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get full details') and resource ('Smithsonian collection record by ID'), and it explicitly lists contents (images, provenance, dimensions, extended metadata). It clearly distinguishes itself from sibling tools by positioning as the detail lookup after smithsonian_search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use smithsonian_search first to find record IDs,' naming the sibling search tool and providing clear sequencing. This effectively tells the agent when to use this tool (after a search) and implies it is not for searching.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• code_modeA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotation, the description discloses the WASM sandbox, the script's allowed operations (JSON.parse, loops, Math, console.log), its limitations (no files, network, Node.js APIs, imports), and the fact that only console.log output enters context. This gives a thorough behavioral profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded: after the core purpose sentence, it delivers usage guidance, capabilities/limitations, and a concrete example. Every sentence earns its place, and the length is justified by the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description carries full responsibility for explaining inputs, behavior, and outputs. It covers the entire lifecycle—what it does, when to use it, how to write scripts, sandbox constraints, and the console.log return behavior—with an example that removes ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema describes all 3 parameters, the description adds crucial meaning: DATA is the raw string response, console.log is the only output channel, and the detailed example ties together tool, tool_args, and code, demonstrating the exact usage pattern.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Run a JavaScript processing script against any tool's output in a WASM sandbox.' It then details the two-step flow (call tool, then run script on DATA), making it unmistakably distinct from the many data-retrieval sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states 'USE THIS when you need specific fields, counts, or filters from a large response' and 'DO NOT use this when you need to read and interpret the full data for cross-referencing or analysis,' providing clear when-to-use and when-not-to-use guidance with implied alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.