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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful scope context beyond them: the data vintage (Stichtag 01.01.2026), the fact that only Wohngebietszonen are covered (commercial zones excluded), and that a Vorjahresvergleich is included. It does not describe match behavior when a name is misspelled or unmatched.

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?

A single front-loaded sentence that names the resource first, then the payload, then the filter; no filler. It is dense (abbreviations like €/m², Stichtag) but every clause 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?

With no output schema, the description correctly specifies the return payload (Median, Minimum, Maximum, Vorjahresvergleich) and the coverage set (97 Ortsteile via null). Scope, date, and geography are all present; only edge-case behavior on unmatched queries 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?

With 100% schema description coverage and only one parameter, the schema already documents the Ortsteil/Bezirk-or-null semantics fully. The description's "Filter nach Ortsteil oder Bezirk" restates that without adding format, matching, or case-handling detail, so the 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?

Names a precise resource (Amtliche Bodenrichtwerte €/m² per Berliner Ortsteil) with the exact statistics returned and the reference date, so the agent knows this is official land-value data rather than a generic price feed. It is not tautological and reads clearly against siblings like get_area_prices or get_market_overview, but it never explicitly states how it differs from those adjacent tools.

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?

"Filter nach Ortsteil oder Bezirk" implies how to scope the query and the residential-zone framing implies the use case, but there is no explicit when-to-use statement and no routing away from the overlapping get_area_prices / get_market_overview siblings. Usage is inferable rather than stated.

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