Server Quality Checklist

Tool Scores

• get_subscription_analyticsC
  2.9/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true and openWorldHint=true, so the description only needs to add behavioral context beyond safety. It adds the fact that 'view selects the ClickBank report' and that subscription data is fetched, which is mildly useful. It does not disclose pagination behavior, rate limits, or report size, though page/maxPages schema entries partially cover pagination.

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

  Conciseness4/5

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

  The description is short, direct, and front-loaded with the main action. The second sentence adds useful view context without fluff. It loses a point because the report list is abbreviated and does not match the enum exactly (e.g., 'cancel windows' is a summary rather than the actual view names).

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

  Completeness2/5

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

  This is a complex 12-parameter tool with no output schema, five enum parameters, and multiple report view variants. A two-sentence description is insufficient to make an agent invoke it correctly across views. It omits view-specific requirements such as when status is required, how dates interact with trend/cancel reports, and what role means.

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

  Parameters2/5

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

  With only 58% schema description coverage, the description must compensate for undocumented parameters like role, view, orderBy, sortDirection, groupBy, productId, and endDate. It provides only a partial gloss of the view parameter ('details, next_payment, cancel windows, by_status, trends') and ignores all other parameter semantics, leaving significant meaning unexplained.

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

  Purpose4/5

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

  The description names a specific verb ('Fetch'), a resource ('subscription details or trends'), and points to ClickBank report views, so an agent can identify it as a subscription analytics tool. However, it does not explicitly distinguish it from siblings like get_analytics or get_refund_amounts, and 'details or trends' is somewhat broad.

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

  Usage Guidelines2/5

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

  The description says 'view selects the ClickBank report' but gives no guidance on when to use this tool versus the many sibling analytics/reporting tools. There are no conditions, exclusions, or alternative tool names mentioned, so an agent must infer applicability from the resource name alone.

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

• get_orderB
  3.1/5.0
  Behavior2/5

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

  Beyond the readOnlyHint annotation, the description does not disclose behavior such as what happens for an unknown receipt, whether multiple orders can share a receipt, or what fields are returned. It adds no behavioral context beyond restating the tool's purpose.

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

  Conciseness5/5

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

  The description is a single, tightly worded sentence with no filler or redundant clauses. The required input is front-loaded in the phrase 'for a receipt ID,' giving maximum clarity in minimal space.

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

  Completeness3/5

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

  For a single-parameter read-only lookup, the description provides enough to invoke the tool correctly. However, with no output schema, it does not specify what 'order details' includes or how missing or invalid receipts are handled, leaving some ambiguity.

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

  Parameters3/5

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

  Schema coverage is 100%: the receipt parameter is already documented as a ClickBank receipt ID. The description repeats this same concept without adding format constraints, lookup semantics, or edge-case details, so the baseline of 3 applies.

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

  Purpose4/5

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

  The description states a clear action ('Get order details') and a key lookup resource (receipt ID), making the tool's function immediately identifiable. It does not explicitly contrast with sibling tools like list_orders or get_order_upsells, so it misses full differentiation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to choose this tool over alternatives such as list_orders, get_order_upsells, or check_order_active. The only implicit signal is that it requires a receipt ID, which is not enough to help an agent decide between tools.

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

• get_analyticsB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It usefully adds that summarize=true changes the call to a totals/summary endpoint, but it does not disclose pagination behavior, date-range defaults, or what the response shape looks like. This is adequate but not rich beyond annotations.

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

  Conciseness5/5

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

  Two sentences with no filler. The core action is stated clearly and the most important switch ('summarize=true') is called out as an imperative. Every word earns its place.

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

  Completeness2/5

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

  This is a 14-parameter tool with no output schema, yet the description does not mention date-range inputs, pagination, result shape, or relevant sibling tools. An agent could select the wrong analytics tool or make incorrect assumptions about scope and return format.

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

  Parameters3/5

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

  Schema description coverage is only 43%, so the description carries some burden for parameter clarity. It adds meaning to role (vendor vs affiliate) and dimension (with examples like product and country), and clarifies summarize as the totals switch. However, many parameters (select, orderBy, dimensionFilter, page, maxPages, dates) remain unexplained beyond enum names or schema descriptions.

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

  Purpose4/5

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

  The description uses a specific verb ('Fetch') and names the resource ('vendor or affiliate analytics') with the key grouping concept ('by dimension'). It gives concrete examples ('product, country, tracking id') that clarify what the tool returns, but it does not explicitly differentiate it from sibling analytics tools like get_subscription_analytics.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives such as get_subscription_analytics, list_quickstats, or summarize_quickstats. It implies usage through the role/dimension parameters but provides no exclusions or alternative routing.

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

