Jahresabrechnung (Stand)

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds that the result is an aggregate status report with per-category costs (pro-rated), missing readings, open_issues and a deadline, which is useful behavioral context. It does not mention data freshness, whether the numbers are provisional, or volume/size characteristics.

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 dense sentence that front-loads the resource and then enumerates the result sections in a scannable list. It is efficient with no filler, though the long run-on form makes it slightly harder to parse than a broken-out list would be.

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 an output schema present, the description need not explain return values, and annotations carry the safety profile; the two required params are fully documented in the schema. What remains missing is the routing information against sibling tools, which matters given several overlapping read tools in the catalog.

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% and both required parameters already carry descriptions, including a cross-reference to list_properties and to billing_year_start for the year semantics. The description adds nothing beyond the schema, so the baseline of 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 and scope: the status of a property's annual statement, then enumerates exactly what is included (cost per cost category with prior-year comparison, missing meter readings, tenants and their statements, open_issues, billing deadline). This is far more specific than the name alone. It does not, however, distinguish itself from potentially overlapping siblings such as get_statement or precheck_statement, leaving the agent to infer the difference.

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?

Usage is only implied: an agent can infer this is a read-only overview to consult before or during statement preparation, but the description never says when to call it versus get_statement, check_hausgeld or precheck_statement. No prerequisites or exclusions are stated.

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