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 does disclose genuinely useful behavior: the aggregate default ('yearly', summing monthly), that it only applies to data_type='counts', and that incomplete years are flagged in a top-level '_partial_years' key with unweighted rate averaging. It omits any mention of permissions, rate limits, or error conditions, leaving real gaps for a query tool with no annotation coverage.

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

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

A one-line summary is front-loaded above an Args list in which each entry adds distinct value (formats, examples, conditional requirements). It is verbose but not padded; nearly every clause earns its place, though the argument list is long enough that it could be tightened slightly.

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?

An output schema exists, so return-value documentation is largely unnecessary, and the description instead explains the one non-obvious output feature ('_partial_years'). For a nine-parameter, five-required query tool with no annotations, coverage of inputs and aggregation behavior is solid, with only permission/error context missing.

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, and it largely does: it documents all nine parameters with formats and examples ('mm-yyyy', offense codes like '11'/'30'/'150', level values, data_type 'counts'/'totals', category values, aggregate semantics). A few semantics remain thin (e.g., the 'sex' vs 'race' category distinction, valid level/category enumerations), but far more meaning is added than the bare schema provides.

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

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

Starts with a specific verb and resource: 'Get arrest statistics by offense, optionally broken down by demographics.' The scope (offense-level arrest counts, optional demographic breakdown) is clear enough to separate it from siblings like get_nibrs_data or get_hate_crime_data. It does not, however, explicitly name or contrast against any sibling, 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.

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

The description routes the agent to a sibling for offense codes ('Use get_reference_data with data_type="offenses" ...'), which is a concrete usage instruction, and it states when state/ori are required. But there is no guidance on when to choose this tool over other crime-data siblings (e.g., get_summarized_crime_data, get_crime_trends), so usage is implied rather than fully specified.

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?

With no annotations present, the description carries the full burden and does fairly well: it discloses that '_partial_years' flags years with fewer than 12 months and that rates in those cases are unweighted averages of available months, plus the constraint that 'aggregate' only applies to counts. It omits permission/auth or rate-limit context, but the retrieval-affecting behavior is substantially 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 purpose is front-loaded in one sentence and the args list is compact with no filler. It is appropriately sized for a 7-parameter tool, though the parenthetical detail in the aggregate note is slightly dense.

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?

An output schema exists, so return values needn't be explained, and the description still usefully flags the '_partial_years' output key. Combined with full parameter documentation, the definition is complete enough for an agent to invoke it correctly; only cross-tool routing guidance is absent.

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 entirely, and it does: every one of the 7 parameters gets meaning plus format guidance (mm-yyyy, two-letter abbreviation, ORI code, conditional requirements tied to 'level', enum-like values for level/data_type/aggregate). This is far beyond what the bare schema provides.

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

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

The description opens with a specific verb and resource ('Get Supplementary Homicide Report (SHR) data') and enumerates the detail categories it returns (demographics, weapons, circumstances). It is clearly distinguishable from generic siblings like get_summarized_crime_data, though it never explicitly names an alternative, which keeps it 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.

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

There is no statement of when to choose this tool over siblings such as get_summarized_crime_data or get_expanded_property_data. The parameter notes imply usage contexts, but the agent must infer the routing decision entirely on its own.

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

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

With no annotations, the description carries the full burden and does disclose a genuinely non-obvious behavioral trait: years with fewer than 12 months are flagged in a top-level '_partial_years' key and rates are unweighted averages of available months. It also documents aggregation behavior and defaults. It stops short of describing the read-only nature, data freshness, or rate/coverage 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?

Purpose is front-loaded in a single sentence, followed by a compact Args list where each entry earns its place. The aggregate line is somewhat run-on, bundling the aggregation semantics with the _partial_years caveat, but no content is redundant.

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

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

All 8 parameters are documented, an output schema exists so return values need not be re-explained, and the description even calls out the _partial_years output key. The only gap is routing guidance relative to the many sibling crime-data tools, which an agent would need to select this tool confidently.

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 schema gives an agent nothing but names and types. The description fully compensates: it enumerates offense codes (NB/NL/NMVT/NROB), geographic levels, the counts-vs-totals meaning of data_type, date formats (mm-yyyy), conditional requirements for state and ori, and the aggregate default with its special semantics.

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

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

States a specific verb and resource (property crime data with stolen/recovered property values), which is clearly narrower than siblings like get_summarized_crime_data or get_crime_trends. It never explicitly names or contrasts with those siblings, so an agent must infer the boundary. Clear but no sibling differentiation.

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

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

