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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read with changing data. The description adds the useful 'facts only — no images' limitation and the distinction between sanctioned federal sources vs full-market comps. It doesn't disclose pagination, result count behavior, or potential timeouts, but with readOnlyHint already provided, some burden is relieved.

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?

Three sentences cover purpose, scope/constraints, and data-domain distinction with zero filler. Each sentence earns its place, front-loaded with the core action and following with useful scope qualifiers.

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 a search tool with 11 parameters, no output schema, and only 36% schema coverage, the description does moderate work. It explains what data is searched, the key distinction between raw listings and comps, and the filter dimensions. Given readOnlyHint/openWorldHint annotations and the absence of an output schema, the description is reasonably complete, though it doesn't describe return structure or result count expectations.

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 only 36%, and 11 parameters are undocumented in the description's prose. However, the zip, radiusMiles, q, state, category, priceMin/Max, and source/country enums are described in the schema itself. The description adds filter dimensions at a high level but does not add per-parameter meaning beyond what the schema conveys. With low coverage and no param descriptions in the tool text, 3 is appropriate.

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 ('Search') plus resource ('live GSA federal-surplus auction listings'), and clearly scopes the domain ('facts only — no images'). It lists concrete filter dimensions (state, category, keyword, price, distance) and distinguishes raw listings from sold-price comps, which separates it from sibling sibling get_sold_comps. This clearly differentiates from siblings get_listing (single listing) and get_flip_score (scoring).

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 states clear context: it searches live GSA auction listings, filters by multiple dimensions, and its scope is 'facts only — no images.' It clarifies that raw listings cover sanctioned federal sources while sold-price comps span the full market, which implies when one might need the sibling get_sold_comps instead. However, it doesn't explicitly name alternatives or say 'when not to use,' so a small gap remains.

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