AIR Bandenservice

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond them by disclosing scope of returned data and the 'No personal data' guarantee, which matters for an agent deciding whether it can surface this to a user; it stops short of describing error behavior for unknown refs.

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?

One sentence, front-loaded with the returned resource, and every clause (link to place_order, reference format, privacy note) carries distinct information. Nothing is redundant with the title or annotations.

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 one-parameter, single-purpose read tool with rich annotations, the description covers the identifier format and the nature of the result. There is no output schema, so a little more on what the status response contains would fully close the gap.

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?

The single parameter has no schema description (0% coverage), so the description carries the burden — it names the argument semantically ('by its reference') and gives a concrete format example ('AIR-2026-…'), which is exactly what the schema omits. Additional validation rules are still absent.

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 precisely what is returned (payment and order status) and for which resource (an order placed with place_order), and anchors it to the sibling tool that creates the resource. An agent can distinguish it from search_tyres, get_quote and the other siblings without opening a 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?

The phrase 'of an order placed with place_order' establishes the prerequisite and points to the correct lookup key, so an agent knows this is a follow-up to a placement. It does not spell out exclusions (e.g. use get_quote before ordering), but the usage context is clear.

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, so the bar is lower, yet the description adds real value: it is a live validation that depends on current stock and fitting capacity and touches nothing (no order, reservation, email or charge). It stops short of stating failure modes (e.g. what happens when stock or a fitting slot is unavailable) or whether the quoted price has a validity window.

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?

Three short sentences, front-loaded with the outcome the agent cares about, with the disambiguating negation at the end. Every clause earns its place.

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 5-param tool with nested items/fitting objects and no output schema, the description conveys enough to call it correctly: what is priced, that stock and capacity are validated, and that nothing is committed. The shape of the returned quote is only hinted at ('line by line'), and error behavior is unspecified.

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% and each parameter carries rich text, including cross-references to search_tyres, list_fitting_days and get_shop_info. The description adds little param-level meaning beyond 'these tyres and options', so the baseline 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 verb and output ('the exact total ... line by line, exactly what the payment page will charge') plus the validation performed ('checks stock and fitting capacity'). The closing negation ('does not order, reserve, email or charge anything') cleanly separates it from place_order, so an agent can distinguish it from siblings 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?

The explicit list of things it will not do defines the non-committal path and strongly implies it precedes place_order, and the stock/capacity check tells the agent why to call it. It never names place_order as the alternative to reach for when the user actually wants to buy, so the routing is implied rather than stated.

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 readOnlyHint=true, idempotentHint=true and destructiveHint=false, so 'No side effects' merely restates structured data and earns no credit. The added value is the enumeration of returned content, which helps the agent know what answers this tool can supply, but it doesn't state freshness of the data (e.g., whether prices/hours are cached) or any localization/currency behavior.

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 compact sentence front-loads the returned fields, which is the highest-value information for this tool. The trailing 'No side effects' is redundant against the annotations and could be dropped, but it costs little.

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 no output schema, the description must carry the return shape, and it does so by listing the fields an agent can expect. It is not exhaustive (no mention of whether currency, opening-hour granularity, or ties to list_fitting_days are included), but for a zero-parameter read-only lookup it is essentially complete.

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?

There are zero parameters, so there is nothing to document and the 4 baseline applies. The description correctly implies no input is needed, which matches the empty 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?

The description enumerates exactly what the tool returns (address, hours, phone, delivery fee, fitting price, payment methods, policy links), which is specific enough for an agent to recognize it as the static shop-info lookup. It does not explicitly differentiate itself from siblings like get_quote or list_fitting_days, which also touch pricing/availability, so a small ambiguity remains about which tool to call for fitting prices vs. fitting days.

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 for static shop details rather than order or quote data. There is no explicit 'use this when…' statement and no mention of alternatives, even though get_quote and list_fitting_days partially overlap on price/day information.

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 closed-world, and the description's 'No side effects' merely restates that. The one piece of added context is the 4-week lookahead bound on results; nothing is said about what a 'day with room' means (capacity, slots, times) or the result format.

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 short sentences with zero waste; the resource and the 4-week scope are front-loaded before the safety note.

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 one optional parameter, full annotations and no output schema, the definition is workable but thin: it never says what a returned 'day' looks like or whether capacity/counts are included. Since no output schema exists, that gap falls on the description and is left unfilled.

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 the supplierItems description already explains the next-day-arrival rule that drops the first day, so the schema does the heavy lifting. The tool description adds no parameter meaning of its own, leaving the baseline of 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?

Names a specific resource (workshop days with fitting capacity) and a concrete scope (the next 4 weeks), so an agent can tell this is an availability lookup rather than an order/status tool. It would be a 5 if it explicitly contrasted itself with siblings like place_order or get_order_status.

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 4-week horizon implies this is a pre-booking availability check, but the description never says when to use it or what to do instead. No alternative tool is named, so the routing signal is only inferred from the topic.

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?

It adds substantial context beyond the annotations: nothing is actually ordered until payment, an unpaid order expires in about 15 minutes, and an identical repeat returns the same order - the last of these explains the idempotentHint rather than merely restating it. The total-mismatch refusal and terms requirement further describe runtime behaviour the agent cannot infer from readOnlyHint/destructiveHint alone.

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?

Three dense sentences, front-loaded with what the tool creates and returns. Every clause carries distinct information - checkout URL, prerequisites, refusal rule, expiry, idempotency - with 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?

For a mutation tool with no output schema, it still names the key return value and the order lifecycle (unpaid, expires, repeat returns same order). The one gap is not mentioning that payment/order state should subsequently be checked via get_order_status.

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 already 100%, so the baseline is 3. The description still adds real meaning by tying expectedTotalCents to get_quote's totalCents and acceptedTerms to the Terms document at a specific URL, and by framing the refund/refusal guarantee in customer terms.

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?

A specific verb and resource ("Creates an unpaid order") plus a stated return value (a Mollie checkoutUrl) make the tool's function unmistakable. It is clearly distinct from the quote/shop-info siblings, which only supply data rather than creating an order.

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 names the prerequisites (accepted terms, total from get_quote) and the refusal condition (a different current total is rejected), which effectively routes the agent through the quote-then-order flow. It stops short of explicitly pointing at get_order_status for the post-payment step, so it is clear but not fully exhaustive.

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 readOnly/idempotent/non-destructive/closed-world, so the bar is lower, and the description goes beyond them by specifying what comes back: all-in price incl. VAT and disposal fee, orderability, and availability speed. 'No side effects' merely restates readOnlyHint, but the return-value context is genuinely additive, especially since no output schema exists.

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?

Three short sentences, front-loaded with the resource and filters, then the return information. Only 'No side effects' is wasted, as it duplicates the readOnlyHint annotation.

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 no output schema, the description carries the return burden and does so by naming price composition, availability and orderability. For a 4-param, all-optional read-only search, this covers what an agent needs; pagination/result-limit behavior is the only notable omission.

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 50%, with brand undocumented and size/orderableOnly described in the schema. The description restates size, season and brand filtering and repeats the size example, but adds nothing about brand values or the orderableOnly default, so it does not compensate for the coverage gap.

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 the resource (tyres for sale) and the three filter dimensions, which is enough to distinguish it from siblings like get_order_status or place_order. It is a noun phrase rather than an explicit search verb, but the intent is unambiguous.

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 the browsing step before place_order or get_quote, but the description never states when to use it versus those siblings or any prerequisites. No exclusions or alternatives are named.

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