eenable — a shop with no checkout

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds valuable behavioral context: it refunds in full, releases the slot, reverses payment, and requires the email used at order creation. It also explains what to do if the tool fails. This enriches the annotation-provided safety profile without contradiction.

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 deprecation status, which is critical. Each sentence provides necessary information: deprecation, alternative, behavior, prerequisite, confirmation requirement, and fallback. It is somewhat wordy but every part earns its place. A slight condensation could make it more concise, so it does not earn a 5.

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 two-parameter cancellation tool with annotations present but no output schema, the description covers all essential aspects: purpose, deprecation, refund behavior, prerequisite, confirmation protocol, and error fallback. It gives an agent enough context to invoke the tool appropriately and handle failures.

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 describes the email parameter with 'Must match the order's email', and the description rephrases this as 'Requires the email the order was created with', adding little new meaning. The order_id parameter has no schema description and the description only implies it via 'order number' in the fallback hint. Schema coverage is only 50%, and the description does not fully compensate for the missing order_id 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?

The description clearly states the tool's action: 'Cancel a booking and refund it in full.' It also distinguishes itself from the sibling tool cancel_order by explaining that cancel_order is the preferred, up-to-date name and is accurate for certificates as well as appointments. This makes the purpose 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?

The description explicitly says to prefer cancel_order instead of this deprecated alias, giving a clear alternative. It also instructs to 'Confirm with the buyer before calling' and explains the consequences (releasing slot, reversing payment), providing concrete usage guidance and when-not-to-use scenarios. The fallback instruction for failure is also present.

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?

Despite annotations indicating destructive and non-read-only behavior, the description adds substantial context: it releases the slot, reverses the payment, requires confirmation, and even provides a fallback path if the tool fails. This goes beyond mere annotation values.

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 three sentences, front-loaded with the core action, then prerequisites, consequences, and fallback. 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 destructive tool with no output schema, the description covers prerequisites, effects, confirmation requirements, and failure fallback. It doesn't specify return values, but no output schema exists, and the behavioral essentials are 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 covers 50% of parameters (email described as must match the order's email). The description adds minimal extra meaning—it reiterates that the email must be the one used at creation, but says nothing about order_id beyond implying it identifies the booking. With one parameter entirely undocumented in both schema and description, this leaves a 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 clearly states the tool cancels a booking and refunds it in full, using a specific verb and resource. However, it does not differentiate from the sibling tool `cancel_booking`, so it lacks explicit sibling differentiation.

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 clear context on when to use: require the email, confirm with buyer before calling, and notes the consequences. It doesn't explicitly mention alternatives or exclusions, but the conditions for use are 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 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 already indicate readOnlyHint=false, but the description adds critical behavioral context: the slot is held for 30 minutes, the email receives the calendar invitation and receipt, and the seller uses topic/desired_outcome to prepare, so a blank booking wastes paid time. This goes beyond annotations and gives the agent essential side-effect information.

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?

Although lengthy, every sentence earns its place. The description is front-loaded with the core purpose, then logically proceeds to prerequisites, workflow, and safety checks. It is sufficiently structured and readable, with no filler or redundant 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?

Given the tool's complexity (10 parameters, required workflow, no output schema), the description covers all necessary context: how to initiate the process, what information to gather, side effects, and what the return value likely contains (payment link). The agent has complete guidance to invoke this 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 coverage is 100%, but the description significantly enriches parameter understanding. For example, catalogue_token is explained as coming from list_products, buyer_confirmed_session has a clear semantic of 'only after buyer actually answers', and topic/desired_outcome are described as things to ask the buyer for, not invent. This adds substantial value 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?

