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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains that this is a 'soft-delete' operation, retaining the product record for history, which clarifies the mutation's nature and permanence. However, it lacks details on permissions, side effects, or response format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by a clarifying detail. Both sentences earn their place by adding value, with no wasted words, making it highly efficient 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?

Given the tool's complexity (a mutation with no annotations), the description adequately covers the soft-delete behavior, but lacks details on permissions or error cases. The presence of an output schema reduces the need to explain return values, making it mostly complete for basic use.

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 0% description coverage for its single parameter 'product_id', but the description compensates by implicitly defining it as the product to archive. It adds meaning beyond the bare schema, though it could specify format or constraints. With one parameter, the baseline is high.

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 specific action ('Archive a product') and resource ('product'), distinguishing it from siblings like 'delete_customer' (hard delete) or 'update_product' (modify). It precisely communicates the tool's function without being tautological.

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 usage when a product should be removed from sale but retained for history, but it does not explicitly state when to use this tool versus alternatives like 'delete_customer' (hard delete) or 'update_product' to modify status. No exclusions or prerequisites are mentioned.

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?

No annotations are provided, so the description carries the full burden. It mentions that the tool creates a coupon but lacks critical behavioral details: it doesn't specify required permissions, rate limits, whether the operation is idempotent, what happens on failure, or the expected output format. The description only covers basic parameter usage without broader context.

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 highly concise and well-structured: a clear purpose statement followed by two focused sentences explaining key parameter usage. Every sentence adds value without redundancy, and the information is front-loaded for quick understanding.

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 complexity (a write operation with 5 parameters), no annotations, and an output schema (which reduces the need to describe return values), the description is moderately complete. It covers the core action and some parameter logic but lacks behavioral context (e.g., permissions, side effects) and full parameter documentation, making it adequate but with clear gaps.

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 0%, so the description must compensate. It explains the semantics of 'is_percentage' and 'currency' parameters, clarifying their roles in percentage vs. fixed discounts. However, it doesn't cover 'name', 'discount_value', or 'is_active', leaving three of five parameters undocumented. This partial coverage meets the baseline for low schema coverage.

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: 'Create a new discount coupon on Stream.' It specifies the verb ('Create') and resource ('discount coupon'), making the action unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'deactivate_coupon' or 'get_coupon' beyond the 'create' action.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication needs), compare it to sibling tools like 'list_coupons' or 'deactivate_coupon', or specify scenarios where coupon creation is appropriate versus other operations.

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 no annotations provided, the description carries full burden but only states it 'creates' without disclosing behavioral traits like permissions needed, whether duplicates are allowed, error handling, or what the output contains. It mentions required vs optional parameters but lacks critical operational context for a mutation tool.

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 efficiently structured in two sentences: the first states the core purpose, and the second enumerates parameters with clear formatting. Every word contributes necessary information without redundancy, making it easy to parse and front-loaded with the key action.

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 (9 parameters, mutation operation) and no annotations, the description adequately covers parameters but lacks behavioral details and output explanation. The presence of an output schema mitigates the need to describe return values, but gaps in usage guidelines and transparency keep it at a baseline level.

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 description adds significant value beyond the input schema, which has 0% description coverage. It clarifies that 'name' is required, lists all optional parameters with examples (e.g., 'EN/AR' for preferred_language, 'WHATSAPP, EMAIL, SMS' for communication_methods), providing essential semantic context not in 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 clearly states the verb 'Create' and resource 'customer in Stream', making the purpose unambiguous. However, it doesn't explicitly differentiate this tool from its sibling 'update_customer', which handles modifications rather than initial creation, so it doesn't reach the highest score.

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 no guidance on when to use this tool versus alternatives like 'update_customer' or 'get_customer', nor does it mention prerequisites or context for creation. It only lists parameters without usage context, leaving the agent to infer when this operation is appropriate.

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 no annotations provided, the description carries full burden for behavioral disclosure. While it mentions ZATCA compliance and notification behavior, it doesn't address critical aspects like required permissions, whether this is a write operation (implied but not stated), potential side effects, rate limits, or what happens with the created invoice. The description provides some context but leaves significant behavioral gaps.

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 efficiently structured with bullet points for parameter details, uses clear formatting, and every sentence adds value. It's appropriately sized for the tool's complexity and front-loads the core purpose before diving into parameter specifics.

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 (13 parameters, no annotations, but with output schema), the description covers the core creation purpose and some parameter semantics adequately. However, it lacks behavioral context for a write operation and doesn't address many parameters. The existence of an output schema reduces the need to describe return values, but the description should provide more complete guidance for this multi-parameter creation 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?

