List addresses at an access address

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 real value beyond that: it discloses the return granularity ('compact records'), names the returned fields, and explains the expected cardinality for single-family houses.

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 purpose, then example, then return shape, then the pointer to dar_get_address. Four short sentences with little waste; the single-family-house note is marginally tangential but earns its place by setting cardinality expectations.

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 compensates by naming the return fields and describing their compactness. Nothing essential to correct invocation is missing for a simple two-parameter read tool; pagination or ordering behavior is unstated but unlikely to matter at this 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%, so both parameters (access_address_id and the status enum) are already fully documented in structured data. The inline example illustrates realistic ID usage but adds no syntax or semantic detail beyond the schema, 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?

States a specific verb and resource with scope: 'List the unit addresses (floors/doors) that belong to one access address (husnummer).' The concrete example output (12 addresses at Oehlenschlægersgade 35) lets an agent distinguish it immediately from sibling tools like dar_get_access_address and dar_get_address.

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?

Explicitly routes to dar_get_address for full detail and notes that a single-family house typically yields one address with no floor/door, which tells the agent when this tool is useful but may return little. It does not explicitly contrast with the closely named siblings dar_list_access_addresses or dar_get_access_address, so the routing guidance is clear but partial.

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