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

No annotations provided, so description carries full burden. Explains parameter dependencies (e.g., aggregate only for counts). Could mention data freshness or read-only nature, but overall transparent about tool behavior.

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

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

Well-structured with clear 'Args' section. Each sentence adds value without redundancy. Efficiently conveys necessary information.

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

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

Covers all parameters with dependencies explained. Includes cross-reference for offense codes. Output schema exists so return values need not be described. Complete for a 9-parameter tool.

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

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

Schema has no descriptions (0% coverage), but the description provides extensive semantics for all 9 parameters, including examples, defaults, constraints, and cross-references. Adds significant value beyond bare schema.

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

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

The description clearly states 'Get arrest statistics by offense, optionally broken down by demographics.' The verb 'get' and resource 'arrest statistics' are specific. Differentiates from sibling tools like get_crime_trends which focus on broader crime data.

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

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

Provides detailed parameter instructions including examples for offense codes, required parameters for geographic levels, and points to get_reference_data for full offense list. Lacks explicit when-not-to-use or direct comparison to siblings, but sufficient for a complex tool.

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

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

No annotations are provided, so the description takes full burden. It clearly states the tool returns a summary including specific elements, which is appropriate for a read-only operation. No side effects or limitations are disclosed, but the description is transparent about what the tool provides.

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

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

The description is four sentences, each adding value: first states purpose, second lists contents, third explains crime trends detail, fourth provides overall orientation. It is front-loaded and concise with no wasted words.

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

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

Given the tool has no parameters and an output schema exists, the description does not need to detail the output format. It covers the key aspects of what the summary includes, making it complete for a simple tool.

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

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

The tool has no parameters, so the schema coverage is 100%. The description adds no parameter info because none are needed, which is adequate.

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

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

The description clearly states 'Get a summary of the FBI Crime Data Explorer (CDE) homepage' and lists specific contents (mission statement, navigation, data freshness, date ranges, crime trends), which distinguishes it from sibling tools like get_crime_trends or get_summarized_crime_data.

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

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

The description does not explicitly state when to use this tool versus alternatives. While the purpose implies it is for an overview, there is no direct comparison or exclusion criteria.

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

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

No annotations are provided, so the description bears full responsibility for disclosing behavior. It states that the tool returns percent changes across crime types but omits important details such as potential caching, rate limits, error handling for out-of-range years, or whether the data represents year-over-year changes. For a tool with no annotations, this is insufficient 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.

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

The description is concise, consisting of a main sentence and an 'Args' section that lists parameters. It front-loads the key purpose and enumerates the crime types. The addition of the 'Args' section is slightly redundant with the schema but adds clarity. Every sentence is useful, though the structure could be more streamlined.

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

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

The tool has only two optional parameters and an output schema exists, so the description need not explain return values. However, the description omits details on how the percent changes are computed (e.g., over the entire range or year-over-year) and does not address edge cases like missing data for certain years. Given the complexity of crime trend data, the description is minimally adequate but not comprehensive.

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

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

The schema has 0% description coverage, meaning the description must compensate. The description adds meaning by specifying that from_year and to_year are optional, use 'yyyy' format, and represent start and end years. This goes beyond the schema's type and default values, providing clear usage intent for both parameters.

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

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

The description clearly states that the tool retrieves national crime trend data showing percent changes across 10 specific crime types. It uses a specific verb ('Get') and resource ('national crime trend data'), and the list of crime types distinguishes it from sibling tools that focus on specific subsets (e.g., NIBRS data, hate crime data).

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

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

The description provides parameter hints (optional from_year and to_year with format) but no guidance on when to use this tool versus siblings, nor any exclusions or prerequisites. For example, it does not explain that this tool is for national-level trends while other tools like 'get_summarized_crime_data' may provide different aggregations. This lack of context makes it harder for an agent to decide when to invoke this tool.

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

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

No annotations exist, so description carries full behavior burden. It details data types (counts/totals), aggregation (yearly/monthly), date formats, and conditional parameter requirements. It does not explicitly state read-only or safety, but behavior is clear and non-destructive.

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

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

