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

With no annotations provided, the description carries the full burden. It explicitly warns 'Moves real money – only call this once you intend to complete the purchase,' disclosing the irreversible, financial nature. It also emphasizes the strict denomination match and price volatility. This is strong behavioral transparency 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?

Three sentences with no filler. The core action is front-loaded, followed by critical constraints and a warning. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential prerequisites (get_product), required conditional fields (recipient), and the irreversible nature. However, with no output schema, it does not mention what the tool returns (e.g., an order ID), which could be useful for the agent. This minor gap prevents a perfect score.

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

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

The schema already describes 3 of 4 parameters (75% coverage), including the exact-match requirement for denomination and the conditional recipient. The description adds extra meaning by explaining the E.164 format for phone numbers (no leading +) and reinforcing the need to fetch current prices. This goes beyond the schema, so a 4 is appropriate given the high baseline.

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: 'Places a live order, debited from your prepaid balance.' This is specific and distinguishes it from premium or SMM order tools by the emphasis on prepaid balance and denomination, even though it doesn't name siblings explicitly. The title 'Buy a product' reinforces the purpose.

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

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

The description gives a clear prerequisite: call get_product first to get current price and valid denoms. It also warns to only call when intending to complete the purchase. However, it does not explicitly state when not to use this tool versus alternatives like create_premium_order or create_smm_order, though the sibling names and the 'prepaid' context imply 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 fully carries the burden of behavioral disclosure. It explicitly states the financial consequence (debits wallet), irreversibility, and automatic idempotency key with safe retry semantics. This gives the agent essential knowledge about costs and error recovery well beyond the schema.

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

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

Three sentences, zero filler. The core action is front-loaded, followed by critical warnings and idempotency behavior. Every sentence earns its place and the structure is ideal for quick agent parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a money-spending, irreversible mutation with no output schema and no annotations, the description covers the most critical operational concerns: cost, reversibility, and retry safety. It does not describe the return value or any success/failure indicators, which would be useful but is not strictly required given the sibling tool get_premium_order exists for retrieval.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that an Idempotency-Key is sent automatically even if the parameter is not supplied, and by tying the recipient and product parameters to the user-confirmation requirement. This goes beyond the plain schema definitions.

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 ('buys a subscription seat') and the resource/effect ('debits your USD wallet'), distinguishing it from siblings like create_order and create_smm_order. The title reinforces the premium subscription scope and the money-spending nature.

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

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

It provides clear context for when to call (after confirming product, price, and recipient) and warns that the action is not reversible. However, it does not explicitly name alternatives or exclusion conditions, such as 'use for premium subscriptions only' or 'prefer list_premium_products first,' though these are implied by the description and title.

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 clearly discloses that this tool spends money, debits the wallet, and that delivery is irreversible once accepted. It also warns about the link being the delivery target. It doesn't mention idempotency behavior or failure modes, but the core risk profile is well covered.

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

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

Three sentences, all high-value. The most critical warning (spends money, confirm link) is front-loaded, and the irreversible delivery warning is included without padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a money-spending mutation tool with no annotations and no output schema, the description covers the essential risks and constraints. It could mention idempotencyKey usage or what happens on failure, but the core information an agent needs to avoid harmful calls is present.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds context about quantity min/max and the link being the delivery target, but doesn't add much beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Buys'), a resource ('social-media service'), and a critical side effect ('debits your wallet'). It also distinguishes itself from siblings like create_order and create_premium_order by naming the SMM service context and the wallet debit.

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 instructs the agent to confirm the link with the user first, warns that delivery cannot be recalled, and states that quantity must be within the service min/max. This is clear when-to-use and when-to-be-cautious guidance, though it doesn't name alternative tools for non-SMM orders.

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, the description carries the full burden. It discloses the primary effect (stops delivery) and reassures that orders are unaffected, also mentioning the fallback polling method. This is transparent for a simple mutation, though it does not state whether the deletion is permanent or reversible. Still, it covers the key behavioral impact.

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

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

Two short sentences, front-loaded with the main action and immediately followed by the key consequence. No filler words, every word earns its place. This is a model of concise tool documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, no-output-schema tool with no annotations, the description covers the essential behavior and points to the alternative (get_order). It could add a note that the webhook is permanently removed or that it must be recreated via set_webhook, but that is a minor omission. The description is adequate for an agent to call this tool correctly.

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

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

