eenable — a shop with no checkout

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

Annotations already flag destructive=true and idempotent=true, and the description adds the consequences that matter: the slot is released and the payment is reversed, plus a failure fallback (tell the buyer to email the seller with their order number). That is real behavioral context beyond the annotation flags.

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 deprecation and preference for cancel_order are front-loaded, which is the right order of information. Slightly long, with the failure-fallback instructions competing for attention against the core deprecation message, 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?

For a two-parameter destructive mutation with no output schema, the description covers alias status, effect (refund, slot release), precondition, confirmation etiquette, and a degraded path on failure. An agent has everything needed to decide and to call it safely.

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%: the description echoes the email constraint ('the email the order was created with') which the schema already states, and adds no detail about order_id — no format, where to obtain it, or whether it is the booking or order identifier. Adequate but not compensating for the uncovered parameter.

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 ('Cancel a booking and refund it in full') and immediately resolves the ambiguity with the sibling cancel_order by declaring this is a deprecated alias that behaves identically. An agent can pick between the two without inspecting 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 routes the agent: 'Prefer cancel_order, which is accurate for certificates as well as appointments,' while noting the old name still works. It also gives a required precondition ('Requires the email the order was created with') and a human-in-the-loop rule ('Confirm with the buyer before calling').

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?

Goes well beyond the annotations (destructiveHint/idempotentHint) by disclosing concrete consequences: the slot is released, the payment is reversed, and the refund is full. It also provides a documented failure fallback (email the seller with the order number), which is exactly the kind of operational context annotations cannot convey.

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 purpose and effect in the first sentence, then preconditions, then the fallback. Every sentence carries information, though the fallback sentence is fairly long and slightly dilutes the core instruction.

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-parameter destructive mutation with no output schema, the definition covers preconditions, destructive consequences, and a recovery path. The only meaningful gap is that it never states what the tool returns or how to obtain `order_id`.

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%; the `email` description is already documented in the schema as 'Must match the order's email', so the description's repetition adds little. `order_id` remains undocumented in both the schema and the description, so the tool does not compensate for the coverage gap. Baseline 3.

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, resource, and side effect: 'Cancel a booking and refund it in full.' An agent immediately understands the operation. However, sibling `cancel_booking` exists and the description never explains how cancelling an order differs from cancelling a booking, leaving ambiguity between two similarly named tools.

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 clear preconditions (the email the order was created with) and an explicit call-first instruction ('Confirm with the buyer before calling'). It does not say when to prefer this over `cancel_booking` or `renounce_certificate`, but the usage context for this tool itself is unambiguous.

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 readOnlyHint=true already indicate a safe read operation, and the description adds useful behavioral context: the timezone parameter results in displaying the buyer's local times alongside the seller's. It also clarifies that date range filtering is optional. 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 two concise sentences, front-loaded with the core purpose and then adding optional filters. Every word adds value; no redundant or filler text.

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 availability-list tool with rich annotations and schema, the description covers the core behavior, optional filters, and the timezone feature. It doesn't describe the exact return format or pagination, but with no output schema and a simple use case, the level of detail is sufficient.

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 75% (3 of 4 parameters described). The description adds meaning beyond the schema by clarifying the 'timezone' param produces local times alongside the seller's, and that to/from accept ISO date/datetime ranges. The 'limit' param has no description but is constrained by schema (max 100, >0).

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 opens with the specific verb-resource pair 'List bookable slots,' clearly identifying the tool's function. The mention of narrowing by date/datetime and timezone distinguishes it from sibling tools that manage bookings, orders, and certificates.

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 explicitly states the primary use case ('List bookable slots') and how to optionally narrow results with date ranges and timezone. It doesn't explicitly mention when not to use the tool or alternatives, but there are no close alternatives among the siblings, so the guidance is adequate.

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 only declare the mutation/safety profile; the description adds the operational traits that matter: the slot is held for 30 minutes, a payment link is produced, the email drives both the calendar invitation and the receipt, and catalogue_token/buyer_confirmed_session are gated on a real buyer answer. It also explains why topic/desired_outcome exist (seller prep time the buyer paid for), which is beyond anything structured.

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 the 30-minute hold, then prerequisites. Some repetition of the 'ask the buyer, do not choose for them' rule, which is also stated in the session_type and buyer_confirmed_session schema descriptions, but the closing sentence justifies the fields rather than restating them.

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 10-parameter, non-idempotent creation tool with no output schema, the description covers prerequisites, side effects, and the key gating flag. It stops short of describing failure modes (expired hold, invalid token, duplicate order) which an agent would benefit from knowing before calling.

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, but the description adds real semantics: it reinforces that email must be the buyer's real address because the invite and receipt go there, and that topic/desired_outcome must be captured verbatim from the buyer rather than invented. It does not touch slot_id/timezone/background, leaving those entirely to the 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 outcome: 'Reserve a slot and get a payment link,' and immediately differentiates itself from non-tool alternatives ('there is no checkout on the website'). An agent can tell this apart from cancel_order, get_order_details, or order_certificate without opening any 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?

