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

Well beyond the annotations, it discloses the e-mail verification side effect, the 15-minute code expiry, the 5-attempt limit, the 'verification_required'/'booked' status transitions, the calendar invitation, and the existing-account error path. The only gap is that destructiveHint=true is never reconciled with what is actually consumed (a slot), though the booking context makes that implicit.

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?

Two clearly labelled steps with the critical constraint ('never guess, invent or repeatedly retry codes') stated inline. It is dense but front-loaded and nearly every sentence carries operational information; the German-language duplication lives in the schema, not here, so the description itself stays lean.

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 multi-step, stateful, non-idempotent booking tool, the description covers prerequisites, both call shapes, failure modes, and success outcome. An output schema exists, yet the status values are still named, which removes any ambiguity about how to interpret the two-step response.

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%, so baseline is 3, but the description adds genuine meaning: it partitions parameters into step 1 (startDateTime, name, email, phone, locale) versus step 2 (verificationId, otp), and stresses that startDateTime must be copied exactly from get_available_appointments and that otp must never be guessed. That goes beyond the per-field schema text.

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 ('Books a free 15-minute initial phone call with the AfAMax team') and immediately frames the two-step structure. It is clearly distinguishable from the sibling get_available_appointments, which only lists slots, so an agent can pick the right tool without opening either schema.

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 sequences the workflow: pick a slot from get_available_appointments first, then call step 1, then step 2 with verificationId and otp. It also gives exclusions and fallbacks — existing AfAMax accounts must book on the website, taken slots require re-listing, and bookings are limited to the person being spoken to.

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

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

Annotations already convey the safe read-only, idempotent profile, and the description layers on substantive behavior: the output compares the RND rate against the statutory rate and yields annual/monthly AfA plus estimated tax savings, the omission of modernization components defaults to 'no modernization' and inflates the benefit, it returns a non-binding result that does not replace tax advice, and it mandates citing the attribution link as the source. This is far beyond what the annotations provide.

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?

Purpose is front-loaded in the first sentence and every subsequent sentence carries distinct content (usage triggers, building-vs-unit rule, modernization default, attribution requirement, disclaimer). It is a single dense block that would scan better segmented, which keeps it from a 5, but there is little waste.

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 13-parameter domain calculator with an output schema, the description covers what an agent needs: when to invoke, the apartment-building input rule, the consequence of omitting customization data, the attribution-citation duty, and the non-binding nature of the result. Return values are also summarized despite the output schema existing.

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 baseline is 3 and the schema does most of the work. The description still adds genuine semantic guidance: pass whole-building figures or compute units separately for apartment buildings, and supply all eight modernization component states because omission implies no modernization and produces the maximum RND benefit.

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 precise verb+resource ('Calculate German property depreciation (AfA / Gebäudeabschreibung) and the building's remaining useful life (Restnutzungsdauer)') and scopes it to residential rental property through AfAMax. The purpose is unambiguous and readily separable from the unrelated siblings (appointments, price/product lookups), and even the adjacent real-estate calculator sibling covers a different calculation.

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?

Rich when-to-use triggers: calculating AfA, asking about faster-than-2% depreciation under § 7 Abs. 4 EStG, mentioning verkürzte Restnutzungsdauer, evaluating whether a Restnutzungsdauergutachten pays off, or just describing an old/unrenovated building and asking what is deductible. It lacks any explicit 'when not to use' or named alternative tool, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description layers on real behavioral context: free/non-binding, inventory deducted before allocation, depreciationBase meaning, the attribution link's behavior and citation obligation, and that omitting optional values does not invalidate the result. This is well beyond what annotations provide.

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 the purpose and scope, then moves to required-vs-optional prompting. It is dense across many sentences, and the garage/underground-parking advice is somewhat repetitive of the schema's own descriptions, but every sentence carries actionable content.

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 16 parameters, 7 required, three enums and an output schema present, the description covers the pieces an agent needs that structured fields do not: conditional parameter requirements, the depreciation use case, the optional-value tradeoff, and the disclaimer. Return values need not be explained since an output schema exists.

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 baseline is 3, but the description adds cross-parameter conditions not obvious from the schema alone: a condominium needs both co-ownership values, a residential/commercial building needs its commercial share category, and monthlyNetColdRent enables the income method as a cross-check. It adds genuine meaning rather than restating field docs.

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 ('Calculate a free, non-binding German property purchase-price allocation (Kaufpreisaufteilung)') and names the mechanism (BMF Arbeitshilfe via AfAMax). An agent can distinguish this from calculate_property_depreciation without opening either schema.

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 frames the use case ('e.g. when a user asks how much of the price they may depreciate or wants to check the Finanzamt's split'), and states a negative constraint (comparative valuation unavailable because the public contract excludes surveyor-only factors). It also tells the agent which optional inputs to solicit and why, which is guidance a schema cannot give.

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

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds genuine behavioral context beyond that: slots are live and can be taken at any time, so results go stale, and the response attribution links to a contact page for direct booking.

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 what the tool returns and its constraints, then the booking handoff and the freshness warning. Dense but every sentence carries operational value; no filler.

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?

An output schema exists so return-value explanation isn't required. The description still completes the workflow picture: timezone, weekday constraint, locale behavior, booking handoff, and staleness warning. Nothing an agent needs to route or call correctly 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?

Schema coverage is 100%, so the baseline is 3. The description goes further by explaining how to use maxSlotsPerDay in practice (a sample spread across the day, default 8) and the specific re-call pattern with days:1 and maxSlotsPerDay:32 for a targeted time, which is not derivable from the schema alone.

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 (lists) and resource (open appointment slots) with scope details: free, non-binding, 15-minute initial phone call, weekdays, Europe/Berlin, grouped by day. An agent can instantly distinguish this from book_appointment and the unrelated calculation siblings.

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?

Explicit routing: for a specific time, re-call with days:1 and maxSlotsPerDay:32; to book, pass startDateTime unchanged to book_appointment; and re-check rather than reusing an old list. The alternative (book_appointment) and the conditions selecting each path are named directly.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real behavioral context beyond them: no discount handling, binding price at order time, per-flat pricing triggered only for multi-unit buildings, and an attribution link that should be cited as the source. The only shortfall is that it repeats some output-shape information (price.totalPrice, surchargeTable) that the output schema already carries.

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 and price/VAT scope in the first clause, then caveats, then the sibling redirect. It is dense but long, and the parenthetical product enumeration duplicates the enum descriptions in the schema, which is the one clearly removable block.

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?

Covers pricing scope, VAT, surcharge sources, caveats about discounts and binding prices, and a redirect to the sibling tool, with return values handled by the output schema. Only the product list is redundant; nothing an agent needs to call or quote correctly 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?

Schema description coverage is 100%, so the schema already documents every parameter including the productType + totalFlatsCount interaction and the surcharge effect of viewingType. The description restates those meanings rather than adding new semantics, so it sits at the baseline for a fully documented schema.

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 ('Returns AfAMax's current list price in EUR, incl. German VAT') and scopes it to exactly one product, enumerating the enum values with short glosses so the agent can map a user request to a product code without opening the schema. It also draws a hard boundary against the closest sibling, calculate_property_depreciation.

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 states what the tool is not for ('This tool only quotes prices') and names the alternative to use instead ('use calculate_property_depreciation' for payoff estimation). It also supplies operational guidance the agent must relay: discount codes are not applied and the order-time price is binding.

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