LivinIsto

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses non-obvious data-quality behavior: the median is suppressed below 8 comparable listings, unknown places return found=false with no nationwide fallback, and the figure is the ASKING price of current offer rather than a transaction price. These are exactly the traits an agent cannot learn from the schema or hints.

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?

Front-loaded with the use case, then returns, then edge-case behavior, then exclusions — a sensible order with no filler sentences. It is dense and somewhat long, but each sentence adds a distinct constraint or output fact.

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 four parameters with one required, an output schema, and a geographic/open-world constraint, the description covers everything an agent needs: trigger conditions, aggregate semantics, suppression threshold, not-found behavior, and scope limits. Return values are additionally summarized even though the output schema exists.

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% and two parameters have enums, so the schema already carries the parameter meaning (rooms, transaction default predaj, propertyType default byt). The description only implies filtering by 'comparable listings' without adding format or default details beyond the schema, so the baseline 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 states a specific verb and resource — returning the typical (median asking) price per m² for a location — and enumerates exactly what comes back (median, sample size, middle range, group level, date). This is unmistakably distinct from the siblings search_properties and get_property_details, which operate on individual listings rather than an aggregate statistic.

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 opens with an explicit trigger ('Use this when the user asks how much property costs per m²... or whether a price per m² is reasonable there') and closes with explicit exclusions ('Do not use it to value a specific property's condition, for commercial property or for places outside Slovakia'). Both the when and the when-not are spelled out, leaving nothing to inference.

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

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

Annotations only cover safety (readOnly, idempotent, closed-world); the description adds substantive behavior: what is deliberately NOT returned (agent/seller name, phone, e-mail, ad text, exact address), the remediation for that gap, and the not-found signal ('found is false'). This is disclosure well beyond the structured fields.

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?

Front-loaded with the trigger and the required input, then the return scope and exclusions. It is one dense paragraph with a long parenthetical, so it is efficient but not maximally scannable; every clause still carries information.

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?

Even though an output schema exists, the description covers the practical gaps: field scope, id provenance, exclusion set, alternative path for contact info, and the not-found case. Nothing an agent needs to call this correctly 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 propertyId description already states its provenance; the description reinforces this and adds the non-obvious constraint that ids must not be guessed. Minor added value over the schema, so slightly above the high-coverage baseline.

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?

Names a specific verb+resource ('get property details') and explicitly scopes it to 'one specific property returned by search_properties', enumerating the fact categories returned. An agent can distinguish it from search_properties and get_price_per_m2 without opening a 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 an explicit trigger ('when the user asks for more about one specific property'), names the source tool that must precede it, and adds a hard constraint ('do not guess ids'). It also routes the agent elsewhere for contact data ('the user opens the property's url').

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: unrecognised words are matched against listing text (max 6) and reported in notUnderstood, criteria get relaxed when nothing matches, and results are capped at 10. The limits paragraph is unusually candid about coverage gaps (no foreign property, no commercial, no short stays), EUR/monthly-rent pricing, asking-price and possibly-sold caveats.

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?

Front-loaded with the trigger, then examples, then return shape, then limits — a sound order and every clause carries information. It is, however, a dense run-on paragraph with heavy comma stacking, so it is informationally tight but not visually scannable.

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?

An output schema exists, yet the description still states the result shape (up to 10 properties, price verdict, summary sentence, relaxed criteria, link to all results) and closes the remaining unknowns: query language, coverage, price basis and staleness risk. Nothing an agent needs to call this correctly 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 3 baseline applies, but the description goes well past the schema: it specifies that criteria must be ONE short phrase in Slovak, that numbers are written as the user said them, that sale is the default with "prenájom" for rent, and that surplus words land in notUnderstood. That is genuine compositional guidance the schema's minLength/maxLength does not convey.

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 (search) and resource (properties for sale/rent in Slovakia) and enumerates precisely what is searchable: type, rooms, place, price, area, floor, condition, amenities. It also scopes the corpus (LivinIsto listings plus public Slovak portals), which cleanly separates it from get_property_details and get_price_per_m2.

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?

"Use this when the user wants to find a home in Slovakia" is an explicit, well-defined trigger condition, and the sale-default/rent-keyword rule tells the agent how to frame the request. It never names the sibling tools (e.g. get_property_details for drilling into a listing), so the routing guidance is clear but not exhaustive.

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