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

Annotations already declare it as a read-only, idempotent, non-destructive local computation, so the safety bar is low. The description adds genuinely useful behavior beyond them: purchase costs of the federal state are factored in, missing interest/repayment fall back to suggested values that are marked in the result, and the output includes an Objelio search link with the price as maximum. It closes with the important caveat that this is an estimate, not financing advice.

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?

The trigger and purpose are front-loaded, and each sentence carries information: trigger, computation, input gathering, fallback behavior, return value, caveat. The embedded German example query is helpful for intent matching but is the one element that adds length without adding rules.

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?

For a read-only estimation tool with nine parameters and an existing output schema, the description covers everything the agent needs: when to call it, which inputs to collect, what happens when optional inputs are missing, what the result contains, and the non-advice disclaimer. Return-format detail is correctly left to the output schema.

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 the schema already documents all nine parameters including the enum and numeric bounds, making 3 the baseline. The description adds little parameter-level detail beyond confirming which inputs to solicit and that interest/repayment are optional with marked defaults; it says nothing about how ort/plz/state/property_type steer the generated search link.

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: 'Estimates which purchase price a user can afford from equity and the monthly loan rate, after purchase costs of the federal state.' It also gives a concrete user-question trigger and distinguishes this estimate from the sibling calculate_purchase_costs by naming the purchase-cost treatment as an input assumption rather than the output.

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 gives an explicit invocation condition ('Use this when the user asks how expensive a property they can afford') plus the follow-up behavior of asking for equity, monthly rate and, if known, interest and repayment. What is missing is an explicit exclusion, e.g. when to prefer calculate_purchase_costs or search_listings instead, so the agent must infer the boundary.

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