The description implicitly guides usage through parameter semantics (data_type 'counts' for time series vs 'totals' for value breakdowns; state required at level 'state'; ori required at level 'agency'). However, it never says when to choose this tool over alternative crime-data tools, nor states any exclusions. Implied usage only.

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, and it steps up: it explains the _partial_years flagging behavior and that rates are unweighted averages of available months, which is meaningful edge-case disclosure. It omits auth, rate limits, and default-vs-explicit behavior on some fields, keeping it 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.

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

Front-loads the one-line summary, then a clean Args block; each entry earns its place. Slightly verbose in a few spots (e.g., repeating default semantics), but no filler or redundancy.

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

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

For an 8-param tool with an output schema and no annotations, the description covers formats, conditional requirements, defaults, edge cases, and a reference-data pointer. What remains missing is confirmation of return structure beyond the short summary, but the output schema covers that.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: every parameter gets meaning, formats (mm-yyyy), conditional requirements (state required when level='state'), example values for bias codes with a lookup tool pointer, and an explicit cross-parameter constraint (aggregate applies only when data_type='counts').

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?

States a specific verb and resource ('Get hate crime statistics') and enumerates the returned data domains (incidents, victim types, offense types, offender demographics, locations). It does not explicitly contrast with siblings like get_nibrs_data or get_arrest_data, so sibling differentiation is implied rather than stated.

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

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

Usage is implied through parameter descriptions (e.g., required state/ori per level, bias lookup pointing to get_reference_data). There is no explicit when-to-use versus when-to-use-instead guidance relative to the many similarly-scoped crime-data 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. 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 the burden. It discloses a meaningful behavioral trait: partial-year flagging via a top-level '_partial_years' key and that rates are unweighted averages over available months. These are genuinely useful and not derivable from the schema. But it omits permissions, error behavior, pagination/rate limits, and whether results are cached.

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

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

A single summary sentence followed by a structured Args block mirroring the schema. Front-loaded purpose with parameter detail in a scannable format. Slightly verbose in repeating schema field names, but the added semantics justify the length.

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

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

Given 8 parameters, no annotations, and an output schema already present, the description covers parameter semantics well and adds behavioral context about partial years. It stops short of describing auth requirements, error cases, or how the output is shaped, but the output schema reduces that need.

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, and it does: it explains offense codes with examples, level values, date format (mm-yyyy), data_type semantics, state/ori conditionality on level, and aggregate behavior. This substantially covers 8 parameters. It's not a 5 only because some ancillary parameters (e.g., defaults interplay, null handling for state/ori) are not fully spelled out.

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?

States a specific verb and resource: fetching NIBRS incident-based crime data across 70+ offense types. It distinguishes itself from siblings like get_summarized_crime_data or get_crime_trends by naming NIBRS specifically, though it doesn't explicitly say how it differs from get_nibrs_estimation.

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

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

It points the agent to get_reference_data for the full offense list, which is a useful routing hint. However, it provides no guidance on when to prefer this tool over get_nibrs_estimation or other crime-data siblings, leaving 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.

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?

With no annotations, the description carries the burden and does so well: it discloses the default aggregation mode, that partial years are flagged under '_partial_years', and that rates are unweighted averages of available months. It stops short of describing pagination, rate limits, or return structure, but the behavioral detail is notably above baseline.

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 summary line is front-loaded and each Args entry earns its place with concrete examples. It is somewhat long, but the added length is informational rather than redundant, so the size is justified.

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?

Because an output schema exists, return values need not be explained, and the description covers all inputs, defaults, and conditional requirements. It could add a brief note on data vintage or caching behavior relative to manage_cache, but for the tool's complexity it is nearly complete.

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

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

Schema description coverage is 0%, so the description must compensate and it does: every one of the 7 parameters is documented with format examples ('mm-yyyy'), enumerated offense codes, valid level values, and cross-parameter dependencies between level and state/ori. This is exactly what a low-coverage schema needs.

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

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

The description states a specific verb and resource ('Get summarized (SRS) crime data') and enumerates the data domains returned (offense rates, actuals, clearances, population coverage). It partially differentiates from siblings by naming SRS data and pointing to get_reference_data, though it doesn't explicitly contrast with get_arrest_data 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?

It gives concrete conditional guidance: 'state' is required when level is 'state', and 'ori' is required when level is 'agency', plus a pointer to get_reference_data for the offense list. No explicit when-not-to-use guidance or sibling comparison is provided.

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

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

No annotations are provided, so the description 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.