Description is concise: one introductory sentence followed by a structured Args list. Each parameter explanation is brief yet complete. No unnecessary words.

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

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

Given 7 parameters, no annotations, and an output schema (not shown), the description covers all needed context: parameter semantics, conditional requirements, and data scope. No gaps for the agent to use the tool correctly.

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

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

Schema has 0% description coverage, but the description's Args section provides thorough explanations for each of the 7 parameters, including required conditions, defaults, and formats (e.g., 'mm-yyyy' for dates, 'state' requirement). Fully compensates for schema gaps.

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

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

Description clearly states 'Get Supplementary Homicide Report (SHR) data with expanded details on homicides including victim/offender demographics, weapons, and circumstances.' This is a specific verb+resource and differentiates from sibling tools like get_hate_crime_data or get_summarized_crime_data.

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

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

Description explains parameter requirements (e.g., state required for level='state') and data_type options (counts vs totals). However, it does not explicitly state when to use this tool versus siblings, though context implies it for homicide-specific data.

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

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

With no annotations, the description carries full burden. It explains parameter dependencies, defaults, and the condition on aggregate. It does not disclose rate limits, idempotency, or data freshness, but the behavioral details are adequate for a data retrieval tool.

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

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

The description is well-structured with clear headings and bullet points, but it is somewhat lengthy. Every sentence adds value; however, it could be slightly more concise without losing information.

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

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

Given 8 parameters, 5 required, no enums, and presence of output schema, the description covers all necessary details: parameter explanations, dependencies, and return type hints (counts vs totals). It is complete for the tool's functionality.

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

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

Schema coverage is 0%, so the description compensates fully. It provides detailed explanations for all 8 parameters, including format examples (e.g., '01-2020'), allowed values (offense codes), and conditional requirements (state, ori). This adds significant value beyond the schema's type definitions.

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

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

The description clearly states the tool gets expanded property crime data with stolen/recovered property values, using specific verbs and resources. It distinguishes from siblings like get_expanded_homicide_data by focusing on property crime.

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

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

The description explains when parameters are required (e.g., state for level 'state', ori for 'agency') and includes a note about aggregate only applying to data_type 'counts'. It does not explicitly state when to use this tool versus alternatives, but the purpose is clear enough.

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

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

Without annotations, the description carries full burden. It discloses conditional parameter dependencies (e.g., state required when level is 'state') and explains default behaviors (aggregate='yearly', data_type='counts'). However, it does not mention read-only status, rate limits, authentication requirements, or any side effects, which are important for an agent to use safely.

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

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

The description is well-structured as a docstring with a brief overview followed by a clean parameter list. Each sentence serves a purpose, though the parameter list could be slightly streamlined. Overall, it is efficient and front-loaded.

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

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

Given the complexity (8 parameters, 3 required) and the presence of an output schema, the description covers parameter semantics thoroughly. It lacks only a sample usage or mention of error conditions, but remains complete enough 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.

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

Schema description coverage is 0%, so the description must fully compensate. It explains every parameter: format (mm-yyyy for dates), allowed values (e.g., 'national','state','agency' for level), defaults, and conditional requirements. It even references another tool for bias code lookup, adding significant value beyond the schema.

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

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

The description clearly states that the tool retrieves hate crime statistics with optional bias filtering, and lists the types of data returned (incident counts, victim types, etc.). It distinguishes itself from sibling tools by focusing specifically on hate crime data, which is unique among the listed siblings.

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

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

The description provides detailed guidance on parameter usage, such as conditional requirements for state and ori depending on level, and the difference between data_type and aggregate options. However, it does not explicitly compare this tool to alternatives like get_arrest_data or get_nibrs_data, leaving the agent to infer when to use this over others.

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

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

No annotations provided, so description carries full burden. Discloses data content but omits behavioral traits like authentication, rate limits, or side effects. Adequate for a read-only retrieval tool.

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

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

Description is concise with a brief overview and structured parameter list. Front-loaded with key information, no redundant sentences.

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

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