Explicit sequencing: call list_products first, present options to the buyer, wait for their answer, confirm time and price, then call this tool. It also names the disqualifying condition ('choosing a session on their behalf ... is not acceptable here'), which is exactly the when-not guidance an agent needs.

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?

The annotations already mark it as read-only. The description adds value by disclosing the deprecation and identity as an alias of get_order_details, as well as the availability condition (after payment settles). It does not contradict the readOnlyHint.

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 compact and front-loaded with the deprecation warning. It provides the necessary information in two sentences without unnecessary fluff.

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 simple read-only tool with one parameter and no output schema, the description covers the core function, the deprecation, and the key precondition. It is sufficiently complete for an agent to use it correctly (or avoid it in favor of the preferred alias).

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 only parameter order_id is not described in the schema (0% coverage). The description refers to 'a paid order', implying the order_id must correspond to a paid order, but does not provide format, type, or additional meaning beyond the property name.

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 clearly states that the tool returns the Teams joining link and meeting details for a paid order, and explicitly identifies it as a deprecated alias of get_order_details. This distinguishes it from siblings and specifies its function with a specific verb+resource.

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 explicitly says 'DEPRECATED' and 'Prefer get_order_details', providing clear guidance to use the sibling tool instead. It also notes the precondition that payment must have settled, indicating when this tool is applicable.

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?

The readOnlyHint annotation already indicates a safe read operation, and the description adds valuable context about the availability condition (post-payment) and the specific content returned (Teams link, meeting details). It does not over-explain or contradict 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 concise, using two short sentences. Key information is front-loaded, and every word contributes meaning without 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?

With a single parameter and no output schema, the description adequately explains what the tool returns and when it's valid. It doesn't cover error behavior for unpaid orders, but overall it's sufficient for a simple read-only tool.

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 schema has one parameter (order_id) with no description coverage. The description partially compensates by specifying the order must be paid, giving some semantic context, but it doesn't clarify the expected format or value range of order_id.

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 clearly states the tool retrieves the Teams joining link and meeting details for a paid order. It is specific about the resource (paid order) and the output, distinguishing it from siblings like get_order_status or get_booking.

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 implies when to use this tool: only once payment has settled. However, it doesn't explicitly mention when not to use it or name alternative tools, so it falls 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?

The description thoroughly discloses behavioral traits beyond the readOnlyHint annotation: it blocks for up to five minutes, returns immediately upon settlement, and prevents sending messages while waiting. This is rich, actionable transparency that critically informs agent 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?

The description is slightly long but each sentence carries essential information, including the blocking behavior, timeout, and message restriction. The critical warning is highlighted with 'IMPORTANT' and the purpose is front-loaded. It is well-organized despite being a single paragraph.

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?