The tool has zero parameters, so the schema is trivially complete. The description adds no parameter details because there are none to add. Per the rubric, a 0-parameter tool gets a baseline of 4; the description adds value by explaining the behavioral outcome, so a 4 is appropriate.

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

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

The description clearly states the action ('Stops webhook delivery') and the resource (webhook). It is distinct from siblings like get_webhook, set_webhook, and test_webhook, making it obvious which tool to pick. The verb and object are specific and unambiguous.

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

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

The description provides a clear consequence ('Orders are unaffected; you fall back to polling get_order'), which implicitly tells the agent when to use this tool and what to do instead. However, it does not explicitly state a condition like 'use when you no longer want webhooks' or mention alternatives like set_webhook for replacement. The guidance is useful but not exhaustive.

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

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

No annotations are present, so the description must carry the behavioral disclosure. It implies a read-only operation via 'Returns', but does not explicitly mention that no data is modified, nor does it disclose potential errors, rate limits, or authentication requirements. It adds the fact that it returns the balance in ETB, which is helpful, but otherwise leaves behavioral details unspoken.

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 with no fluff. The core purpose is front-loaded ('Returns the calling partner account's current prepaid balance (ETB)'), and the second sentence adds relevant context without padding. Perfectly sized for a zero-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description is the sole source of behavioral and response information. It explains what the balance is used for but does not specify the response format (e.g., whether it returns a number, a string, or an object with currency). It also does not mention edge cases like zero balance or error handling. For a simple getter, this is acceptable but not complete.

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

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

The tool has zero parameters, so the baseline is 4. There is nothing to explain beyond what the schema already indicates (empty properties). The description does not need to elaborate on parameters, and it does not.

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

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

States the exact operation ('Returns'), the resource ('current prepaid balance'), the scope ('calling partner account'), and the currency ('ETB'). The added note 'Orders are paid from this balance' gives useful context that helps differentiate it from other balance tools like get_premium_balance, even though that sibling is not explicitly named.

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

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

Provides no explicit guidance on when to use this tool versus the sibling get_premium_balance. The phrase 'Orders are paid from this balance' implies a purpose but does not state when to choose this tool over alternatives or when not to use it. No exclusions or conditional logic are given.

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 operation is a read ('Returns') but doesn't disclose pagination, ordering, error behavior, or whether the category must be an exact ID from list_categories. The reference to list_categories adds some context but not enough for a 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?

One sentence, front-loaded with the action and scope, and the parenthetical reference to list_categories is efficient. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read tool, the description is minimal but lacks key context: no output schema, no pagination info, no error behavior, and no guidance on how the category value relates to list_categories output. The sibling list includes search_catalog and list_premium_products, so more routing context would help.

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 the category comes from list_categories, which adds meaning beyond the bare 'category' string property, but it doesn't explain the expected format (ID vs name) or how to obtain it beyond the parenthetical reference.

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

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

The description states a specific verb ('Returns') and resource ('every product in one category'), and references list_categories as the source of category values. It is clear what the tool does, though it doesn't explicitly distinguish it from sibling tools like search_catalog or get_product.

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 by noting the category comes from list_categories, which tells the agent where to get valid input. However, it doesn't explicitly state when to use this tool versus alternatives like search_catalog or list_premium_products.

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 behavioral burden. The verb 'Fetches' clearly signals a read-only operation, and the timeout-recovery use case implies the tool is safe to call again after uncertainty. It does not describe error behavior or response shape, but for a simple getter the key safety trait is clear.

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 front-loaded sentence that states the core operation first and then gives two concrete use cases. Every word earns its place with no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema, the description covers what the tool does, what it operates on, and when to use it. It does not enumerate possible status values or explicitly route away from premium/SMM siblings, but the create_order reference provides enough orientation.

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 provides only the parameter name and type for orderId, so the description adds meaning by explaining that the parameter is the ID of the order to check and that it is likely obtained from create_order. This meaningfully compensates for the 0% schema description 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 uses a specific verb and resource: it fetches the current status of one order by id, which clearly distinguishes this from list/history tools and from SMM/premium order variants. The purpose is immediately clear to an agent.

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

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

It explicitly states when to use the tool: to re-check an order after create_order or to recover from a timed-out call. It does not provide exclusions or name alternative tools such as get_smm_order or get_premium_order, so it stops short of a 5.

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

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

With no annotations provided, the description carries full behavioral disclosure. It states the result limit (up to 50) and ordering (newest first), which are key behavioral traits. It does not mention authentication or side effects, but the operation is clearly a read-only list.

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 sentence with no filler. Every word adds value: the cap (50), the scope (your recent orders), and the ordering (newest first).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple zero-parameter, read-only list endpoint without an output schema, the description covers the essential details needed to invoke it correctly. It could mention how to retrieve older orders beyond the first 50, but that is a minor gap for such a minimal API.

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

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

The tool has zero parameters, so the schema is already complete. The description's 'your recent orders' implies an authenticated-user context, which is sufficient. No parameter-level gaps exist to compensate for.

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

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

The description uses a specific verb and resource: 'Returns up to 50 of your most recent orders, newest first.' It clearly distinguishes this history-listing tool from siblings like get_order (which fetches a single order) and list_categories or search_catalog.

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

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

Usage context is implied by the title 'List your recent orders' and the description, but there is no explicit when-to-use or alternative guidance. An agent has to infer that this is the right tool for browsing recent orders rather than using get_order or search_catalog.

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 a meaningful behavioral trait: orders are refused with 402 when balance is insufficient. However, it does not describe the response format or any authentication requirements, leaving minor gaps for a simple getter 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 only two sentences, front-loaded with the core purpose, and the usage guidance is placed second. Every sentence earns its place with no redundancy, 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?

For a zero-parameter, no-output-schema tool, the description provides sufficient context: what it returns conceptually, when to invoke it, and a behavioral consequence. Minor omissions like response format or authentication are acceptable given the simplicity.

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

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

The tool has zero parameters, so per the rubric the baseline is 4. The description does not need to add parameter details since there are none, and the empty schema already covers all (nonexistent) 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 states the resource ('USD wallet premium balance') and the action ('get'), and the title reinforces it. It distinguishes from sibling get_balance by specifying 'premium' and 'USD', making the tool's specific purpose clear without ambiguity.

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

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

The description explicitly advises checking this balance 'before ordering' and explains the consequence of insufficient balance (402 refusal). This provides clear when-to-use context, though it does not explicitly mention alternatives or when not to use, so it stops short of a perfect 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses that delivery is separate from the order and requires a fulfilled status, which is useful. However, it does not explicitly state that this is a read-only operation, nor does it mention error conditions (e.g., what happens if status is not fulfilled). This is a moderate gap for a get 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 two concise sentences with the core purpose front-loaded. It conveys the main function and the key usage condition without any filler. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a single parameter and no output schema, the description covers the essential context: what it returns, when to call it, and how it differs from inline delivery. It does not specify the response format or error behavior, but given the low complexity, this is a minor omission.

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

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

Schema description coverage is 0%, so the description must compensate. It only implies that orderId refers to the fulfilled premium order but does not explicitly state that orderId is the premium order's ID or how to obtain it. The description adds minimal meaning beyond the schema's bare property definition.

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

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

The description states a specific verb ('collect') and resource ('premium delivery') and clarifies that it returns credentials/invite/link. It distinguishes from store orders by noting delivery is not inline. However, it does not name a specific sibling tool like get_premium_order, relying on a category contrast rather than explicit 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 gives a clear condition for use: 'you must call this once status is fulfilled.' It contrasts with store orders, implying when not to use it (for store orders). It lacks explicit mention of alternatives, but the context is sufficient for an agent to infer it is the dedicated delivery retrieval tool.

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

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

With no annotations, the description carries the full behavioral burden. 'Status of a premium order' signals a read-only operation, and 'poll this' plus 'recover from a timed-out call' convey idempotency and safe repeated invocation. It does not discuss auth, rate limits, or error behavior, but it covers the essential behavioral profile for a getter.

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

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

Two short sentences, front-loaded with the core purpose and followed by concrete usage guidance. Every word earns its place, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter status getter with no output schema, the description gives enough context to call it correctly: what it returns conceptually, when to call it, and how it fits the order lifecycle. It does not describe status values or error conditions, but these are not essential for selecting and invoking the 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?

Schema coverage is 0% and the description does not mention orderId at all. The parameter name is self-explanatory, and the lifecycle context (after create_premium_order) hints at where the ID comes from, but the description adds little explicit meaning beyond the schema.

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

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

The description clearly identifies the resource as a premium order and the action as retrieving its status, which is more specific than the title alone. It does not explicitly contrast with closely related siblings like get_premium_delivery, so it stops short of a full 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?

It gives explicit when-to-use guidance: poll after create_premium_order or recover from a timed-out call. It does not state when not to use it or name alternative tools, so it lacks the full exclusionary guidance of a 5.

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

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

With no annotations, the description carries full behavioral disclosure. It transparently indicates a read-only operation ('Fetches') and adds valuable context about the freshness of the data ('current tier price and stock', 'live price'). It does not describe potential errors or rate limits, but for a simple read operation, the implied safety and data freshness are sufficient.

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

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

A single sentence that front-loads the core function and then immediately gives practical usage guidance. Every clause earns its place, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema and no annotations, the description covers the essential context: what is fetched, that the price is live, and when to call it. It does not describe the output structure or error behavior, but these are less critical given the simplicity and the explicit guidance that this feeds directly into create_premium_order.

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

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

The input schema already has 100% coverage, including a helpful description ('Product id from list_premium_products'). The tool description itself adds no additional parameter semantics beyond that. The baseline of 3 is appropriate since the schema does the heavy lifting and the description does not need to compensate.

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

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

The description states a specific verb ('Fetches'), resource ('subscription product'), and scope ('one', with current tier price and stock). This clearly distinguishes it from list_premium_products (list vs single) and get_premium_order (order vs product), giving an agent immediate differentiation without opening schemas.

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

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

The description explicitly tells the agent when to use this tool: 'call this right before create_premium_order so you are quoting a live price.' This is a clear usage context, though it does not explicitly name alternatives or when not to use other get tools. The sibling list makes the distinction apparent, but the description itself lacks explicit 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?

Since no annotations are provided, the description carries the behavioral disclosure burden. It reveals a non-obvious behavior: the tool returns the current live price, and it implies freshness by instructing to call right before create_order. It doesn't explicitly state read-only nature or error handling, but 'fetches' strongly implies a safe read operation. This is adequate coverage for a simple get 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 a single, tightly worded sentence that front-loads the core action ('Fetches one product by id'), then adds the key behavioral detail (live price) and the usage hint (call before create_order). Every clause earns its place with zero redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter get tool without an output schema, the description covers the essential aspects: what it returns (product with live price) and when to call it. It also integrates with sibling tools by referencing search_catalog, get_category, and create_order. It doesn't describe the return structure or error behavior, but those are often acceptable to leave to the schema or inference for such a simple 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. It explains that productId is an identifier obtained from search_catalog / get_category, adding meaning beyond the schema's type and minLength. This tells the agent where to source a valid id, which is valuable. It doesn't specify format nuances, but the schema already provides type and length constraints.

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 a specific action: 'Fetches one product by id' and includes a key differentiator: 'including its current live price'. It also names the source tools (search_catalog / get_category) for the id, which helps distinguish it from search and category listing siblings. While it doesn't explicitly contrast with get_premium_product, the context of 'create_order' and 'product' rather than 'premium product' makes the purpose unambiguous.

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

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

The description provides explicit when-to-use guidance: 'always call this right before create_order to get the exact denomination.' It also states where the id comes from (search_catalog / get_category), telling the agent how to obtain a valid parameter. This is clear and actionable, though it doesn't mention premium alternatives, the regular-order context is sufficient.

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 indicates a read-only operation by stating it returns status and progress, but it does not explicitly state that it has no side effects, nor does it mention error behavior or permissions. Minimal disclosure.

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

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

A single concise sentence that front-loads the key information. No wasted words or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple get operation with one parameter and no output schema, the description gives the essential information about what is returned (status and progress). However, it does not describe the exact structure or fields of the response, nor does it mention any error conditions. Adequate for a straightforward lookup but lacks detail.

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 a single required parameter orderId with no description. The tool description does not explain what orderId refers to or any constraints beyond the schema's minLength 1. With 0% schema description coverage, the description adds no value to the parameter meaning.

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 returns status and real delivery progress (start count, delivered so far, remaining) for an SMM order. It is specific about the resource and the data returned. However, it does not explicitly differentiate it from sibling tools like get_order or get_premium_delivery, relying on the name for that.

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 on when to use this tool versus alternatives. It does not mention that this is for SMM orders specifically or contrast with get_order or get_premium_order. The agent must infer usage from the 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, the description carries the behavioral burden. It discloses that the tool returns null when no webhook is configured and mentions recent delivery health, which is helpful. However, it does not explicitly state that this is a read-only operation or describe error handling or authentication requirements, though these may be less critical for a getter.

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 concise sentence that front-loads the key purpose and includes the important null return behavior. No unnecessary words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless getter with no output schema, the description is complete enough: it states what the tool returns and the special null case. Minor omissions like explicit read-only confirmation are not critical, but given no annotations, a slightly richer description could mention that it only reads configuration. Still, it is adequate.

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

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

The tool has zero parameters, so the schema description coverage is trivially 100%. The description adds no parameter-specific information because there are none to describe, meriting the baseline score of 4.

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

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

The description clearly states the tool retrieves the webhook endpoint and its recent delivery health, and returns null if none is configured. It specifies the resource (webhook endpoint) and the action (get), making it distinguishable from sibling write/delete/test operations, though it does not explicitly contrast with them.

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 is given on when to use this tool versus alternatives like set_webhook, delete_webhook, or test_webhook. The description implies it is the getter, but does not state conditions, prerequisites, or when one would choose it over other webhook-related tools, leaving the agent to infer from the name.

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 responsibility. It discloses the primary behavior (returns categories with counts) and implicitly indicates a read operation ('returns'), but it does not mention any potential side effects, authentication requirements, rate limits, or output format details. For a simple list operation, this is acceptable but not comprehensive.

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, front-loaded sentence that immediately states the action and resource. It lists the categories concisely and avoids unnecessary fluff. Every word serves a purpose, making it highly 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?

For a tool with no parameters and no output schema, the description covers the essential function: returning all categories with counts. However, it does not describe the return format (e.g., array vs. object, field names), which could be helpful. Given the simplicity of the operation, this is a minor gap and the description is largely complete.

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

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

There are zero parameters and schema coverage is 100% (vacuously), so there are no parameter semantics to explain. The description adds no parameter-related information, which is appropriate given the absence of parameters. Baseline for 0 parameters is 4.

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 'returns' and the resource 'each product category', listing the exact categories (airtime, esim, giftcards, gaming, bills) and the associated item count. This makes the tool's purpose unambiguous and distinct from siblings like get_category (single) or list_premium_products (premium-only).

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 states what the tool does but does not explicitly mention when to use it versus alternatives. The context implies it is for retrieving all categories, but there is no guidance such as 'use get_category for a single category' or 'use search_catalog for filtering'. The usage is inferred, not 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 present, the description carries the burden of behavioral context. It usefully discloses that the same API key opens both catalogs, that pricing depends on reseller tier, and that the premium catalog uses a separate USD wallet. It does not mention rate limits or response shape, but for a read-only list operation this is adequate.

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 compact, information-dense sentences. The first sentence defines the contents, and the second adds the key operational distinction between premium and store, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless list operation, the description covers scope, pricing, authentication, and catalog/wallet separation. It does not describe the return envelope or possible pagination, and there is no output schema to offload that, leaving a minor gap.

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

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

The input schema has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds relevant context about what premium products are, but no parameter-specific documentation is required.

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 tool name and title already supply a specific verb and resource, and the description enriches this by defining premium products as reseller-tier subscription seats and explicitly marking them as a separate catalog from the store. This clearly distinguishes it from store catalog siblings such as search_catalog and get_product.

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

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

The description gives clear context for when to use the tool by stating that premium products are a separate catalog and separate USD wallet from the store, while sharing the same API key. It does not explicitly name alternative tools such as get_premium_product or list_smm_services, so it stops short of full exclusion 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?

With no annotations, the description carries the burden of disclosing behavior, and it does so well: returns a potentially huge list, requires a query for relevance, and strictly enforces min/max server-side. It adds operational context beyond the schema, such as the scale of data and server-side refusal of invalid orders. It does not mention response format or sorting, but those are minor given the tool's simple list nature.

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

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

Three sentences, each with a clear job: defining the resource/data, warning about the need for a query, and noting server-side enforcement. The most critical usage guidance (always pass a query) is front-loaded in the second sentence and reinforced with concrete examples. No filler or redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description tells an agent what the tool returns (rate and min/max size), how to call it effectively (query required, optional limit), and a key behavioral constraint (server-side enforcement). There is no output schema, so a bit more detail about response fields (IDs, names, categories) would improve completeness, but the description covers the essentials for correct invocation.

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

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

Schema description coverage is 100%: both limit and query are already explained in the input schema. The description adds useful emphasis that query should always be passed and warns about unfiltered results, but it does not provide new syntactic or semantic parameter details beyond the schema. Baseline 3 is appropriate.

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

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

The description specifies a unique resource—social-media services (followers, views, likes)—and the key data returned: rate per 1000 and min/max order size. It clearly distinguishes this tool from siblings like list_premium_products and search_catalog by narrowing to SMM services. Even without the verb 'list', the title plus the implied return of a list makes the purpose unambiguous.

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

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

The description provides strong context on how to use the tool: ALWAYS pass a query because there are ~7,500 services and an unfiltered list is enormous and mostly irrelevant. It does not explicitly name alternatives or state when not to use this tool in favor of siblings, but the SMM-specific framing makes the intended usage clear.

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

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

No annotations are present, so the description must carry the transparency burden. It discloses the search behavior (full-text), the result cap (up to 50), and that prices are live. However, it doesn't explicitly state the operation is read-only (though implied) or address rate limits or auth requirements. For a read-only search, this is adequate but not exhaustive.

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 consists of two efficient sentences that front-load the purpose and immediately state the key behavioral constraints (result limit, live prices). Every word earns its place, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema, the description provides a solid high-level picture of what is returned (products with live prices, up to 50) and the search scope. It doesn't detail pagination or result fields, but given the tool's simplicity and the absence of an output schema, it is reasonably complete for agent decision-making.

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 covers the query parameter with examples, and the tool description adds no additional parameter-level information. With 100% schema coverage, the baseline of 3 is appropriate even though the description doesn't further elaborate on query syntax.

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 searches the catalog (airtime, eSIMs, gift cards, game top-ups) and returns up to 50 products with live prices. This specific verb+resource scope differentiates it from sibling list/get tools without needing to open their schemas.

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

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

The description implies this is the tool for free-text search across the listed categories, but it doesn't explicitly say when to use it instead of alternatives like list_categories or get_product, nor does it mention when not to use it. Usage context is left 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals a critical behavior: the signing secret is returned exactly once and cannot be read back, which is essential for the agent to inform the user. It also discloses that private, loopback, and cloud-metadata addresses are refused, and that the endpoint is called on every terminal order state. These are significant and non-obvious behaviors.

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

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

The description is concise, two sentences, with the primary purpose front-loaded. The critical warning about the one-time secret is emphasized in caps, making it visually prominent. There is zero redundancy; every clause adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a registration tool with only 2 parameters and no output schema, the description covers the essential aspects: purpose, the one-time secret, and address restrictions. It does not explicitly state whether calling again overwrites an existing webhook or if it is idempotent, which could be relevant for an agent deciding whether to re-call. This is a minor gap given the simplicity of the 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?

Schema coverage is 100%, with both parameters (url and events) described in the schema. The description adds minimal parameter-specific meaning; it reiterates the 'https' requirement and the 'on every terminal order state' trigger, but that is more about tool behavior than parameter semantics. The schema already handles parameter meaning adequately, so baseline 3 applies.

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

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

The description uses a specific verb ('Registers') with a clear resource ('an https endpoint') and a precise trigger ('on every terminal order state'), directly addressing the agent's need to stop polling. It also implicitly differentiates from siblings like get_webhook, delete_webhook, and test_webhook by focusing on registration and the one-time secret.

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

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

The phrase 'so you can stop polling' provides a clear use case and implies the alternative of continuous polling. It also gives explicit constraints (refused addresses) that guide when not to use it. However, it does not explicitly name sibling tools like get_webhook for verification or delete_webhook for removal, so the routing is 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, the description carries the behavioral disclosure burden. It transparently states that a signed test event is posted to the configured endpoint and that the response is returned. It does not dwell on side effects or requirements, but the posted-test-event behavior is clearly conveyed.

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 one focused sentence with no filler. It front-loads the action and target, then gives the purpose, making it quick for an agent 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?

For a zero-parameter tool with no output schema, the description adequately covers the action, target, returned information, and purpose. It could be slightly more explicit about prerequisites or the exact response shape, but those are minor gaps for such a simple 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 input schema has zero parameters, so there are no parameter semantics for the description to explain. The zero-parameter baseline of 4 applies.

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

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

The description uses a specific verb ('Posts'), a specific resource ('a signed test event'), a target ('configured endpoint'), and a clear outcome ('reports what came back'). It clearly separates this tool from webhook configuration siblings like set_webhook and delete_webhook.

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

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

The phrase 'so a partner can verify their signature check before relying on it' provides clear usage context and implies this is a verification step after configuration. It does not name alternatives or state explicit when-not-to-use conditions, but the context is still clear.

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