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

Annotations already declare a non-read-only, open-world, non-idempotent, non-destructive mutation. The description adds substantial behavioral context beyond that: a two-call OTP flow, intermediate status 'verification_required', verificationId return, 15-minute expiry, 5 attempts, calendar invitation on success, and error handling for taken slots or existing accounts. No contradiction with annotations.

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 long but well-structured, with STEP 1 and STEP 2 labels and the critical constraint ('never guess, invent or repeatedly retry codes') highlighted. Most sentences earn their place by covering verification, expiry, retries, and error alternatives. A small amount of repetition with the schema descriptions keeps it from being maximally tight.

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 two-step, open-world booking tool with 7 parameters and an output schema, the description covers everything an agent needs: sequencing, required inputs per step, OTP rules, error cases, and identity restrictions. Return values are left to the output schema, which is appropriate.

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 carries parameter meanings and constraints. The description still adds value by grouping parameters into step 1 vs step 2, clarifying that step 2 should be called with only verificationId and otp, and reinforcing that email must be the user's own address. That is useful operational framing beyond the schema, though not exhaustive per-parameter detail.

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 precise verb and resource ('Books a free 15-minute initial phone call with the AfAMax team') and immediately frames it as a two-step process. It also names the sibling get_available_appointments as the source of the slot, so an agent can distinguish this from the other appointment/pricing tools without opening schemas.

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 explicit when-to-use and step-by-step conditions: step 1 only after the user picks a slot from get_available_appointments and confirms name/email, step 2 only with the e-mailed code. It also states when not to proceed (slot taken, existing account email) and the alternative action for each, plus a firm usage restriction ('Only book for the person you are talking 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 cover safety (readOnly, idempotent, non-destructive, closed-world), yet the description adds real behavioral context beyond them: the omission of modernization inputs produces the highest possible benefit, the response carries an attribution link to the AfAMax calculator that should be cited, and the result is explicitly non-binding and not a substitute for tax/legal 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?

Well front-loaded: purpose first, then scope, then handling guidance, then the attribution/disclaimer. It is dense and nearly every sentence earns its place, though the 'ask for all eight modernization states' instruction partially duplicates the schema's own note, adding mild redundancy.

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 calculation tool with an output schema, the description covers what an agent needs: purpose, scope, the key default risk (omitted modernization), and result caveats. Return values are appropriately left to the output schema; only minor gaps remain, such as no note on partial vs. full input handling.

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; the description earns an extra point by adding semantics the schema does not carry, specifically the whole-building-vs-unit choice for apartment buildings and the consequence of omitting the eight modernization component states.

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 names a specific verb and resource ('Calculate an indicative German real-estate depreciation (AfA) estimate') and situates it in a named product (AfAMax). The domain term AfA plus the enumerated outputs (remaining useful life, annual/monthly AfA, statutory comparison, tax savings) make it unmistakably distinct from siblings like calculate_purchase_price_allocation.

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 clearly scopes usage ('residential German property') and gives concrete handling guidance for apartment buildings (whole-building vs. per-unit). It does not explicitly name when not to use it or point to an 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?

Adds meaningful context beyond the annotations: the result is 'free, non-binding,' 'does not replace tax or legal advice,' and the attribution link should be cited as the source. It also discloses that omitting optional values does not invalidate but does reduce reliability. The annotations already cover the read-only/idempotent safety profile, so richer detail on limits would still help.

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-loads the core purpose followed by method, conditional requirements, optional enhancements, and disclaimer. It is somewhat long and partly echoes schema descriptions, but every sentence carries operational or usage information.

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 16-parameter calculation tool with an output schema present, the description covers the required conditional fields, the purpose of optional fields, the attribution/citation obligation, and the legal disclaimer. Nothing needed to invoke it 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?

With 100% schema coverage the baseline is 3, but the description adds cross-parameter meaning: monthlyNetColdRent enables the income method as a cross-check, garages/underground parking are valued separately, condominium requires both co-ownership fields, and residential/commercial requires the share category. This dependency guidance exceeds what the per-field schema notes convey.

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 ... German property purchase-price allocation (Kaufpreisaufteilung)') and names the governing method (BMF Arbeitshilfe). It is clearly distinguishable from the sibling calculate_property_depreciation, which covers a different computation.

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?

Gives explicit context: 'Use this to divide acquisition costs between non-depreciable land and the depreciable building,' and states conditional triggers for parameters (condominium needs both co-ownership values; residential/commercial needs its share category). It does not, however, name an alternative tool or a when-not-to-use condition versus siblings.

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 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.