While there is no output schema, the description adequately explains the return behavior (pending_payment vs. settled) and the timeout/retry logic. It covers the key operational details for a payment status check, though it does not specify the full return object structure, which remains a minor 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 input schema already provides 100% coverage for both parameters with detailed descriptions (order_id, wait_seconds with defaults and maximum). The description adds behavioral context but does not introduce new parameter semantics beyond what the schema offers, so the baseline 3 is 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 clearly states the tool's purpose: to check whether an order has been paid. This distinguishes it from sibling tools like get_order_details, which likely provides broader order information. The specific focus on payment status and the blocking behavior make the purpose unmistakable.

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 provides explicit usage guidance: call once rather than polling, re-call if pending_payment, and ensure the payment link is sent before blocking. It also warns against sending a message while waiting, giving clear when-to-use and how-to-use context.

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?

The annotations already declare readOnlyHint=true, and the description's informational content is consistent with that. The description adds context that the tool explains buying mechanics and is a prerequisite for first-time shop interactions, which goes beyond the annotation. However, it doesn't disclose return format or edge cases, but with annotations present this is acceptable.

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 a single, well-structured sentence that front-loads the key information (what the tool reveals) and ends with a clear usage directive. No wasted words.

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 parameterless read-only info tool, the description covers the essential information: purpose, content, and when to call. The sibling tools and annotations provide additional context, and no output schema is needed. The description is sufficient for an agent to select and invoke the tool 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?

The tool has zero parameters, and the schema description coverage is 100% trivially. The description correctly doesn't attempt to explain parameters. According to the rubric, a 0-param tool gets a baseline of 4, and there is no reason to deduct.

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 clearly states the tool provides shop-level information: what the shop sells, pricing, and purchasing process. This distinguishes it from sibling tools like list_products, which would focus on individual products, and order-related tools. The verb 'get' is implied by the name and the description gives specific content categories.

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 explicitly says 'Call this first if you have not dealt with this shop before,' providing clear when-to-use guidance. It does not mention alternatives or when-not-to-use, but the directive is strong and sufficient for most cases.

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 and openWorldHint=false, and the description does not contradict them. It adds useful behavioral context by explaining that the returned IDs link to create_order, that examples are provided for decision support, and that the list is effectively the complete set of types (with 'general' as a valid choice). For a read-only listing with no output schema, this is sufficient transparency.

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 four short sentences, each adding necessary value: the tool's purpose, the interaction rule, the output linkage to create_order, and the guidance for handling indecision. No redundant phrasing or repetition of schema details.

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?

Given the simple tool shape (no parameters, no output schema, readOnly annotation), the description fully covers what the agent needs: what the list contains, how to present it, how to use the ID, and how to handle buyer uncertainty. The reference to alternate tool create_order also provides integration context.

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 tool has zero parameters and the schema already provides complete coverage, so the baseline is 4. Although the description does not discuss parameters (there are none), it does clarify the meaning of the returned values, which supports the calling convention.

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 clearly identifies the tool's function: listing the session types the shop sells. It goes further to specify the output's role ('returns an id to pass to create_order'), distinguishing this from sibling tools that manage orders and bookings.

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 provides explicit guidance on when to use the tool: present options to the buyer and let them choose, with a clear prohibition on choosing for them unless asked. It also advises how to handle uncertainty using 'good_for' examples and notes that 'general' is acceptable, giving practical decision-making context.

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=false, idempotentHint=false, and destructiveHint=false. The description adds non-obvious behavior beyond that: issuance occurs the moment payment settles, delivery is by PDF email, and a verifiable hash is registered. It does not cover payment mechanics or failure cases, but the fulfillment model is materially clearer than annotations 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?

Five short sentences, front-loaded with purpose and immediately followed by the sibling distinction and the fulfillment model. Every sentence carries information relevant to selecting or invoking the tool; 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?

With no output schema, the description appropriately explains the fulfillment outcome (instant issuance, PDF email, hash registration) and the consent requirement. For a non-idempotent purchase tool, it could say more about payment flow or irreversibility, but the core calling context is present.

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 adds some meaning to buyer_confirmed_choice by stressing that the buyer must choose rather than the agent deciding, but it largely overlaps with the schema's own description of that parameter and adds little on email, name, certificate_id, or catalogue_token.

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 concrete verb and resource ("Buy a certificate") and immediately distinguishes it from the nearest sibling ("Use this instead of create_order, which is only for booking time"). The contrast between certificates as objects and appointments as slots further sharpens what this tool is for.

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 names the alternative (create_order) and the condition that selects it (certificate purchase vs. booking time). It also gives a usage rule for the buyer interaction ("show the buyer what is on offer and let them choose"), which tells the agent how to invoke it correctly.

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?