• count_ordersB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and open-world behavior are covered. The description adds the useful behavioral note that filtering matches list_orders, but it does not disclose the return format or whether the count is bounded or paginated. With annotations covering the main behavioral concerns, this is adequate but not rich.

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

  Conciseness4/5

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

  The description is a single sentence that front-loads the core action and immediately references the relevant sibling for filter semantics. It is concise with no wasted words, though it leans heavily on list_orders and could be considered slightly under-specified.

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

  Completeness2/5

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

  There is no output schema, and the description does not state what the tool returns (e.g., a single integer count, a formatted response, or a count with metadata). With 12 parameters and only 33% schema coverage, the description should provide more context about the filter set and return value. The indirect reference to list_orders is insufficient for an agent to invoke this tool confidently without locating that sibling's definition.

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

  Parameters2/5

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

  Schema description coverage is only 33%, with 8 of 12 parameters lacking descriptions. The description says the filters are 'the same as list_orders', but this is indirect and depends on knowledge of another tool's schema. Parameter names and enums provide partial self-evident meaning, but the description does not compensate for the low schema coverage.

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

  Purpose4/5

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

  The description uses a specific verb and resource: 'Count orders'. It also references list_orders, which signals this is the counting counterpart to that listing tool and helps distinguish it from other order-related siblings like get_order or check_order_active. It does not enumerate the filters, but the schema provides that detail.

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

  Usage Guidelines4/5

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

  The phrase 'matching the same filters as list_orders' gives clear contextual guidance: use this when a count is needed instead of a full order list, using identical filter semantics. It does not explicitly state when not to use it or name alternatives like count_shippable_orders, but it clearly points to the most relevant sibling.

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

• list_ordersB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and openWorldHint, so the description does not need to restate safety. However, it adds little behavioral detail beyond the filtering scope and does not disclose pagination semantics, default date range, or how filters combine.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence with no filler: verb and object first, followed by the filter dimensions. Every word contributes, and it avoids duplicating schema details.

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

  Completeness3/5

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

  For a 14-parameter tool with no output schema, the description plus input schema covers many mechanics such as page size, maxPages, and date format. Still, it lacks explicit statement of return shape and filter combination semantics, which are important for correct invocation.

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

  Parameters3/5

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

  With 50% schema coverage, the description helps by naming several undocumented filter parameters such as type, vendor, and email. But it omits role, item, lastName, and postalCode, and does not clarify whether filters are combined or mutually exclusive.

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

  Purpose4/5

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

  The description clearly states the action ('List'), the resource ('orders'), and the key filter dimensions ('date, type, vendor, affiliate, email, or tracking'). This distinguishes it from single-order or counting siblings, though it does not explicitly contrast with list_shippable_orders.

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

  Usage Guidelines2/5

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

  No when-to-use guidance or alternative mention is present. The filter list implies a query use case, but an agent receives no help deciding between list_orders, count_orders, get_order, or list_shippable_orders.

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

• list_quickstatsB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint and openWorldHint annotations already convey that this is a safe read operation. The description adds useful context about the data content (daily sale, refund, chargeback totals) but does not disclose pagination behavior, return format, or how the openWorldHint affects result completeness.

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

  Conciseness5/5

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

  The description is a single focused sentence with no filler or redundancy. It front-loads the core data content and remains appropriately short for the tool's simplicity.

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

  Completeness3/5

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

  The description conveys the essential output concept but relies heavily on the schema for pagination and defaults. With no output schema present, it would benefit from explicitly noting that results are paginated or that it returns a list of daily records.

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

  Parameters3/5

  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 mentions account and date range, which maps to the relevant parameters, but adds no meaning beyond what the schema provides.

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

  Purpose4/5

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

  The description clearly identifies the resource: daily sale, refund, and chargeback totals for an account and date range. It is specific enough to understand what the tool returns, though it does not explicitly differentiate itself from siblings like summarize_quickstats or get_analytics.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as summarize_quickstats or get_analytics. The description implies a use case but provides no exclusions, prerequisites, or selection criteria.

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