The description opens with 'Reserve a slot and get a payment link', which is a specific verb+resource pair that clearly defines the tool's action. It further distinguishes itself by stating 'This is the only way to buy — there is no checkout on the website', which sets it apart from sibling tools like check_availability 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 provides explicit step-by-step guidance: must call list_products first, present options to the buyer, wait for them to choose, and only set buyer_confirmed_session after actual confirmation. It also states when not to use the tool implicitly by noting there is no alternative checkout, and explains prerequisites like confirming time and price.

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 only declare readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds substantial behavioral context: the certificate is issued at payment settlement, emailed as a PDF, and registered against an hash. It also clarifies that no slot, calendar entry, or meeting is created, which is crucial for an agent to understand the tool's side effects.

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 five sentences, each serving a distinct purpose: the core action, the artifact's nature, the issuance process, the sibling alternative, and the buyer-consent rule. No sentence is filler; it is front-loaded with the most important information and remains compact given the tool's complexity.

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?

Despite having no output schema, the description provides essential outcome details (PDF emitted, hash registry) and operational guidance (payment, buyer choice). It fully differentiates the tool from create_order and covers the required parameters' intent, making the tool actionable for an agent. The lack of an exact response structure is a minor gap, but the description is otherwise 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 input schema describes all five parameters with 100% coverage, including detailed explanations for catalogue_token and buyer_confirmed_choice. The description does not introduce new parameter formats or constraints beyond the schema; the buyer-consent guidance in the description largely echoes the schema's instruction for buyer_confirmed_choice. With high schema coverage, a baseline of 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 opens with a specific verb and resource ('Buy a certificate') and explicitly contrasts itself with the sibling tool create_order ('Use this instead of create_order, which is only for booking time'). It also clarifies that certificates are objects, not appointments, eliminating any ambiguity about scope.

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 when to use the tool and names the alternative to avoid: 'Use this instead of create_order, which is only for booking time.' It also adds a buyer-consent guideline ('As with sessions, show the buyer what is on offer and let them choose'), giving clear operational rules beyond simple tool selection.

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?

Annotations already communicate that this is not read-only, not idempotent, and not destructive. The description adds the context that the move is 'at no charge' and requires the original email. However, it does not disclose potential side effects on the old slot or mention any confirmation/rollback behavior. This is adequate but not rich.

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 and front-loaded with the deprecation notice, then states the core action, the key requirement, and the prerequisite step. Every sentence serves a clear purpose and no unnecessary wording is present.

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 3-parameter mutation tool, the description covers the action, prerequisite, required credential, and deprecation context. It does not mention return values or confirmation behavior, but given the lack of an output schema and the tool's simplicity, this is a minor gap. The deprecation context is well handled.

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 describes email and new_slot_id well, and the description reinforces the requirement to use a slot_id from check_availability. However, order_id remains undocumented beyond its name, and the description adds no further parameter-level meaning beyond what the schema provides. With 67% schema coverage, the description offers marginal additional value.

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 (move a booking to a different slot) and resource (a booking), and explicitly distinguishes itself from the preferred sibling reschedule_session by framing itself as a deprecated alias. This is a specific verb+resource definition with strong sibling differentiation.

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?

Provides explicit usage guidance: prefer reschedule_session instead, call check_availability first to obtain a valid new_slot_id, and require the email matching the order. This clarifies exactly when and how to use the tool versus alternatives.

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 adds value beyond annotations by disclosing that the reschedule is free and requires the original email. These details are useful, though it does not mention side effects on the old slot or error handling.

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 three concise sentences, front-loaded with the purpose, followed by a requirement and a prerequisite step. Every sentence carries distinct information with 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?

The description covers the core action and prerequisites, but it does not distinguish from the similar sibling 'reschedule_booking' and lacks information about the operation's outcome. With no output schema and minimal annotations, additional context would be beneficial.

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 describes email and new_slot_id (67% coverage), and the description repeats this information without adding new meaning. The order_id parameter remains undescribed, and the description does not compensate for that 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 clearly states the tool moves a booking to a different slot at no charge, using a specific verb and resource. However, it does not differentiate from the sibling tool 'reschedule_booking', which could cause ambiguity.

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 by specifying the email requirement and recommending calling check_availability first. It does not explicitly state when not to use this tool or mention alternatives, but it provides enough guidance for the intended use case.

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 provide false flags for readOnly, idempotent, and destructive, which are minimal. The description adds critical behavioral details: the transfer costs exactly twice the initial purchase value, the serial number and hash remain unchanged, and the transfer takes effect only after payment via a returned payment link. This goes far beyond the annotations and fully discloses the operation's side effects.

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 primary action and then provides essential operational details: the pricing rule, the unchanged identifiers, and the payment/effect timing. Every sentence serves a purpose, including the historical clause which explains the cost rationale. It is compact and well-structured.

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?