The description goes well beyond the destructiveHint annotation by explaining irreversibility ('strikes the hash from the register permanently and cannot be undone'), the security implication that anyone holding the PDF can execute it, and the need for buyer consent. This is rich behavioral context that annotations alone do not 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?

The description is front-loaded with the core action but becomes wordy with the Yves Klein allusion. While the analogy adds conceptual color, it is not strictly necessary and makes the description longer than needed. Every sentence does not tightly earn 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?

Even without an output schema, the description covers all necessary operational aspects: the irreversible destructive effect, the consent requirement, the bearer-instrument caution, and how to find the parameter. For a simple one-parameter tool with significant behavioral nuance, it is remarkably 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?

The schema already provides 100% coverage for order_id, explaining that it is printed on the certificate and that no email is required due to bearer-instrument status. The description repeats 'needs only the order number' but adds no new parameter-level meaning beyond the schema, so the baseline 3 is 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 clearly states the action: 'Destroy the proof of ownership for an AI Repellent, completing the transfer.' This is a specific verb and resource that distinguishes it from siblings like transfer_certificate (which would transfer rather than destroy). The title 'Renounce a certificate' and the description align perfectly.

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 clear context: it is used to complete a transfer, requires buyer agreement, and warns about bearer-instrument implications. However, it does not explicitly name alternatives or state when not to use this tool, so it falls 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?

