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

Beyond readOnly/openWorld annotations it discloses rate/load behavior ('every call is a request to the site', one request at a time, results cached), the STOP error protocol (retry nothing, no workaround, tell the user), the no-geocoding constraint, and the meaning of low_confidence and null estimated_value.

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 and constraints are front-loaded, but the single dense paragraph then enumerates the whole result shape, which duplicates the output schema and buries the warning about mixing price regimes in the middle of a very long sentence.

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 network-dependent, open-world estimator with an output schema, it supplies everything an agent needs: coordinate sourcing, request etiquette, failure handling, and interpretation caveats for low-confidence or null results.

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 it starts at baseline 3; the description adds meaning the schema lacks — that address is sent but does not set the location, that limit=0 yields only the estimate and stats, and that estimated_value may not equal price_per_m2 × area_m2.

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 ('Estimate the value of a flat of a given area at a point in Poland') plus the data source (RCN transaction prices). It explicitly separates itself from the asking-price siblings, so an agent can route without opening another 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?

Gives the triggering user question ('what a flat may be worth or whether its price is market'), names concrete sources for the required coordinates (user, deweloperuch_search_locations, user's own data) and warns against batching many points. It also groups siblings into two price regimes that must not be mixed.

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