get_expanded_property_data

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.