Get Price Benchmark

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

Beyond the readOnly and idempotent annotations, the description exposes non-obvious behaviors: raw single-letter FPDS codes can appear as passthrough data ('not an error'), date filters apply to action_date rather than award date, and combined is 'blended context only, not a real number to price against.' These are exactly the behavioral quirks an agent needs.

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

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

Although long, the description is front-loaded with purpose and usage, then structured parameter guidance, then a critical caveat. Every sentence earns its place; the length is justified by 8 parameters, multiple sibling tools, and important behavioral warnings.

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

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

The description is fully complete for a complex, 8-parameter tool with 0% schema coverage. It covers when to use, parameter semantics, data quirks, and interpretation guidance, and the output schema exists to handle return-value details.

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 carries the entire parameter-documentation burden and succeeds. Every parameter is explained with formats, examples, and semantics: naics is '6-digit, required', set_aside lists valid codes, pricing_type notes the raw-code edge case, value_basis enumerates options, and date_from/to clarify they filter on FPDS action_date.

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 ('Get') and precise resource ('percentile distribution of comparable contract VALUE for a NAICS'), immediately distinguishing itself from siblings like get_price_position and get_labor_rate_benchmark. It also clarifies what it is not ('not a win predictor').

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

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

The description gives explicit context ('Bid & Proposal / Negotiate stage, Pro only') and names complementary tools with their distinct purposes ('Pair with get_price_position to see where YOUR specific value sits, or get_labor_rate_benchmark for the labor-cost input'). The IMPORTANT note tells agents to use pricing-type blocks rather than combined, providing concrete selection guidance.

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