Bydleno – prodej bytů

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

Beyond the annotations, the description discloses return shape (first ten listings, total count, listing link), handling of unknown enum values and unknown parameters (dropped), fallback behavior for unrecognized locations, zero-result behavior, and error behavior via isError. It also explains the free listing versus paid detail model and instructs the agent to always offer links.

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 front-loaded: purpose and return behavior come first, followed by parameter guidance, error behavior, and pricing/link instructions. Given 32 optional parameters, the length is proportionate and no sentence is wasted.

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 complex 32-parameter search tool with annotations and an output schema, the description covers the critical gaps: optionality, common filters, enum matching, location normalization, empty results, errors, and pricing constraints. Nothing essential for selecting or invoking the tool 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 description coverage is 100%, so the baseline is 3, but the description adds meaningful global semantics: optionality, common filters, exact enum-label matching, and Czech first-case location formatting with a maximum of ten values and fallback search behavior. It does not add per-parameter guidance for many of the 32 tersely described filters, so it stops short of 5.

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 opens with a precise verb and resource: 'Najde byty na prodej v Česku podle zadaných kritérií.' It also states the return scope (first ten listings, total count, link), so the agent knows exactly what the tool is for without opening 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?

It gives clear usage context: all parameters are optional, an empty search returns newest listings, and the agent should pass only criteria the user actually mentioned. It also names the most common parameters, though it does not state explicit when-not-to-use conditions or alternatives (there are no sibling tools).

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