This is a 3-parameter tool with no output schema, yet the description covers the action, the cost, the non-reissuance of the certificate, and the post-payment activation. There are no obvious gaps that would prevent an agent from selecting and invoking 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 input schema already covers all three parameters with descriptions, so the baseline is 3. The description adds extra meaning by clarifying that the cost is tied to the certificate's initial purchase value (relevant to order_id) and reinforcing that the new_bearer_email is where the endorsed certificate is sent. This supplemental context enhances parameter understanding 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?

The description opens with 'Pass a certificate to someone else,' using a specific verb and resource that clearly identifies the action. It further distinguishes from siblings by stating it is the same object endorsed to a new bearer, not a new certificate, which differentiates it from create/order/cancel operations.

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?

Clear context is provided: the tool transfers a certificate to a new bearer, with an explanation of the double-cost rule and the payment-link flow. It does not explicitly name alternative tools or state when not to use it, but the use case 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?

With annotations already indicating idempotency and non-destructiveness, the description adds valuable behavioral context: 'Only the fields you pass are changed,' clarifying partial update semantics. It also honestly discloses the deprecation status and that the old name remains functional, which is important for agent reasoning.

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 well-structured and front-loaded with the deprecation warning, which is critical for agent decision-making. The second paragraph is efficient, though the illustrative clause about buyers refining thinking is slightly verbose. Overall, it is focused and appropriately sized for the tool's complexity.

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?

The description covers purpose, usage, exclusions, and field semantics, with strong support from annotations and schema. Given the moderate complexity and absence of an output schema, the lack of return-value details is a minor gap. It is nearly complete for an update tool with good structured metadata.

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 descriptions cover 83% of parameters, so the baseline is high. The description adds a semantic grouping of fields ('what they want to discuss, what they want out of it, or the background they want read first') but does not deeply enrich the syntax or provide examples beyond what the schema already offers. This is adequate but not exceptional.

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 updates the session type or brief on an existing booking, with specific examples of the fields affected. It also distinguishes itself from reschedule_booking and points to the preferred rename update_order_details, making its unique role 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?

The description provides explicit usage context: use when the buyer refines their thinking after booking. It also gives an explicit exclusion: 'This does not move the meeting — use reschedule_booking for that' and cites the alternative update_order_details as the preferred tool.

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=false, idempotent=true, destructive=false. The description adds valuable context beyond these: partial update semantics (only passed fields change) and the explicit non-mutating boundary regarding meeting time. This enriches the behavioral model without contradicting 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 three sentences, front-loaded with the primary purpose, followed by a usage context and a clear distinction from a sibling tool. Every sentence earns its place with no redundancy or 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 mutation tool with no output schema, the description provides what an agent needs: what it does, when to use it, partial update behavior, and which sibling handles related cases. The annotations cover safety/idempotency, making this sufficient for correct selection and invocation.

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 high at 83%, so the baseline is 3. The description adds meaning by grouping topic, desired_outcome, and background under the concept of 'the brief' and by clarifying that only provided fields are changed, which is not fully explicit in the schema. The order_id parameter lacks description in the schema and the description does not compensate, but it is a standard required identifier.

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 uses a specific verb ('Change') and identifies the precise resource ('session type or the brief on an existing booking'). It further clarifies scope by naming the fields involved (what to discuss, desired outcome, background) and explicitly differentiates from reschedule_booking by stating it does not move the meeting.

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 explicitly states when to use the tool: 'when the buyer refines their thinking after booking.' It also provides a clear exclusion and alternative: 'This does not move the meeting — use reschedule_booking for that.' Additionally, it explains the partial update behavior ('Only the fields you pass are changed'), guiding proper invocation.

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