With 0% schema description coverage for 13 parameters, the description provides valuable semantic information for 3 parameters (items structure, scheduled_on format, notify_consumer purpose). It explains the items array structure in detail and clarifies ISO-8601 format for scheduled_on. However, it doesn't address the other 10 parameters like customer_id, description, currency, or payment acceptance flags, leaving significant gaps.

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 specific action ('Create a ZATCA-compliant invoice in Stream') with the resource type and compliance standard. It distinguishes from sibling tools like 'send_invoice' and 'void_invoice' by focusing on creation rather than sending or voiding 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?

The description provides no guidance on when to use this tool versus alternatives like 'create_payment_link' or 'send_invoice'. It mentions the 'notify_consumer' parameter but doesn't explain when notification is appropriate versus using the separate 'send_invoice' tool for existing invoices.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It mentions a constraint about mixing product types, which is useful, but fails to describe critical behaviors such as authentication needs, rate limits, what happens upon creation (e.g., link generation, storage), or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap.

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 appropriately sized and front-loaded, starting with the core purpose. The bullet points for 'items' are well-structured, and the constraint about mixing products is clearly emphasized. However, the lack of complete parameter coverage or additional context slightly reduces efficiency.

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 (7 parameters, mutation operation) and no annotations, the description is moderately complete. It explains the 'items' parameter well and includes a key constraint, but omits details on other parameters, behavioral traits, and usage context. The presence of an output schema mitigates some need to explain return values, but overall gaps remain.

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 description adds meaningful semantics for the 'items' parameter by detailing its structure (list of objects with product_id, quantity, coupons) and constraints (quantity ≥ 1, default 1). With 0% schema description coverage and 7 parameters, this partially compensates for the schema's lack of documentation, though it doesn't cover other parameters like 'name' or 'currency'.

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: 'Create a new payment / checkout link on Stream.' It specifies the verb ('Create') and resource ('payment / checkout link'), and the platform ('Stream'). However, it doesn't explicitly differentiate from sibling tools like 'create_invoice' or 'create_product', which would require a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides implied usage guidance by stating 'You **cannot** mix one-time and recurring products in the same link,' which hints at when not to use it. However, it lacks explicit guidance on when to choose this tool over alternatives like 'create_invoice' or 'create_product', and doesn't mention prerequisites or context for usage.

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 no annotations provided, the description carries full burden for behavioral disclosure. It mentions that 'type' can be ONE_OFF, RECURRING, or METERED, and that recurring products need 'recurring_interval', but doesn't address permissions, side effects, error conditions, or what happens after creation. For a mutation tool with zero annotation coverage, this is insufficient.

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 efficiently structured with a clear main sentence followed by bullet-point style parameter guidance. Both sentences earn their place by providing essential information. It could be slightly more front-loaded with a broader usage context, but overall it's appropriately sized.

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 that this is a mutation tool with 9 parameters, 0% schema description coverage, and no annotations, the description should do more to explain behavior and parameter usage. The presence of an output schema reduces the need to describe return values, but the description still lacks sufficient context for safe and effective use of this creation 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 description adds meaningful context for two parameters ('type' and 'recurring_interval') beyond what the schema provides, explaining the enum values and their implications. However, with 9 total parameters and 0% schema description coverage, it leaves 7 parameters completely undocumented. The description compensates somewhat but not enough for the large coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create a new product or service') and the target system ('in Stream'), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from its sibling 'update_product', which handles modifications rather than creation.

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 no guidance on when to use this tool versus alternatives like 'update_product' or 'list_products'. It mentions that recurring products require specifying 'recurring_interval', but this is parameter guidance rather than usage context. No exclusions, prerequisites, or alternative tools are mentioned.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deactivates a coupon, implying a mutation, but lacks details on permissions required, whether the action is reversible, rate limits, or error conditions. This is a significant gap for a mutation tool with zero annotation coverage.

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, efficient sentence that front-loads the key action and outcome without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it appropriately sized 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?