• count_shippable_ordersB
  3.4/5.0
  Behavior2/5

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

  The readOnlyHint annotation already covers the safety profile, so no mutation disclosure is needed. However, the description omits a key behavioral trait: the interaction between pagination (page/maxPages) and the count result. Since maxPages defaults to 1 and limits fetched pages, the count may not represent a total, and the description does not disclose this.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. It states the verb, resource, and scope efficiently, earning every word.

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

  Completeness2/5

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

  Despite strong schema coverage, the description is thin for a tool with 7 optional parameters and no output schema. It does not clarify whether the returned count is the total across all pages or only the pages fetched via page/maxPages, which is a material gap for a counting tool. An agent could easily misinterpret the result.

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

  Parameters3/5

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

  Schema description coverage is 86%, so most parameters are already documented with meaningful detail (dates, receipt override, maxPages, status enum). The description adds no parameter-level semantics beyond 'shipping filters', but the schema carries the burden. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description uses the specific verb 'Count' and identifies the resource as 'physical-goods orders matching shipping filters', which clearly distinguishes it from siblings like count_orders (all orders) and list_shippable_orders (list vs count). It is not a tautology and states the tool's core function unambiguously.

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

  Usage Guidelines3/5

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

  The description implies when to use this tool—when a count of physical-goods orders is needed—but it does not mention alternatives or exclusions. Siblings such as count_orders and list_shippable_orders are not referenced, so the agent must infer the boundary from the name rather than from explicit guidance.

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

• count_ticketsA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint and openWorldHint annotations already establish this as a safe read operation, and the description adds that the operation produces a count rather than ticket objects. However, it does not clarify how the filters combine, whether results are grouped, or what the response shape looks like.

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

  Conciseness5/5

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

  The description is a single sentence with no filler or unnecessary detail. It front-loads the action and resource, and every word contributes to the core meaning.

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

  Completeness3/5

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

  For a simple count tool, the description is serviceable, but it leaves important gaps: no output schema is present, 'or' makes filter combination ambiguous, and the receipt parameter is undefined. An agent could invoke the tool correctly with basic inference, but not with full confidence about multi-parameter behavior.

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

  Parameters2/5

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

  The schema has 0% description coverage, so the description must compensate, but it only repeats the parameter names as filtering dimensions. It does not explain what 'receipt' means, whether the parameters combine with AND or OR logic, or whether the count is filtered or grouped by these values.

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

  Purpose5/5

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

  The description clearly states a specific verb ('Count') and a specific resource ('tickets') and names the three filtering dimensions: type, status, or receipt. This distinguishes it from sibling tools like list_tickets or get_ticket, which return ticket data rather than counts.

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

  Usage Guidelines3/5

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

  There is no explicit guidance about when to use this tool versus list_tickets or get_ticket, but the verb 'Count' and the tool name imply it is for aggregate numeric summaries rather than retrieving ticket details. The usage context is implied, not stated.

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

