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

Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely new behavioral facts: the call costs $0.002 USDC via x402 on Base/Solana/Arc and failed calls are not charged, which is critical pre-invocation context for a paid tool. It also enumerates what a detail lookup returns (classifications with hourly rate and fringe benefit, covered counties, construction type, revision, publish date). Rate limits and pagination behavior are not covered.

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 core capability and its two modes are front-loaded in the first sentence, with pricing and return shape following. Dense and largely waste-free, though the pricing clause is long enough that it could be trimmed without losing meaning.

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 six optional parameters, an output schema, and full schema coverage, the description supplies exactly the missing pieces: the two operating modes, ID format examples, return-field inventory, and payment terms. An agent can decide to call it and how to call it correctly without further inference.

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 100%, so a 3 is the floor; the description goes beyond it by giving concrete format examples for wd (TX20260253 vs 2015-5245) and framing search inputs as state/county/text filters. The wd-versus-search mode split, which the flat schema cannot express, is the key semantic addition.

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 resource (US federal prevailing wage determinations from SAM.gov/DOL) and two distinct operations: search determinations by state/county/text, or open a single determination by number. The parenthetical examples of determination IDs make the resource concrete and separable from any sibling directory 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?

Clearly describes the two invocation modes and which parameters select them ('search ... by state, county or text, or open one determination'), plus the dba/sca distinction carried in the type enum. It stops short of explicit when-not-to-use guidance or naming an alternative tool, but the context needed to choose a mode is present.

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