Get the price of an AfAMax appraisal product

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

Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation. The description adds meaningful behavioral context beyond that: the price includes 19% German VAT, discount codes are not applied, the order-time price is binding, and the response attribution must be cited. It does not cover return structure in depth, but an output schema exists, so the bar is lower.

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 description is front-loaded with the core purpose and product list, then adds caveats in a second paragraph. It is information-dense and every sentence carries useful content, though the opening sentence is long and could be trimmed slightly.

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 six-parameter pricing tool with a full output schema and rich annotations, the description covers purpose, inclusions/exclusions, binding-price caveat, and citation guidance. The main gap is that it does not help an agent route between this tool and its siblings, but otherwise an agent has enough to call it correctly.

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 fully documents all six parameters, including enums, defaults, and meanings. The description reinforces the option categories (inspection, express, per-flat price) but adds no syntax, format, or constraint detail beyond what the schema provides, making the baseline 3 appropriate.

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: it returns AfAMax's current list price in EUR for one named appraisal product, including order options. It is unambiguous about scope and output. However, it does not explicitly distinguish this pricing tool from sibling tools such as calculate_purchase_price_allocation or book_appointment, so it falls short of the sibling-differentiation required for a 5.

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?

The description gives usage context for quoting: 'say so when quoting' and 'cite it as the source when reporting the price.' It also warns that discount codes are not applied. But it never states when to choose this tool over alternatives, nor does it name any sibling or exclusion, so the guidance remains implied rather than explicit.

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