Output schema exists but isn't shown; description mentions data categories but not structure or field names. Complete enough for basic use but could detail return format given 3 parameters and no output schema in description.

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

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

Schema coverage is 0%, so description compensates well. Explains each parameter clearly: report_type values, year, month dependency on report_type. Adds meaning beyond schema.

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

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

The description clearly states the tool retrieves LEOKA data on law enforcement officers killed and assaulted, specifying the resource and verbs. It distinguishes from siblings by focusing on a specific dataset, though it could explicitly differentiate from similar tools.

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

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

No guidance on when to use this tool versus alternatives or prerequisites. The description explains parameters but lacks context on when to choose 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.

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

No annotations are provided, so the description carries full burden. It discloses that invalid chart_type will result in an error, but omits other behavioral traits like data freshness, read-only nature, or response format.

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

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

Two sentences: first clearly states purpose, second covers parameters. No wasted words; front-loaded with key information.

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

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

Description provides basic purpose and parameter meanings, but lacks context about data coverage (e.g., year range, source) and output format. However, an output schema exists, reducing the need to describe return values.

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

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

With 0% schema coverage, description adds value by explaining year as 'Year for the data (e.g., 2022)' and chart_type as 'Chart/breakdown type' with hint to use get_reference_data. It compensates well for the schema gap.

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

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

Description clearly states it retrieves law enforcement suicide data with breakdowns by specific categories (demographics, race, location, duty status). This distinguishes it from siblings like get_leoka_data (assaults/killings) and get_use_of_force_data.

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

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

No explicit guidance on when to use this tool versus alternatives. It does mention using get_reference_data for valid chart_type values, but no when-not or comparative context.

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

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

No annotations are provided, so the description carries full burden. It describes the data retrieval operation but does not explicitly state side effects, permissions, or read-only nature. The description implies a safe read operation but lacks explicit behavioral disclosure beyond data format.

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

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

The description is well-structured with a clear purpose and Args section. While it is somewhat lengthy, every sentence provides value. Minor fluff could be trimmed, but overall it is effective and well-organized.

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

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

Given the presence of an output schema (context signals indicate 'Has output schema: true'), the description focuses on input parameters and usage. It covers all 8 parameters, required vs optional, defaults, and links to reference data, making it complete for the tool's complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It does so thoroughly by explaining each parameter with examples, default values, conditional requirements, and data format constraints. This adds significant meaning beyond the schema structure.

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

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

The description clearly states 'Get NIBRS incident-based crime data for 70+ offense types.' It uses a specific verb and resource, and distinguishes from sibling tools like get_arrest_data and get_hate_crime_data by focusing on NIBRS data.

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

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

The description provides detailed parameter guidance, including examples for offense codes and conditional requirements for level. It also references get_reference_data for a full offense list. However, it does not explicitly compare when to use this tool versus similar siblings like get_crime_trends or get_summarized_crime_data.

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

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

No annotations are provided, so the description carries full burden for behavioral transparency. The description does not disclose whether the operation is read-only, whether it requires special permissions, if there are rate limits, or any side effects. It focuses solely on parameter definitions, missing key behavioral context.

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

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

The description is well-structured with a brief overview followed by an 'Args' section. Each parameter gets a clear, concise explanation. The length is justified by the complexity (8 parameters with conditions). No superfluous sentences, though the external reference to 'get_nibrs_data docs' could be integrated.

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

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

Given the presence of an output schema (context signal: has output schema = true), the description need not cover return values. It thoroughly documents all 8 input parameters with constraints and defaults. The description is complete for the tool's complexity, covering all necessary input guidance.

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

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

The input schema has 0% description coverage, meaning the description must fully explain parameters. It does so exceptionally: provides examples for offense codes, lists exact level options, and clarifies conditional requirements (e.g., state, region, agency_type). This adds substantial value beyond the schema's bare property definitions.

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

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

The description clearly states the tool retrieves NIBRS national crime estimates with breakdowns. It specifies the verb 'Get' and the resource 'NIBRS national crime estimates'. While it doesn't explicitly distinguish from sibling tools like get_nibrs_data, the context of 'estimates derived from incident data' implies an aggregated view, setting it apart from raw data retrieval.

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

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