Goes beyond the annotations by disclosing cost ("at no charge"), the auth requirement (must supply the order's email), and a hard upstream dependency on check_availability. It does not address the non-idempotent implication (what happens if the same reschedule is retried) or what the response contains, so it stops short of full disclosure.

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 deprecation and the preferred alternative are front-loaded, which is exactly the right ordering for a rename stub, followed by the operational sentence. Slightly wordy in the middle ("behaves identically" plus "keeps working" restate the same guarantee), but no sentence is truly wasted.

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 3-required-parameter mutation with no output schema, the description covers the essential call path: prerequisite lookup, auth requirement, and cost. The only real gap is the undocumented order_id and the absence of any statement about the tool's 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 67%; email and new_slot_id are already documented in the schema and the description adds only the operational framing (email must match the creating order, slot must come from check_availability). order_id remains undocumented in both schema and description, leaving one required parameter without semantics.

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+resource ("Move a booking to a different slot") and immediately identifies itself as a deprecated alias of reschedule_session with identical behavior. An agent can distinguish it from reschedule_session and update_booking without opening any 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 says to prefer reschedule_session for new connections, and mandates calling check_availability first to obtain a valid new_slot_id. Both the alternative and the ordering prerequisite are named rather than implied.

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=false, idempotentHint=false and destructiveHint=false, so the mutation profile is known. The description adds genuinely new context — no charge, email must match the order, slot must come from check_availability — but says nothing about what happens to the prior slot/booking or what is returned, so it doesn't reach rich disclosure.

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 sentences, no filler, and the cheap/free nature of the operation plus the required prerequisite are front-loaded where an agent will read them first.

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 3-required-param mutation with no output schema and no nested objects, the description covers auth, precondition, and cost. What's missing is what the call returns or confirms, and any disambiguation from the closely named sibling reschedule_booking.

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 67% and order_id has no schema description; the text clarifies that email must match the order the booking was created with, and reinforces that new_slot_id comes from check_availability. order_id is left completely unexplained in both places.

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 concrete verb+resource ("Move a booking to a different slot") and adds a salient constraint ("at no charge"). It does not differentiate itself from the sibling reschedule_booking, so an agent can't tell which reschedule to pick from the description alone.

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 an explicit prerequisite sequence ("Call check_availability first to get a valid new_slot_id") and an authentication condition (email must be the one used to create the order). It stops short of saying when to use this versus reschedule_booking or cancel_booking.

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 only tell us it is a non-idempotent, non-destructive write. The description adds real behavioral context: the exact cost rule, that a payment link is returned, and that the transfer only takes effect once payment completes. The main residual gap is that it does not say what happens if the recipient never pays or whether the existing bearer retains any rights in the interim.

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 purpose is front-loaded in the first sentence and the cost, identity, and payment-link facts each follow in order. The Klein's-receipts framing is slightly ornate, but it does real work by motivating the doubling rule rather than being pure decoration.

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 burden of explaining the return value and does so ('Returns a payment link; the transfer takes effect once it is paid'). Combined with the cost rule and the identity-preservation note, an agent has everything needed to call this correctly and to set expectations for the user.

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 order_id, name, and email are already fully documented. The description reinforces the endorsement framing ('sent there' for the email) but adds no format, constraint, or edge-case detail beyond the schema, so 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 resource ('Pass a certificate to someone else') and immediately clarifies the identity semantics: the same serial and hash are endorsed to a new bearer rather than a new certificate being minted. That distinction separates it from creation/ordering tools and from a renouncement conceptually, without the agent needing another 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?

It conveys when the operation is appropriate and a hard precondition (cost is exactly double the initial purchase value and the shop won't go lower), which is genuinely useful routing information. However, it never names the obvious alternative, renounce_certificate, or explains when an owner should renounce rather than transfer, so the choice between siblings stays implicit.

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 real disclosure beyond the annotations: deprecation status and identical-behavior guarantee for backward compatibility, plus "Only the fields you pass are changed" which pins down partial-update semantics that the idempotentHint alone does not convey. The mutation claim is consistent with readOnlyHint=false and destructiveHint=false, and the rename warning is exactly the kind of lifecycle context agents otherwise miss.

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 most decision-relevant fact — DEPRECATED — before any functional prose, which is the right ordering. Slightly verbose in places (the rename rationale is spread over two sentences, and the 'people work out the real question' aside is color rather than instruction), but nothing is wasted enough to impede scanning.

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 6-parameter mutation with no output schema, the description covers scope, partial-update semantics, and sibling routing, which is the bulk of what an agent needs. The only gap is the absence of any statement about what a successful call returns or whether the matching-email rule can fail the call, which matters given no output schema documents it.

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 83%, so the baseline is 3; the description earns a bump by unpacking the abstract field names ("what the buyer wants to discuss, what they want out of it, or the background they want read first") into topic, desired_outcome and background. It says nothing extra about order_id or the email-must-match constraint, which the schema already carries.

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 verb+resource ("Change the session type or the brief on an existing booking") and enumerates the concrete fields in plain language. It also explicitly states the deprecation rename to update_order_details and distinguishes itself from reschedule_booking, so an agent can tell the three apart without opening any 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?

Gives an explicit when (buyer refines their thinking after booking), an explicit when-not ("This does not move the meeting — use reschedule_booking for that"), and an explicit preference between siblings ("Prefer update_order_details"). Both alternatives are named with the condition that selects them.

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=false, idempotentHint=true, and destructiveHint=false. The description adds valuable partial-update semantics ('Only the fields you pass are changed') and clarifies there is no scheduling side effect, though it does not discuss auth or reversibility.

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 core change is front-loaded and the reschedule exclusion is prominent. The explanation of why buyers refine their thinking is slightly illustrative, but no sentence is wasteful.

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 purpose, usage, partial updates, and the main alternative for a mutation tool with annotation and schema support. It omits return/error behavior, but with no output schema and high schema coverage this is adequate.

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 83%, so the schema already documents email, topic, background, session_type, and desired_outcome. The description restates the human meaning of the 'brief' fields but adds little parameter-level syntax or constraint detail beyond the 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: changes session type or brief fields on an existing booking. It explicitly excludes reschedule_booking, but does not distinguish itself from sibling update_booking, so sibling differentiation is partial.

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 an explicit when-to-use case (buyer refines their thinking after booking) and an explicit when-not case with an alternative (does not move the meeting — use reschedule_booking). The routing guidance is clear and actionable.

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