cpu_list_lots

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

With no annotations, the description carries the full behavioral burden, and it does so thoroughly: it discloses this is a public read, explains that 'all' means open plus incoming and never sold/cancelled/evicted lots, notes that frozen lots are hidden under the default 'open', and mentions server clamping of radius to 50 and limit max 200.

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 dense but every clause earns its place: it front-loads the core purpose, packs the key parameters into one readable sentence, and finishes with routing and a critical exclusion case. No filler or repetition of schema 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?

Despite no output schema, the description covers the important edge cases an agent needs before calling: availability nuances, evicted-lot exclusion, nearest/zone coupling, pagination bounds, and server clamping. For a complex 11-parameter, all-optional listing tool, nothing essential for correct selection and invocation is 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it clarifies that 'availability' defaults to open, defines 'all' precisely, ties 'nearest' to the zone requirement, and explains radius in grid steps with clamping. This extra semantic context justifies an above-baseline score.

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 ('Browse marketplace lots') and resource, then enumerates the filtering, sorting, pagination, and zone capabilities. It also explicitly distinguishes this tool from cpu_get_markets (compact overview) and cpu_list_my_lots (seller's evicted lots), so an agent can tell it apart without inspecting the schema.

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 routing guidance: 'start with cpu_get_markets for a compact overview, then drill in here' and says an evicted lot never appears here, with the seller finding it via cpu_list_my_lots. It also explains the availability semantics (open, incoming, all) well enough to choose the right parameter value.

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