The description provides detailed parameter conditions (e.g., state required when level='state'), which guides usage. However, it does not explicitly state when to use this tool versus alternatives like get_crime_trends or get_nibrs_data, nor does it mention when not to use it. The guidance is implicit through parameter requirements.

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

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

With no annotations, the description conveys the nature of the data returned (counts by gender, rates) and implies a read-only operation via 'get'. It does not mention permissions or rate limits, but the behavioral scope is well-covered for a 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.

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

The description is concise: a one-sentence summary followed by a clear Args list. No wasted words, and information is front-loaded.

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

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

Given the parameter count (6) and the existence of an output schema, the description fully covers the input parameters' semantics. No additional context is needed for a read tool.

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

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

Schema description coverage is 0%, but the description compensates fully by explaining each parameter's meaning, format (e.g., yyyy), and required context (e.g., state for 'agency' level). This adds significant value beyond the schema.

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

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

The description clearly states the tool retrieves law enforcement employee data, specifying officer/civilian counts by gender and rates per 1,000 population. This verb+resource is distinct from sibling tools (e.g., crime, arrest data).

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

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

The description implies usage for employment data but does not explicitly state when to use this tool versus alternatives or when not to use it. There is no guidance on exclusions or context for selecting this over siblings.

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

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

No annotations provided, so description carries full burden. It implies a read-only retrieval but does not explicitly state side effects, permissions, or response behavior beyond listing what each data_type returns. 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.

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

Front-loaded with purpose, then structured parameter details. Slightly verbose due to formal Args format, but every sentence adds value. No wasted words.

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

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

Covers all data types and parameter conditions. Output schema exists, so return value details are not needed. Could mention that offense_type is ignored for non-offenses, but not essential.

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

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

With 0% schema coverage, the description fully explains both parameters: data_type with four enumerated values and offense_type with conditional requirement. Adds significant meaning beyond the bare schema.

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

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

Clearly states the tool retrieves reference data (state lists, offense/bias code lookups, data properties, refresh dates). The verb 'Get' and specific resource types distinguish it from sibling tools that focus on crime statistics.

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

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

Provides explicit guidance on data_type options and conditionally required offense_type. However, no explicit comparison to siblings or when-not-to-use advice, though context makes it clear this is for reference data.

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

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

Describes the data content and default behavior (aggregate defaults to 'yearly'), but with no annotations, the description carries full burden. It does not disclose potential side effects, authentication needs, rate limits, or whether the operation is read-only, though it is implicitly a 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.

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

The description is moderately long but well-structured with a clear opening line and an Args list. Each sentence is informative and earned. Could be slightly more concise, but overall efficient.

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

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

Given 7 parameters (4 required), no annotations, and an output schema, the description covers all parameter semantics, required conditions, and provides examples. It is sufficiently complete for an agent to invoke the tool correctly, with no obvious gaps.

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

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

With 0% schema description coverage, the description adds extensive value by explaining each parameter's meaning, allowed values (e.g., offense codes, level options), required conditions (state for 'state' level, ORI for 'agency' level), and date format. This fully compensates for the schema's lack of descriptive metadata.

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

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

Clearly states it gets summarized SRS crime data including specific metrics (offense rates, actuals, clearances, population coverage). The verb 'get' and resource 'summarized crime data' are specific, but it does not explicitly distinguish from sibling tools like get_crime_trends or get_nibrs_data.

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

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

Provides detailed parameter guidance (e.g., state required for 'state' level, ORI for 'agency' level, date format examples) but does not explicitly state when to use this tool versus alternatives, nor when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It discloses the data scope and parameter dependencies (e.g., year required for summary). However, it does not mention read-only nature, rate limits, or data source details. The behavioral traits are partially transparent.

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

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

The description is concise, starting with a clear purpose statement, followed by a structured Args list. Every sentence adds value, and there is no redundancy. The front-loaded summary aids quick understanding.

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

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

