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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds useful behavioral context by disclosing the breadth of data returned (noise, rents, nearby construction), which matters since there is no output schema. It does not mention rate limits, cost, or lookup latency.

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 primary instruction and scoping condition, then a compact enumeration of returned facts. The quadruple-language example list is somewhat bulky, but each example maps to a plausible user phrasing rather than being filler.

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?

With no output schema, the description carries the burden of telling the agent what comes back, and it does so by listing the fact categories. An agent knows what to expect and when to call it; minor gaps remain on result format and coverage boundaries (e.g., non-Swiss addresses are implicitly out of scope).

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%: the address format example and the language enum/default/'use the user's language' rule are all already documented in the schema. The description's multilingual query examples reinforce language handling but add no syntax or format detail beyond the schema, so baseline 3 applies.

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 resource (Swiss address) and enumerates exactly what facts are returned: building attributes, transit, amenities, noise, prices, construction, listings. The phrase 'even without a listing' cleanly distinguishes it from sibling tools like get_listing and search_listings.

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?

Strong trigger guidance ('Use this for ANY Swiss address') plus concrete multilingual example queries that map real user phrasings to the tool. It does not explicitly name alternatives such as area_market_facts or property_value_range, so the when-not-to-use boundary is left implicit.

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