Given the tool's complexity (a mutation with one parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete behavioral details, it leaves gaps in understanding the full context, such as side effects or error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not mention parameters, but with only one parameter (coupon_id) and 0% schema description coverage, it implicitly clarifies that the tool operates on a specific coupon. Since there are zero parameters described in the schema, the baseline is 4, as the description's focus on coupon deactivation adds sufficient context for the single input.

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 ('deactivate') and resource ('coupon') with the outcome ('so it can no longer be redeemed'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'archive_product' or 'void_invoice', which might involve similar deactivation concepts in different contexts.

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 no guidance on when to use this tool versus alternatives, such as whether to use 'deactivate_coupon' over 'delete_customer' for coupon-related actions or how it compares to 'get_coupon' for checking status. There is no mention of prerequisites, exclusions, or contextual triggers for usage.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deactivates/archives a payment link, implying a mutation operation, but lacks details on permissions required, whether the action is reversible, rate limits, or what 'archive' entails (e.g., hidden vs. deleted). This is insufficient for a mutation tool without 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 a single, efficient sentence that front-loads the core action and outcome. There is no wasted verbiage, and it directly communicates the tool's function without unnecessary elaboration.

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 (a mutation with 2 parameters), lack of annotations, and presence of an output schema (which may cover return values), the description is minimally complete. It states what the tool does but misses key contextual details like parameter meanings, behavioral traits, and usage guidelines, making it adequate but with clear gaps.

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 0%, so the schema provides no parameter details. The description doesn't mention any parameters, leaving both 'payment_link_id' and 'deactivate_message' unexplained. However, with only 2 parameters and a baseline of 3 when schema coverage is low but not compensated, the score reflects minimal adequacy without added 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 ('deactivate (archive)') and resource ('a payment link'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'archive_product' or 'deactivate_coupon', which would require mentioning payment-link-specific context to achieve a perfect score.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the link must exist), exclusions (e.g., cannot deactivate already deactivated links), or comparisons with siblings like 'delete_customer' or 'void_invoice', leaving the agent without contextual usage cues.

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 no annotations provided, the description carries full burden and effectively discloses key behavioral traits: it specifies 'soft-delete' and clarifies that the record is 'archived but not permanently removed'. This informs the agent about the non-destructive nature, though it lacks details on permissions, reversibility, or 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 core action in the first sentence and adds clarifying detail in the second. Both sentences earn their place by defining the operation and its archival effect, with zero 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?

Given the tool's complexity (a mutation with no annotations) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the soft-delete behavior adequately, though it could benefit from mentioning permissions or error conditions.

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 0% with 1 parameter, so the description must compensate. It adds meaning by explaining that 'customer_id' is used to identify the customer for soft-deletion, though it does not specify format or constraints. This provides essential context beyond the bare 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 clearly states the specific action ('soft-delete') and target resource ('a customer by ID'), distinguishing it from siblings like 'update_customer' or 'get_customer'. It precisely defines the operation as archival rather than permanent removal.

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 usage for archiving customers but does not explicitly state when to use this tool versus alternatives like 'update_customer' for deactivation or other deletion methods. No guidance on prerequisites or exclusions is provided.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves a coupon but doesn't mention whether this is a read-only operation, what permissions are required, error handling (e.g., for invalid IDs), or response format. For a retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.

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, clear sentence with zero wasted words. It front-loads the essential information ('Get a single coupon') and efficiently specifies the method ('by ID'). Every part of the sentence contributes directly to understanding the tool's function.

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 low complexity (single parameter, retrieval operation) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema description coverage, it lacks context on permissions, errors, or behavioral nuances. It meets basic needs but leaves room for improvement in transparency.

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 description mentions 'by ID', which aligns with the 'coupon_id' parameter in the schema. However, schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds minimal semantic context (it's an ID) but doesn't explain format, constraints, or examples. With 1 parameter and low schema coverage, this is a baseline score.

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 ('Get') and resource ('a single coupon by ID'), making the purpose unambiguous. It distinguishes this tool from sibling tools like 'list_coupons' by specifying retrieval of a single item rather than a collection. However, it doesn't explicitly differentiate from other 'get_' tools like 'get_customer' or 'get_product' beyond the resource type.

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 no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'get_coupon' over 'list_coupons' (e.g., when you have a specific coupon ID), nor does it reference other sibling tools like 'deactivate_coupon' for related operations. Usage is implied by the name but not explicitly stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation but doesn't specify error handling, permissions, rate limits, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 a single, clear sentence with no wasted words. It is front-loaded with the core purpose, making it efficient and easy to understand.

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 simplicity (single parameter, read-only operation) and the presence of an output schema, the description is reasonably complete. It covers the basic purpose, though it could benefit from more behavioral context, especially since no annotations are provided.

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 0%, but the description adds meaning by specifying that the parameter is for retrieving by ID. However, it doesn't detail the ID format or constraints. With one parameter, the baseline is 4, but the lack of additional semantic info reduces the score slightly.

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 verb ('Get') and resource ('a single customer record'), specifying retrieval by ID. It distinguishes from sibling tools like 'list_customers' by focusing on a single record, though it doesn't explicitly name alternatives.

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?

No guidance is provided on when to use this tool versus alternatives such as 'list_customers' or 'create_customer', nor does it mention prerequisites like authentication or ID format. The description only states what it does, not when to use it.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but does not describe any behavioral traits such as permissions required, rate limits, error handling, or what happens if the ID is invalid. This leaves significant gaps in understanding how the tool behaves beyond its basic function.

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, efficient sentence that is front-loaded with the core action. There is no wasted wording, and it directly communicates the essential information without unnecessary elaboration, making it highly concise 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?

Given the tool's low complexity (one parameter) and the presence of an output schema, the description is reasonably complete for its purpose. It covers the basic action and parameter intent, and the output schema likely handles return values. However, without annotations and with minimal behavioral details, it could be more comprehensive for a retrieval tool in a financial 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 description adds minimal meaning beyond the input schema, which has 0% description coverage. It mentions 'by ID' to clarify the purpose of the 'invoice_id' parameter, but does not provide details on format, constraints, or examples. With only one parameter and low schema coverage, this offers some compensation but remains basic.

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 verb ('Get') and resource ('a single invoice by ID'), making the purpose specific and understandable. It distinguishes from sibling tools like 'list_invoices' by specifying retrieval of a single item. However, it doesn't explicitly differentiate from other 'get_' tools like 'get_customer' or 'get_product', which follow the same pattern.

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 usage when needing a specific invoice by its ID, but provides no explicit guidance on when to use this versus alternatives like 'list_invoices' or other retrieval tools. It lacks context about prerequisites, error conditions, or comparisons with siblings, leaving usage somewhat inferred rather than clearly defined.

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?

No annotations are provided, so the description carries full burden. It indicates a read operation ('Get details') and specifies return fields ('amount, status, payment method, customer info, and more'), which adds useful context beyond the input schema. However, it lacks details on permissions, error handling, rate limits, or whether it's idempotent, which are important for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence and adds return details in the second. Both sentences earn their place by providing essential information without redundancy. It's appropriately sized for a simple retrieval tool, with no wasted words or unnecessary elaboration.

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 low complexity (1 parameter), no annotations, and the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose, parameter intent, and return fields. However, it could improve by addressing behavioral aspects like error cases or idempotency, especially since annotations are absent.

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 0%, so the description must compensate. It clarifies that 'payment_id' is required to retrieve a single payment, adding meaning beyond the schema's basic type and requirement. However, it doesn't specify format constraints (e.g., string length or pattern) or provide examples, leaving some semantic gaps. With 0 parameters documented in the schema, the description does a good but not complete job.

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: 'Get details of a single payment by ID' specifies the verb ('Get'), resource ('payment'), and scope ('single payment by ID'). It distinguishes from sibling 'list_payments' by focusing on individual retrieval rather than listing multiple payments. However, it doesn't explicitly differentiate from other get_* tools like 'get_invoice' or 'get_customer' beyond the resource type.

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 usage context through 'by ID,' suggesting it's for retrieving specific known payments. It doesn't provide explicit guidance on when to use this versus alternatives like 'list_payments' for browsing or other get_* tools for different resources. No exclusions or prerequisites are mentioned, leaving usage context somewhat inferred rather than clearly defined.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data, implying a read-only operation, but does not address permissions, error handling, or rate limits. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise 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?

Given the tool's low complexity (one parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks details on behavioral aspects like authentication or error cases, which are important for a retrieval tool with no annotations.

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 description coverage is 0%, but the description adds meaning by specifying that the parameter 'payment_link_id' is used to retrieve a single payment link. However, it does not detail the ID format or constraints, so it partially compensates for the schema gap without fully documenting the 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?

The description clearly states the action ('Retrieve') and resource ('a single payment link by its ID'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'list_payment_links' or 'get_payment', which could enhance clarity further.

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 no guidance on when to use this tool versus alternatives such as 'list_payment_links' for multiple links or 'get_payment' for related resources. It lacks context on prerequisites or exclusions, leaving usage decisions to inference.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a product by ID but doesn't cover aspects like authentication requirements, error handling, rate limits, or response format. This is a significant gap for a tool with no annotation coverage.

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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse.

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 low complexity (1 parameter) and the presence of an output schema, the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it lacks details on usage context and behavioral traits, making it insufficient for full understanding.

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 description mentions 'by ID', which adds meaning to the 'product_id' parameter beyond the schema's basic type definition. However, with 0% schema description coverage, it doesn't fully compensate by explaining format constraints or examples. The baseline is 3 since it adds some value but not enough to overcome the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('a single product'), making it easy to understand what it does. However, it doesn't distinguish itself from sibling tools like 'get_coupon' or 'get_customer', which follow the same pattern, so it lacks 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_product' over 'list_products' for multiple products or other sibling tools, leaving the agent without context for 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?

No annotations are provided, so the description carries the full burden. It discloses that slugs are 'auto-discovered from the sitemap' and hints at the tool's read-only nature by using 'Fetch', but it lacks details on error handling, rate limits, authentication needs, or output format. The description adds some context but is incomplete for behavioral 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by concise guidance on usage and examples. Every sentence earns its place by providing essential information without waste, making it easy to scan and understand.

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 low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is largely complete. It covers purpose, usage, and parameter semantics well. However, without annotations, it could benefit from more behavioral details (e.g., error cases), but the output schema reduces this 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 has 1 parameter with 0% description coverage, so the description must compensate. It explains that 'slug' refers to a Stream documentation page identifier, provides examples (e.g., 'getting-started'), and mentions how to obtain slugs (via list_stream_docs or prior knowledge). This adds significant meaning beyond the bare 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 clearly states the specific action ('Fetch the content') and resource ('Stream documentation page by slug'), distinguishing it from sibling tools like list_stream_docs (which lists available docs) and other unrelated tools (e.g., payment or customer management tools). It directly addresses what the tool does without redundancy.

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 provides when to use this tool vs. alternatives: use list_stream_docs first to discover slugs, or use this tool directly if you already know the slug. It also gives examples of slugs (e.g., 'getting-started'), clarifying the context and excluding other use cases like fetching non-documentation resources.

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 no annotations provided, the description carries full burden for behavioral disclosure. It mentions filtering capabilities but doesn't describe pagination behavior (implied by 'page' and 'limit' parameters), rate limits, authentication requirements, error conditions, or what happens when filters return no results. The description is minimal and leaves critical behavioral aspects undocumented.

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 extremely concise and well-structured. The first sentence states the core purpose, followed by bullet points explaining two key parameters. Every sentence earns its place with no redundant information. The bullet format makes the parameter explanations scannable and clear.

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 that this is a read-only listing tool with an output schema (which handles return values) and no annotations, the description is minimally adequate. It covers the basic purpose and explains two of four parameters, but leaves pagination behavior and other operational aspects undocumented. For a simple listing tool, this might be sufficient, but there are clear gaps in behavioral 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 description adds significant value beyond the schema, which has 0% description coverage. It explains the semantics of two key parameters ('active' and 'is_percentage') that would otherwise be completely undocumented. However, it doesn't explain the 'page' and 'limit' parameters, leaving pagination behavior implicit rather than explicit. For a tool with 4 parameters and no schema descriptions, this partial coverage is valuable but incomplete.

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 as 'List all coupons with optional filters' - a specific verb (list) and resource (coupons). It distinguishes from sibling tools like 'get_coupon' (singular retrieval) and 'create_coupon' (creation). However, it doesn't explicitly differentiate from other list_* tools like 'list_customers' or 'list_products' beyond the resource type.

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 no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'list_coupons' versus 'get_coupon' (singular retrieval), nor does it provide context about prerequisites, permissions, or typical use cases. The only implicit guidance is that it's for listing multiple coupons rather than retrieving a single one.

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?

No annotations are provided, so the description carries the full burden. It mentions pagination and that it returns a paginated list, which adds some behavioral context beyond basic listing. However, it lacks details on permissions, rate limits, error handling, or what 'search' entails (e.g., filtering capabilities), making it insufficient for a tool with no annotation support.

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 extremely concise with two short sentences that are front-loaded and waste no words. Every sentence directly contributes to understanding the tool's function, making it efficient and well-structured for quick comprehension.

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 has an output schema (which likely defines the return structure), the description doesn't need to detail return values. However, with no annotations, 0% schema coverage, and two parameters, it should provide more context on usage, parameters, and behavior. The mention of pagination and listing is minimal but not fully adequate for this complexity.

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 0%, so the description must compensate. It mentions pagination but doesn't explain the 'page' and 'limit' parameters or their semantics (e.g., what values are valid, how pagination works). This leaves parameters largely undocumented, failing to add meaningful context beyond the bare 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 clearly states the verb ('List / search') and resource ('customers'), making the purpose specific and understandable. It distinguishes from siblings like 'get_customer' by indicating it returns multiple customers rather than a single one. However, it doesn't explicitly differentiate from other list tools (e.g., 'list_products'), though the resource specificity helps.

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 no guidance on when to use this tool versus alternatives like 'get_customer' for single customer retrieval or 'search_customers' if such a tool existed. It mentions pagination but doesn't specify when pagination is needed or how to handle large datasets, leaving usage context implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities but lacks critical behavioral details: it doesn't specify if this is a read-only operation (implied by 'List' but not explicit), doesn't mention pagination behavior (though 'page' and 'limit' parameters exist in schema), and doesn't describe authentication requirements or rate limits. The description adds some value by listing filter options but misses key operational context.

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 perfectly concise and well-structured. The first sentence states the core purpose, and the second sentence efficiently enumerates the filter options with helpful examples. Every word earns its place, with no redundant information or unnecessary elaboration.

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 moderate complexity (7 parameters, no annotations, but has output schema), the description is partially complete. It covers the filtering parameters well but ignores pagination parameters. The existence of an output schema means the description doesn't need to explain return values, but it should address more behavioral aspects like pagination mechanics and operational constraints for a listing 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?

With 0% schema description coverage, the description must compensate for the schema's lack of parameter documentation. It successfully adds meaning by explaining what each filter parameter does: 'organization_consumer_id', 'statuses' with enumerated values, 'payment_statuses' with examples, and 'date range' for 'from_date'/'to_date'. However, it doesn't mention the 'page' and 'limit' parameters at all, leaving two parameters completely undocumented.

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: 'List invoices with optional filters.' This specifies the verb ('List') and resource ('invoices'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_invoice' (singular retrieval) or 'list_payments' (different resource), which prevents a perfect score.

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_invoice' for retrieving a single invoice or 'list_payments' for listing payments instead of invoices. There's no context about prerequisites, typical use cases, or exclusions.

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 no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'optional filters' but doesn't disclose pagination behavior (implied by page/limit parameters), rate limits, authentication requirements, or what 'List all' means in practice (e.g., completeness guarantees). The status values are listed, but no context about what they represent or system behavior is given.

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 appropriately brief with two sentences: a clear purpose statement followed by specific parameter details. It's front-loaded with the core functionality. However, the second sentence could be more integrated (e.g., 'Filter by status using statuses parameter, which accepts...') for better flow.

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 5 parameters with 0% schema coverage and no annotations, the description is incomplete—it only documents one parameter's values. The existence of an output schema reduces the need to describe return values, but behavioral aspects like pagination, filtering logic, and error conditions remain unaddressed. For a list tool with multiple filters, more context would be helpful.

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 0%, so the description must compensate but only partially does. It clarifies that 'statuses' can include specific values (INACTIVE, ACTIVE, COMPLETED), adding meaning beyond the schema's generic string array. However, it doesn't explain the other 4 parameters (page, limit, from_date, to_date), leaving their purpose and format undocumented. The baseline would be lower without the status clarification.

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 verb ('List') and resource ('payment links'), making the purpose immediately understandable. It distinguishes itself from siblings like 'get_payment_link' (singular retrieval) by indicating it returns multiple items with filtering. However, it doesn't explicitly contrast with other list tools like 'list_coupons' or 'list_invoices' beyond the resource type.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare with sibling tools like 'get_payment_link' for single retrieval or 'list_payments' for different resource types. The agent must infer usage from the tool name alone.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities but doesn't describe pagination behavior (implied by page/limit parameters), rate limits, authentication requirements, whether it's read-only (implied by 'list' but not explicit), or what the output contains. The description adds some context about filter options but leaves significant behavioral gaps.

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 appropriately sized and front-loaded with the core purpose. The second sentence efficiently details filter options with specific examples. While concise, it could be slightly more structured by explicitly mentioning pagination parameters or grouping related filters.

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 moderate complexity (7 parameters, filtering functionality) and the presence of an output schema (which handles return values), the description is partially complete. It covers filter semantics well but misses pagination parameters and behavioral context. With no annotations and incomplete parameter coverage, it leaves gaps that could hinder effective tool selection and use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for 7 parameters, the description compensates well by explaining the semantics of 5 key parameters (statuses with enum values, invoice_id, search_term, from_date, to_date). It provides format details (ISO-8601 for dates) and the complete status enum. However, it doesn't mention the page and limit parameters at all, leaving their purpose undocumented.

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 as 'List payments with optional filters,' which is a specific verb+resource combination. It distinguishes itself from siblings like 'get_payment' (singular retrieval) and 'mark_payment_as_paid' (mutation), but doesn't explicitly differentiate from other list tools like 'list_invoices' beyond the resource type.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, compare with 'get_payment' for single payment retrieval, or indicate when filtering is appropriate versus using other list tools. Usage is implied through the filter descriptions but not explicitly stated.

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

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

With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions filtering capabilities but doesn't describe pagination behavior (implied by page/limit parameters), rate limits, authentication requirements, error conditions, or what constitutes a 'product' in this context. The description is functional but lacks operational context.

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 extremely concise with zero wasted words. The first sentence establishes core functionality, and the two bullet points efficiently document the most complex parameters. Every sentence earns its place, and the structure is front-loaded with the main purpose.

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 5 parameters with 0% schema coverage and no annotations, the description partially compensates by documenting two parameters but leaves three undocumented. The existence of an output schema means return values don't need explanation, but for a list operation with filtering and pagination, more behavioral context would be helpful. It's minimally adequate but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for 5 parameters, the description adds significant value by explaining the 'type' parameter's allowed values (ONE_OFF, RECURRING, METERED) and clarifying that 'active' filters by status. However, it doesn't mention 'page', 'limit', or 'currency' parameters at all, leaving three parameters completely undocumented.

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 verb ('List') and resource ('products') with the core functionality of optional filtering. It distinguishes from siblings like 'get_product' (singular retrieval) and 'create_product' (creation), but doesn't explicitly contrast with other list tools like 'list_coupons' or 'list_customers' beyond the resource name.

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?

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like 'get_product' for single product retrieval or 'create_product' for creation, nor does it specify prerequisites, access requirements, or contextual triggers for choosing this list operation.

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 no annotations provided, the description carries full burden. It discloses that pages are 'auto-discovered from the Stream docs sitemap' and returns specific fields (slug, URL, resource URI), which adds useful behavioral context. However, it doesn't mention potential limitations like rate limits or error conditions, leaving some gaps.

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 with zero waste. The first states the purpose, the second explains the discovery mechanism, and the third provides usage guidance. Each sentence earns its place, and the structure is front-loaded with the core functionality.

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 simplicity (0 parameters, no annotations, but has output schema), the description is mostly complete. It explains what the tool does, how it works, and when to use it vs. alternatives. However, it could benefit from mentioning the output format more explicitly, though the output schema mitigates this 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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters, and it appropriately focuses on the tool's purpose and usage without redundant parameter information.

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 verb 'List' and the resource 'Stream documentation pages', specifying it returns all available pages. It distinguishes from its sibling 'get_stream_doc' by indicating this tool lists metadata while the sibling fetches full content, providing clear 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?

The description explicitly states when to use this tool vs. alternatives: 'Use the slug with get_stream_doc to fetch the full content.' This provides clear guidance on using this tool for listing metadata and the sibling for detailed content, with no misleading information.

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

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

No annotations are provided, so the description carries the full burden. It states this is a manual marking/recording action, implying a mutation (changing payment status), but doesn't disclose critical behavioral traits such as permissions required, whether the action is reversible, side effects (e.g., updating invoice status), or error conditions. The mention of 'payment_method' enums adds some context but is insufficient for a mutation tool.

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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds context. The bullet point for 'payment_method' is efficient. There's minimal waste, though the structure could be slightly improved by integrating the enum list more seamlessly.

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 complexity (a mutation tool with no annotations and 0% schema coverage) and the presence of an output schema (which reduces the need to describe return values), the description is partially complete. It covers the tool's purpose and one parameter's semantics but lacks behavioral transparency, usage guidelines, and details for other parameters, making it adequate but with clear gaps.

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 has 0% description coverage, so the description must compensate. It adds meaningful semantics: it explains that 'payment_method' must be one of four specific values (CASH, BANK_TRANSFER, CARD, or QURRAH), which clarifies beyond the schema's string type. However, it doesn't explain 'payment_id' (the required parameter) or 'note', leaving gaps for 2 out of 3 parameters.

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: 'Manually mark a payment as paid' and 'Record a payment received through manual methods.' This specifies the verb ('mark as paid'), resource ('payment'), and context ('manual methods'), distinguishing it from automated payment processing. However, it doesn't explicitly differentiate from sibling tools like 'refund_payment' or 'get_payment' beyond the manual aspect.

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 minimal guidance: it implies usage for manual payments but doesn't specify when to use this tool versus alternatives (e.g., automated payment systems or other sibling tools like 'refund_payment'). No exclusions, prerequisites, or explicit alternatives are mentioned, leaving the agent with little context for decision-making.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a refund operation (implying a financial transaction reversal) but doesn't mention permissions required, whether refunds are reversible, rate limits, or what the response contains. The description adds minimal behavioral context beyond the basic action.

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 extremely concise with just two sentences. The first sentence states the core purpose, and the second provides essential parameter guidance. Every word earns its place with zero wasted text, making it front-loaded and efficient.

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 this is a financial mutation tool with no annotations, 4 parameters at 0% schema coverage, but with an output schema present, the description is minimally adequate. It explains the core action and provides some parameter guidance, but doesn't address behavioral aspects like permissions, reversibility, or error conditions that would be important for a refund operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and 4 parameters, the description provides crucial semantic information for one parameter (refund_reason) by listing its allowed values. However, it doesn't explain payment_id format, refund_note purpose, or the boolean flag's effect. The description adds meaningful value but doesn't fully compensate for the schema coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Issue a refund') and the target resource ('on a completed payment'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from potential sibling operations like voiding invoices or marking payments as paid, which would require a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like voiding invoices or marking payments as paid. It mentions the payment must be 'completed' but doesn't explain what constitutes completion or any prerequisites. No explicit when/when-not rules or named alternatives are provided.

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?

No annotations are provided, so the description carries full burden. It mentions the action ('(Re)send') and delivery methods, but lacks critical behavioral details: whether this triggers notifications, requires specific permissions, has rate limits, or what happens on failure (e.g., retry logic). For a communication tool with zero annotation coverage, this is insufficient.

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, efficient sentence with zero waste. It's front-loaded with the core action and resource, and every word ('(Re)send', 'invoice', 'customer', 'email / SMS') adds value. No extraneous details or repetition.

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 1 parameter, no annotations, but an output schema exists, the description is moderately complete. It covers the purpose and delivery methods, but lacks behavioral context (e.g., side effects, error handling) and parameter details. The output schema may handle return values, but for a tool that likely involves external communication, more guidance is needed.

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 0%, so the description must compensate. It doesn't mention the 'invoice_id' parameter at all, leaving it undocumented. However, with only 1 parameter, the baseline is higher; the description implies the tool operates on an invoice but doesn't explain parameter meaning or format. This is minimal but not entirely absent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('(Re)send') and target resource ('an invoice to the customer'), specifying the delivery methods ('via email / SMS'). It distinguishes from sibling tools like 'create_invoice' or 'void_invoice' by focusing on communication rather than creation or cancellation. However, it doesn't explicitly differentiate from all siblings (e.g., 'mark_payment_as_paid' might also involve notifications).

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?

No explicit guidance on when to use this tool versus alternatives is provided. The description implies it's for sending invoices, but doesn't specify prerequisites (e.g., invoice must exist, customer contact info required) or when not to use it (e.g., if invoice is voided). It mentions 'resend' but doesn't clarify scenarios for initial send vs. resend.

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 no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) and clarifies partial update behavior, but lacks critical details like permission requirements, error handling, or rate limits. For a mutation tool with 10 parameters, this is insufficient 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 extremely concise with two clear sentences. The first states the core purpose, and the second adds crucial behavioral context about partial updates. Every word earns its place with zero redundancy, making it efficiently front-loaded 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?

Given the complexity (10 parameters, mutation operation, no annotations) and the presence of an output schema, the description is incomplete. It doesn't explain parameter meanings, usage context, or behavioral implications beyond partial updates. For a customer update tool with many sibling operations, more guidance is needed despite the output schema.

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 0%, so the description must compensate for undocumented parameters. It only mentions 'fields' generically without explaining what fields are available, their purposes, or constraints. With 10 parameters (9 optional), this leaves significant semantic gaps, failing to add meaningful value beyond the bare 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 clearly states the tool's purpose: 'Update fields on an existing customer.' It specifies the verb ('update'), resource ('customer'), and scope ('existing'), distinguishing it from create_customer. However, it doesn't explicitly differentiate from update_product or other update operations, keeping it at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like get_customer or delete_customer. It mentions partial updates ('Only the fields you provide will be changed'), which is useful but doesn't address sibling tools or contextual usage scenarios, resulting in minimal guidance.

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?

No annotations are provided, so the description carries full burden. It states 'Only the fields you provide will be changed,' which adds useful partial-update behavior. However, it lacks critical details: permissions required, whether changes are reversible, rate limits, error conditions, or what the output contains. For a mutation tool with zero annotation coverage, this is insufficient.

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, front-loaded with core purpose. Every word earns its place: first sentence defines action and scope, second clarifies behavioral nuance. No fluff or repetition, efficiently structured for quick comprehension.

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 complexity (mutation tool), no annotations, 0% schema coverage, but has output schema, the description is moderately complete. It covers purpose and partial-update behavior, yet misses permissions, error handling, and output expectations. Output schema may help, but description should guide usage more fully for a write operation.

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 0%, so the description must compensate. It lists updatable fields (name, description, active status), mapping to 3 of 4 parameters, but omits product_id (required). It adds meaning by clarifying partial updates, though doesn't explain data types or constraints. Baseline is lowered due to coverage gap; description provides some but incomplete param context.

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 verb 'update' and the resource 'existing product', specifying the fields that can be modified (name, description, active status). It distinguishes from siblings like create_product (creates new) and archive_product (different action), though it doesn't explicitly name alternatives. Purpose is specific but could better differentiate from update_customer.

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?

No explicit guidance on when to use this tool versus alternatives like archive_product or create_product. The description implies usage for modifying existing products, but lacks context on prerequisites (e.g., product must exist), exclusions, or comparisons to sibling tools. Minimal usage context provided.

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 no annotations provided, the description carries the full burden. It discloses that voiding is irreversible ('can no longer be paid'), which is a key behavioral trait for a destructive operation. However, it doesn't mention other important aspects like permissions needed, error handling, or what the output contains, leaving gaps in behavioral context.

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 with zero waste: the first states the action and resource, and the second explains the consequence. It's front-loaded with the core purpose and efficiently structured, earning its place fully.

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 (destructive operation with no annotations) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the irreversible nature but could improve by mentioning prerequisites like invoice status or linking to sibling tools for better 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 input schema has 0% description coverage, so the description must compensate. It doesn't explicitly mention the 'invoice_id' parameter, but the context of 'an unpaid invoice' implies an identifier is needed. Since there's only one parameter, the description adequately conveys the semantics without detailed param info, meeting the baseline for 0 params.

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 ('void (cancel)') and resource ('an unpaid invoice'), making the purpose explicit. However, it doesn't differentiate from sibling tools like 'delete_customer' or 'refund_payment', which are also destructive operations, so it misses full sibling distinction.

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 usage by specifying 'unpaid invoice' as a prerequisite, but doesn't explicitly state when to use this tool versus alternatives like 'refund_payment' for paid invoices or 'delete_customer' for other cancellations. It provides some context but lacks clear exclusions or named alternatives.

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