• get_refund_amountsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds a useful behavioral detail: the tool converts amounts into the customer's currency rather than returning raw amounts. However, it does not describe the response shape, limits, or any edge-case behavior, 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.

  Conciseness5/5

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

  A single, front-loaded sentence with no filler. It conveys the action, the refund types, and the currency-conversion behavior without redundancy.

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

  Completeness3/5

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

  For a simple read-only preview tool, the description plus schema is minimally adequate, but the lack of an output schema and thin parameter documentation means the agent must still infer what the return value looks like and what receipt/sku mean. More detail would make it fully self-sufficient.

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

  Parameters2/5

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

  Schema description coverage is only 25%, with only refundAmount having a description. The tool description merely restates the enum values and does not explain how receipt, sku, or refundAmount relate to the conversion, so it fails to compensate for the low schema coverage.

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

  Purpose5/5

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

  The description names a specific action ('Preview'), a clear resource ('refund amounts'), and a defining scope ('converts in the customer's currency'). It also calls out the three refund types, so an agent can distinguish this from the broad analytics/order sibling tools.

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

  Usage Guidelines3/5

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

  The word 'Preview' implies the tool is for simulating or calculating a refund before it happens, but the description never states when to prefer this tool over alternatives or what prerequisites apply. There is no explicit when/when-not guidance, only an implied use case.

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

• get_ship_noticesA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already discloses that this is a read-only operation. The description adds the small behavioral detail that only notices 'already filed' are returned, but it does not describe return shape, pagination, or empty-result behavior.

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

  Conciseness5/5

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

  The description is one short sentence that front-loads the core action and resource. It contains no filler and every word contributes to the tool's purpose.

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

  Completeness4/5

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

  For a simple read-only tool with a single parameter, the description is reasonably complete. It identifies the input (receipt) and the result concept (shipping notices), though it does not detail the response fields.

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

  Parameters3/5

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

  The schema only defines 'receipt' as a required string, and schema description coverage is 0%. The description adds meaning by tying the receipt parameter to the receipt whose shipping notices are requested, but it does not specify formats or expected value types beyond the schema.

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

  Purpose5/5

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

  The description uses a specific verb 'Get' and a specific resource 'shipping notices already filed for a receipt'. This clearly differentiates the tool from siblings like get_refund_amounts, get_ticket, and get_order, which target different resources.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus alternatives such as list_shippable_orders or get_order. The description implies it is for fetching existing ship notices for a receipt, but it never states exclusions or conditions.

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

• list_ticketsA
  3.6/5.0
  Behavior3/5

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

  Annotations already supply readOnlyHint and openWorldHint, so the safety profile is covered. The description contributes the 7-day date-window limit, which is a real behavioral constraint, but it does not add other behavioral context such as pagination semantics or response scope. That is adequate but not rich.

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

  Conciseness5/5

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

  Two short sentences, with the core action in the first sentence and the key constraint in the second. No filler, no repetition of schema details; the structure is front-loaded.

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

  Completeness3/5

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

  For an 11-parameter tool with no output schema, the description is a bit thin: it doesn't clarify default behavior when no filters are supplied, what a ticket result looks like, or how this relates to get_ticket/count_tickets. The schema and annotations cover a lot, and the date-window rule is the main added completion, but the agent is still left inferring some invocation expectations.

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

  Parameters4/5

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

  Schema coverage is only 73% and leaves type/status/receipt unexplained. The description adds useful semantics by mapping ticket categories to support/cancel/refund, which helps interpret the cryptic enum values, and it states the relationship among the six date parameters. This compensates for some of the schema gaps.

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

  Purpose4/5

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

  The description states a concrete action ('Search') on a specific resource ('tickets') and enumerates ticket categories (support, cancel, refund). It is clear on what the tool does at a high level, but it does not explicitly differentiate from siblings like get_ticket or count_tickets, so it misses the top score.

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

  Usage Guidelines3/5

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

  The description implies this tool is the place to search or list tickets ('Search support, cancel, and refund tickets') and adds a concrete filter constraint (date windows cannot exceed 7 days). It gives no explicit when-not-to-use guidance or pointers to get_ticket/count_tickets, leaving the choice to inference.

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

• list_shippable_ordersA
  3.7/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds domain scope and filter axes but does not disclose behaviors such as pagination, default date windows, or receipt/date interactions beyond what the schema already documents.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence with no filler. It states the action, resource, and key filter dimensions in concise order.

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

  Completeness3/5

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

  Given seven optional parameters and no output schema, the description is economical but leaves response shape and pagination behavior to inference. It also does not clarify the relationship to sibling count/list tools, so an agent may need to rely on assumptions or the schema to fully anticipate the call.

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

  Parameters3/5

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

  Schema description coverage is 86%, and the schema already documents days, page, date format, receipt override, and maxPages. The description's high-level grouping into status, date range, and receipt provides a useful summary but adds no new semantic detail beyond the schema.

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

  Purpose5/5

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

  The description clearly states the action ('List'), the resource ('physical-goods orders' / ClickBank shippable orders), and the main filtering dimensions ('shipped status, date range, or receipt'). This makes it distinguishable from siblings like list_orders or get_order even without opening the schema.

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

  Usage Guidelines3/5

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

  The phrase 'physical-goods orders' implies the intended scope and the filter dimensions signal common use cases. However, it does not name alternatives or state when to prefer this over list_orders or count_shippable_orders, so usage guidance remains mostly implicit.

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

• summarize_quickstatsA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare the operation as read-only, so no mutation warning is needed. The description adds the aggregation scope, but it does not disclose whether the summation spans all fetched pages or only the current page, nor does it describe the result format. This leaves some behavioral ambiguity.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence with no filler. Every word contributes to identifying the operation, the data being summed, and the scope.

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

  Completeness3/5

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

  The description and schema together cover how to invoke the tool for a basic use case, and all parameters are optional with documented defaults. However, there is no output schema and the description does not clarify the exact return shape or how pagination/maxPages affects the aggregated totals, leaving moderate gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so every parameter already has meaningful documentation including defaults and constraints. The description adds little beyond the 'account and date range' context, but the schema carries the parameter burden, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Sum') and names the resource and scope ('sale, refund, and chargeback amounts for an account and date range'). It clearly distinguishes this aggregation tool from sibling list-style tools like list_quickstats, which would return raw rows rather than totals.

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

  Usage Guidelines3/5

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

  The aggregation intent is clear and implies the tool should be used when totals are needed, but the description does not explicitly say when to prefer it over list_quickstats or mention any exclusions. Usage context is implied rather than stated.

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

• get_order_upsellsA
  4/5.0
  Behavior3/5

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

  The readOnlyHint=true and openWorldHint=true annotations already establish the safety profile, so the description only needs to add contextual behavior. The phrase 'for a parent receipt' adds the parent-child relationship constraint, but the description does not disclose behavior such as empty-result handling or whether results can be returned for non-parent receipts. There is no contradiction with annotations.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the action and object with no filler. Every word contributes semantic value.

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

  Completeness4/5

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

  For a single-parameter, read-only listing tool, the description covers the core input condition and the implied output. Because there is no output schema, a slightly more explicit note on the returned upsell transaction shape or behavior when none exist would make it fully complete, but this remains adequate.

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

  Parameters4/5

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

  Schema coverage is 100%, with the receipt parameter already described as a 'ClickBank receipt ID.' The description adds the 'parent receipt' role, which is a meaningful constraint beyond the schema's type-level description. This tells the agent not just what to pass, but which receipt qualifies.

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

  Purpose5/5

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

  The description uses a specific verb ('List') with a clear resource ('upsell transactions') and a scope qualifier ('for a parent receipt'), which sets it apart from sibling order tools like get_order or list_orders. Even without naming a sibling, the phrasing makes the tool's unique purpose evident.

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

  Usage Guidelines3/5

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

  The description implies the tool should be used when upsell transactions for a given parent receipt are needed, but it does not explicitly state when to prefer it over alternative tools or what conditions make it inappropriate. The context is clear enough for a simple tool, but no exclusions or alternatives are provided.

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

• get_productA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description is consistent with that. It adds modest scoping detail (a single product keyed by SKU and site nickname), but does not cover error or not-found behavior; no contradiction exists.

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

  Conciseness5/5

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

  One short sentence, front-loaded with verb and resource, with no filler. It efficiently packs the distinguishing 'one' and both identifying criteria.

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

  Completeness4/5

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

  For a simple read-only lookup with two required string parameters, the description is largely sufficient. It lacks return-value details, but no output schema is provided and the operation is straightforward.

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

  Parameters4/5

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

  Schema descriptions are absent, so 'by SKU and site nickname' is the only semantic explanation. It clarifies that 'site' means site nickname and 'sku' is the product key, adding value beyond bare string property names.

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

  Purpose5/5

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

  States a clear verb ('Get'), resource ('product'), and retrieval key ('SKU and site nickname'). The word 'one' distinguishes it from list_products, while the resource differentiates it from order, ticket, and analytics siblings.

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

  Usage Guidelines3/5

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

  No explicit when-to-use or alternative routing is given. The singular 'one product' implies it is for fetching a specific product by known identifiers, but it does not mention list_products or when not to use this tool.

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

• get_ticketA
  4/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the 'by ID' retrieval behavior, which is minimal but not misleading or contradictory.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence: 'Get one ticket by ID.' It conveys the essential operation with no filler or redundant wording.

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

  Completeness4/5

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

  For a simple read-only fetch-by-ID tool with one parameter and existing annotations, the description is largely complete. It does not describe the return shape, but the tool name and 'get ticket' semantics make the general outcome clear.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the id parameter is documented as 'Ticket ID.' The description's 'by ID' phrase adds no new semantic detail beyond what the schema already provides, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb ('Get'), a specific resource ('one ticket'), and the access pattern ('by ID'). This clearly differentiates it from sibling tools like list_tickets and count_tickets, which operate over multiple tickets.

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

  Usage Guidelines4/5

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

  The description provides clear context: use this tool when you need a single ticket identified by its ID. It does not explicitly mention alternatives, but the 'one ticket by ID' phrasing makes the intended use obvious and naturally distinguishes it from list or count operations.

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

• list_productsA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds site scoping and filter behavior, but it does not mention pagination, result limits, or whether the list can be considered exhaustive, so operational behavior remains partially unspecified.

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

  Conciseness5/5

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

  Two short sentences with no filler. The primary scope is stated first, and the optional filter is stated second; every part of the description earns its place.

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

  Completeness4/5

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

  For a low-complexity, read-only list operation with one required and one optional parameter, the description provides the necessary invocation context. A small gap is the lack of any note about return shape or pagination, especially since no output schema is provided.

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

  Parameters4/5

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

  Schema description coverage is 50%: 'site' is already described, while 'type' has no description. The description compensates by framing 'type' as an optional STANDARD/RECURRING filter, giving the agent useful meaning beyond the raw enum names.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'List products' for a 'site nickname', and adds the optional STANDARD/RECURRING filter. This is enough for an agent to distinguish it from siblings like get_product or list_orders without needing to inspect schemas.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool: when you want products owned by a site, optionally narrowed by product type. However, it names no alternatives and gives no explicit 'when not to use' guidance, leaving the choice among sibling tools to inference.

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

• check_order_activeA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint, so the bar for additional disclosure is lower. The description adds meaningful behavioral details beyond annotations: it explains the value mapping (active=true/false) and the 403 response semantics, including the case where the receipt is missing or inaccessible.

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

  Conciseness5/5

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

  The description is two sentences with no filler. It front-loads the core purpose and status conditions in the first sentence, then clarifies error mapping in the second, making every word useful.

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

  Completeness5/5

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

  For a single-parameter, read-only tool with no output schema and annotations covering safety, the description fully covers what an agent needs: the exact boolean semantics, the statuses that determine falseness, and the HTTP 403 behavior. No critical calling information is missing.

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

  Parameters3/5

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

  The schema fully describes the only parameter (receipt) as a ClickBank receipt ID, so schema coverage is 100%. The description does not add additional meaning to the parameter itself beyond confirming it receives a receipt, meeting the baseline but not exceeding it.

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

  Purpose5/5

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

  The description clearly states the tool's function: it checks whether an order is active by evaluating refund, chargeback, and cancellation status. It distinguishes itself from sibling tools like get_order and list_orders by focusing specifically on the active/inactive boolean outcome rather than order details or lists.

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

  Usage Guidelines3/5

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

  The description implies use for a quick status check via HEAD, but it does not explicitly state when to use this over alternatives like get_order or when not to use it. There are no exclusions or alternative tool references, leaving usage context to inference.

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

• list_clickbank_accountsA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the access-scope detail ('current API key can read'), which is useful. It does not describe output format or ordering, but for a zero-parameter list tool this is a minor gap.

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

  Conciseness5/5

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

  A single front-loaded sentence with no wasted words. It conveys the action, the resource, and the permission scope efficiently.

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

  Completeness5/5

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

  For a zero-parameter, read-only list tool with annotations covering behavior, the description is complete. An agent knows what to call it for and what it will get back: account nicknames accessible to the current API key.

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

  Parameters4/5

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

  The input schema has zero parameters, so there is nothing for the description to clarify. Baseline 4 is appropriate for a parameterless tool; the description accurately states what will be returned.

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

  Purpose5/5

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

  The description uses a specific verb ('List') with a clear resource ('account nicknames') and an explicit scope ('the current API key can read'). This distinguishes it from siblings that target orders, products, tickets, and analytics.

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

  Usage Guidelines4/5

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

  The phrase 'the current API key can read' provides clear context for when this tool applies: when the agent needs account nicknames accessible to the authenticated API key. It does not explicitly name alternatives, but no sibling tool appears to serve this same purpose.

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