With 6 parameters, 1 required, and an output schema present, the description covers all parameters' roles and some constraints. However, it lacks guidance on valid parameter combinations and error conditions. The presence of an output schema reduces the burden for return value documentation, but additional context would improve completeness.

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

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

The schema has 0% description coverage, but the tool description explains each parameter's meaning and constraints (e.g., location: 'national or two-letter state abbreviation'). This adds significant value beyond the schema's type definitions. However, some format details (e.g., year range) are missing.

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

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

The description clearly states 'Get use of force data from law enforcement agencies' and specifies the scope: incidents resulting in death, serious bodily injury, or firearm discharge. This distinguishes it from sibling tools like get_arrest_data, 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.

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

The description explains parameter requirements (e.g., which params are required for each report_type) but does not provide explicit guidance on when to use this tool vs. siblings. No 'when to use' or 'alternatives' section is present.

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

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

No annotations are provided, so the description fully carries the burden. It explains the behavior for each lookup type, pagination (offset, limit order), and name_filter application. It does not cover error handling or rate limits, but the core behavior is well disclosed.

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

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

The description is well-structured with a clear Args section and front-loaded purpose. It is thorough but not overly verbose; every sentence adds value. Minor redundancy (e.g., repeating 'required for' multiple times) could be trimmed, but overall efficient.

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

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

With 7 parameters and an output schema present, the description covers all parameter relationships, pagination order, and usage details. It does not need to explain return values since the output schema exists. The description is fully complete for an agent to use the tool correctly.

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

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

The input schema has 0% description coverage, meaning the properties have no descriptions. The tool's description fully compensates by explaining each parameter's purpose, requirements, and constraints (e.g., required for certain lookup_type). This adds significant meaning beyond the schema.

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

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

The description clearly states the tool's purpose: to look up law enforcement agencies by state, ORI code, or judicial district code. It distinguishes itself from sibling tools, which focus on crime data, by being the sole agency lookup tool.

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

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

The description specifies three lookup types and their required parameters, guiding when to use each. It does not explicitly mention when not to use this tool or alternatives, but sibling tools are distinctly different, so the guidance is clear.

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

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

The description discloses that 'clear' wipes the entire cache, which is a significant destructive behavior. No annotations are provided, so the description carries the transparency burden. It lacks details on auth requirements, rate limits, or what cache stats include.

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

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

The description is very concise, with a clear opening statement and a structured args list. Every sentence adds value, and there is no wasted text.

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

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

Given the tool's simplicity (one parameter, clear actions) and the presence of an output schema (so return values are handled externally), the description is complete. It covers what each action does, which is sufficient for correct invocation.

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

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

Schema description coverage is 0%, but the description fully explains the single 'action' parameter by enumerating the three possible values ('status', 'clear', 'clear_expired') and describing what each does. This adds essential meaning beyond the bare schema.

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

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

The description uses a specific verb 'Manage' with the resource 'FBI Crime Data response cache', and lists three distinct actions (status, clear, clear_expired). It clearly distinguishes from sibling tools which are all data retrieval or lookup tools.

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

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

The description implies usage for cache management via the actions listed, but does not explicitly state when to use or exclude alternatives. However, the context of sibling tools makes the differentiation clear.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool reads spillover files, explains the 'list' special value, and details offset/limit behavior. It is transparent about defaults and limits.

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

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

The description is concise and well-structured: a short purpose statement, a usage hint, then parameter descriptions. Every sentence adds value, and 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.

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

Given 3 parameters, no annotations, and an existing output schema, the description covers all necessary aspects: what the tool does, when to use it, and detailed parameter semantics. It is fully adequate.

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

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

Schema coverage is 0%, so description must add meaning. It explains filename with an example and the 'list' option, offset as character position with default 0, and limit with default and maximum. This goes well beyond schema.

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

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

The description clearly states the tool reads spillover files saved when tool responses exceed size limits. It distinguishes from sibling tools that retrieve specific data categories, making its unique purpose clear.

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

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

The description explicitly says to use this tool when a truncated response provides a spillover notice, and mentions the filename is from that notice. It does not discuss when not to use it or offer direct alternatives, but the context is sufficient.

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