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

Annotations indicate a write operation with potential side effects. The description adds the auth detail but does not explain activation effects (e.g., instance creation, idempotency).

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 extraneous content. Front-loaded with the core action and auth note.

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?

No output schema or return behavior described. For a mutation tool, more context on success/failure or side effects would improve completeness, but it's adequate for a simple activation.

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

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

Schema covers both parameters with descriptions. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the verb (activate) and resource (license key for an instance). It distinguishes from siblings like 'deactivate' and 'validate'.

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?

States that no API key is needed, which clarifies a key usage context. Does not explicitly exclude alternatives but the sibling list provides implicit differentiation.

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

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

Adds that status is set to 'archived' and is reversible, providing some behavioral context beyond annotations. However, lacks details on side effects (e.g., on licenses, subscriptions) and permissions required.

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 concise sentences, front-loaded with the main action and effect. No unnecessary 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?

Adequate for a simple tool with one parameter and no output schema. Mentions reversibility, but could note typical response or related implications (e.g., if customer has active subscriptions).

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 already describes the single parameter with 100% coverage. Description adds no new 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?

Description clearly states the action (archive), resource (customer), and effect (sets status to archived). It distinguishes from siblings like ls_update_customer by specifying the specific operation.

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?

Implies usage when customer should be archived, but no explicit alternatives or when-not-to-use guidance. Mentions reversibility but does not contrast with related tools like ls_deactivate_license.

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

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

Annotations already provide destructiveHint, idempotentHint, and openWorldHint. The description adds that the subscription remains active until period end, which is valuable behavioral context not in annotations. However, it does not disclose potential side effects (open-world) explicitly.

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

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

Two sentences, front-loaded with the main purpose, and a complementary detail. 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 cancellation tool with one parameter, the description covers the key behavioral effect (deferred expiration). Although no output schema, the description is sufficient given annotations.

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

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

Schema coverage is 100% with a clear description for subscriptionId. The tool description adds no extra meaning beyond the schema, so baseline of 3 is appropriate.

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

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

The description clearly states the action (cancel) and the resource (subscription), and adds specific behavior (remains active until end of billing period then expires), distinguishing it from other subscription modification tools like ls_deactivate_license or ls_update_subscription.

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

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

The description implies usage for canceling a subscription with deferred expiration but does not explicitly state when to use this tool over siblings (e.g., for immediate cancellation vs. end-of-period). No exclusions or alternatives mentioned.

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

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

Annotations already establish this is a mutation (readOnlyHint=false) and not idempotent. The description adds that it returns a URL and that it supports custom pricing, prefill, and customization, but it does not disclose side effects, auth requirements, or behavior around expiry/payment. This is acceptable but not rich.

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

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

Three short sentences with the core action front-loaded. There is minor redundancy ('Create a new checkout URL' vs 'Returns a URL...') but no filler or irrelevant detail.

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 12 parameters, a required storeId/variantId pair, and no output schema, the description gives a useful high-level summary but omits the exact response shape and any edge-case behavior. The schema covers parameter details, but the tool's output contract is only described as 'a URL'.

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 every parameter is individually documented. The description's mention of 'custom pricing, prefilled customer data, and checkout customization' only groups existing schema capabilities without adding new meaning beyond the schema. 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 opens with a specific verb and resource: 'Create a new checkout URL for a product variant,' and immediately clarifies the output (the purchase URL). This clearly distinguishes the tool from sibling read tools like ls_get_checkout and ls_list_checkouts.

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 use case is clear: you use this when you need to generate a checkout URL for a variant. However, the description never explicitly names alternatives or states when not to use the tool; the distinction from siblings is implied by the create verb rather than stated.

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

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

The description adds no behavioral detail beyond what the annotations already convey. Annotations indicate readOnlyHint=false (write), idempotentHint=false (non-idempotent), and destructiveHint=false, but the description does not mention side effects, failure conditions (e.g., duplicate email), or whether it returns the created object. It adds no additional transparency beyond the annotation profile.

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 core purpose. There is no redundant or filler content, and every word serves the clarity of the operation. It is appropriately minimal for a simple creation 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?

The tool has no output schema, and the description does not explain what the tool returns (e.g., the created customer object or an error). While the schema lists required parameters, the description does not mention them. For a straightforward creation action, the description is minimally adequate but lacks information about the response and potential failure modes, leaving the agent to infer behavior.

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 all parameters already have descriptions. The tool description itself adds no parameter-specific context (e.g., why storeId is required or what values are valid). Since the schema fully documents parameters, the baseline of 3 is appropriate; the description does not compensate further.

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

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

The description clearly states the verb ('Create'), the resource ('a new customer'), and the context ('in a store'), which unambiguously distinguishes it from sibling tools like ls_get_customer, ls_update_customer, and ls_archive_customer. The purpose is immediately clear and specific.

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 the tool is for adding new customers, but it does not explicitly state when to use it versus alternatives (e.g., 'use ls_update_customer for modifications'). No exclusions or alternative recommendations are provided, so the guidance is only implied by the tool's name and purpose.

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?

Description matches annotations (non-readonly, non-destructive). No additional behavioral context beyond 'create' is provided, which is adequate but not enhanced.

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?

Single sentence, no unnecessary words. Efficient and front-loaded.

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 12 parameters and no output schema, the description lacks details on return values, error conditions, or constraints (e.g., uniqueness of code). Could be more 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?

Schema description coverage is 100%, so the description adds no extra value beyond the schema. Parameters are well-documented in the schema itself.

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?

Description clearly states the action (create) and resource (discount code), and mentions supported discount types. However, it does not distinguish from sibling tools like ls_delete_discount or ls_get_discount.

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

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

No explicit guidance on when to use this tool vs alternatives. The sibling list includes many discount-related tools, but the description does not provide context for selection.

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

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

Annotations already indicate destructiveHint=true, so the description adds minimal behavioral context beyond restating the action semantics already present in the input schema. It does not disclose side effects, error behavior, authorization requirements, or concurrency considerations. The description repeats what the schema enum descriptions already convey.

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

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

The description is two sentences long, front-loaded with the primary purpose, and wastes no words. Every sentence provides necessary context (the resource and the two modes of operation). It is concise yet complete for its length.

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

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

Given the tool has 3 parameters, no output schema, and annotations that mark it as destructive, the description adequately covers the primary purpose and action choices. However, it does not describe the response format or success behavior, which is important since there is no output schema to guide the agent. It also omits any mention of prerequisites like requiring a valid subscription item or authentication.

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%, meaning all parameters have descriptions in the schema. The description adds no additional meaning beyond restating the 'increment' and 'set' actions, which are already documented in the action parameter's description. Therefore, it meets the baseline for full schema coverage without extra semantic value.

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

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

The description clearly states the purpose: 'Report usage for a metered subscription item,' which defines the verb (report/create) and resource (usage record). It distinguishes the two possible actions, 'increment' and 'set,' which aligns with the sibling tools like ls_get_usage_record and ls_list_usage_records that are read-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 provides implicit guidance on when to use the tool (for metered subscription usage reporting) and explains the two actions, but it does not explicitly state when to use this tool versus alternatives such as ls_get_usage_record or ls_list_usage_records. No exclusion criteria or prerequisites are mentioned.

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

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

Beyond annotations (which indicate this is a write operation, not destructive, not idempotent), the description reveals a critical behavioral trait: 'The signing secret is returned only once — save it immediately.' This adds value by warning the agent about a one-time return, which is not evident from annotations alone.

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

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

The description consists of two short sentences, each earning its place: the first states the purpose, the second adds the crucial warning. No unnecessary words or repetition.

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

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

Given the tool's simplicity (4 required params, no output schema), the description covers the core purpose and a key behavioral detail. However, it does not describe the response format or what happens after creation (e.g., webhook starts sending events). This slight gap prevents a 5.

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 100% description coverage, so the schema already explains each parameter (storeId, url, events, secret). The description does not add additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states 'Create a new webhook to receive event notifications,' which is a specific verb+resource combination. It distinguishes itself from sibling tools like ls_get_webhook, ls_update_webhook, and ls_delete_webhook by focusing on creation.

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

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

The description does not explicitly state when to use this tool versus alternatives like ls_get_webhook or ls_list_webhooks. However, the tool name and description imply it is for initial setup, and the warning about the signing secret provides usage context.

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

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

Annotations already mark destructiveHint and readOnlyHint, but the description adds meaningful behavioral detail beyond them: the operation is rate-limited, audited, and masks the license key in audit entries. This is exactly the kind of contextual disclosure that helps an agent anticipate consequences.

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 tight sentences: action and effect, destructive consequences, and auth requirement. Every sentence adds non-redundant information, and the most important scoping facts are front-loaded.

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

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

For a two-parameter destructive action with annotations covering idempotency and destructiveness, this description is complete. It covers purpose, effect, consequences, rate-limiting, auditing, masking, and authentication. Nothing critical is missing for an agent to select and invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value by explaining that the licenseKey parameter is not just an identifier but also the authentication credential for this call. That is helpful detail beyond the schema's bare 'The license key'.

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 ('Deactivate') with a precise resource ('a license key instance') and states the observable effect ('revoking that instance's access'). This clearly distinguishes it from siblings like ls_activate_license and ls_validate_license without needing to open 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 gives clear context for when the tool is appropriate: to revoke access for a specific license instance. It also adds a practical auth signal ('Does not require an API key — uses the license key itself for auth'). It stops short of explicitly naming alternatives or exclusions, so it misses the full 5.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds 'Permanently delete' and 'irreversible,' which reinforce the destructive nature but do not provide substantial new behavioral information beyond the annotations.

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

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

Two concise sentences with no filler. Every word adds value, stating action and irreversibility.

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

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

Given the simple one-parameter tool and rich annotations, the description is adequate. Could mention that the discount must exist or error handling, but not strictly necessary.

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 100% coverage for the single parameter discountId, with a clear description. The tool description does not add any further semantic context for the parameter.

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

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

The description clearly states the verb 'delete' and the resource 'discount', and explicitly notes it's permanent and irreversible. It distinguishes from sibling tools like ls_create_discount or ls_get_discount.

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 (e.g., soft deletion or archiving). No mention of prerequisites or contextual triggers.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds 'This is irreversible', reinforcing the destructive nature, but does not disclose potential side effects or prerequisites, such as whether the webhook must be inactive.

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

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

The description is extremely concise with two sentences, directly stating the action and irreversibility. Every word is purposeful, and the critical information is front-loaded.

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 delete operation with one required parameter, the description is complete. It conveys the action, permanent nature, and no output schema is needed. The simplicity of the tool does not demand more context.

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

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

The input schema provides 100% coverage with a clear description for the only parameter 'webhookId'. The tool's description adds no additional parameter information beyond what the schema already provides, resulting in a baseline score of 3.

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

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

The description clearly states the verb 'delete' and the resource 'webhook', and emphasizes irreversibility. It effectively distinguishes from sibling tools like ls_create_webhook, ls_update_webhook, and ls_get_webhook by specifying a permanent deletion action.

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

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

No explicit guidance on when to use this tool versus alternatives. While the context of deleting is implied, the description does not provide conditions or contrast with other tools like ls_update_webhook for deactivating a webhook.

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

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

The idempotentHint annotation already indicates safe repeated calls, but the description adds little beyond that. It does not disclose behavior on errors, existing invoices, or the download URL format. However, it does not contradict annotations.

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

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

The description is a single sentence that efficiently conveys the core function and output. Every word is necessary and front-loaded.

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

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

Given 9 optional parameters and no output schema, the description is too brief. It does not explain how the optional parameters affect the invoice or what the download URL looks like, leaving gaps for a complex 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 description coverage is 100% with basic descriptions for each parameter. The tool description does not add extra meaning or usage guidance beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the action ('Generate a PDF invoice') and the resource ('for an order'), and specifies the output ('Returns a download URL'). This distinguishes it from sibling tools like ls_generate_subscription_invoice.

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

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

No guidance is provided on when to use this tool versus alternatives, such as ls_generate_subscription_invoice or other order-related tools. The description lacks context about prerequisites or typical scenarios.

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

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

Annotations indicate idempotentHint=true, so the tool is safe to retry. The description does not elaborate on side effects (e.g., whether it creates a record) or the nature of the download URL. It adds minimal context beyond the annotations.

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

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

The description is a single sentence that directly states the purpose and output. It is appropriately concise and front-loaded with essential information.

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 9 parameters and no output schema, the description is minimal. It covers the core functionality but omits details like prerequisites (e.g., invoice existence state), error handling, or URL expiration. This is adequate but not comprehensive.

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

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

Schema descriptions cover all 9 parameters (100% coverage), so parameters are already well-documented. The description adds no additional meaning to parameters beyond what the schema provides.

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 generates a PDF invoice for a subscription invoice and returns a download URL. The verb 'generate' and resource 'subscription invoice' are specific, and the name distinguishes it from sibling tools like ls_generate_order_invoice.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., ls_get_subscription_invoice for retrieving invoice data). There is no mention of prerequisites or cases where this tool is inappropriate.

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

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

Annotations indicate read-only and idempotent behavior. The description adds minimal transparency beyond confirming it is a retrieval operation; it does not mention side effects, auth requirements, or rate limits, but the annotations already cover the safety profile.

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 immediately states the action and resource, with no unnecessary 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 read tool with high schema coverage, the description covers the key purpose and output fields. It could mention the return format or structure, but it is largely sufficient 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 description coverage is 100% with clear parameter descriptions. The tool description does not add additional meaning beyond what is already in the schema, so it performs at the baseline for high coverage.

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

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

The description clearly states 'Get a specific affiliate by ID, including commission rate, status, and earnings.' It provides a specific verb (get), resource (affiliate), and distinguishes itself from the sibling tool 'ls_list_affiliates' by focusing on a single affiliate retrieval.

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

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

The description implies usage when an affiliate ID is available, but it does not explicitly state when to use this tool versus alternatives like ls_list_affiliates, nor does it provide any usage exclusions or prerequisites.

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

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

Annotations already communicate readOnly, idempotent, and non-destructive behavior. The description adds value by indicating the response will include URL, expiry, and custom data, but it does not discuss errors, authorization, or edge cases.

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, compact sentence that front-loads the core behavior and then highlights the most useful returned fields. There is no filler or redundant restatement.

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

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

For a simple read operation with one required parameter and strong annotations, this is nearly complete. It identifies the input, the core return contents, and the read-only nature, though it could briefly mention related-resource inclusion via the optional `include` parameter.

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

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

Schema coverage is 100%, so both checkoutId and include are already documented in the schema. The description mentions payload fields but does not add meaningful parameter-level guidance beyond what the schema provides.

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 ('Get a specific checkout by ID') and names key returned content ('URL, expiry, and custom data'). It is clearly distinguished from listing checkouts by stressing 'specific' and 'by ID'.

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 intended use is implied: call this when you already have a checkout ID and need one checkout. However, it does not explicitly name ls_list_checkouts as the alternative for fetching multiple checkouts, nor does it state any 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds the set of returned fields but no additional behavioral context (e.g., auth needs, rate limits, error scenarios).

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?

Single sentence, 19 words, front-loaded with the core action and resource. Every word is informative, no fluff.

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

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

Given 100% schema coverage, annotations, and no output schema, the description lists returned fields helpfully. Could mention error handling or response format, but adequate for a simple retrieval 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 descriptions for both parameters. The description does not add extra meaning beyond the schema; it lists output fields, not parameter details. Baseline 3 as schema carries the load.

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?

Description clearly states the verb 'Get' and resource 'specific customer by ID', listing specific fields returned. It distinguishes from siblings like ls_list_customers (list) and ls_create_customer (create).

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?

Implied usage for retrieving a single customer by ID, but no explicit guidance on when to use vs alternatives like ls_list_customers or when not to use. No exclusions or prerequisites mentioned.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds return fields but no further behavioral details (e.g., error handling). No contradiction.

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

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

Single sentence, 15 words, directly states action and result. No unnecessary 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?

Covers essential return fields for a single-ID retrieval. No output schema, but description compensates. Lacks response structure or error details.

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 good descriptions for both parameters. Description does not add extra meaning beyond 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?

Description clearly states it gets a discount by ID and lists specific fields (code, amount, type, usage limits). Distinguishes from sibling tools like ls_list_discounts and ls_get_discount_redemption.

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?

Implied usage for retrieving a single discount, but no explicit when-to-use or alternatives. Missing guidance on the 'include' parameter context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, safe operation. Description adds minimal context (showing when and where), but does not contradict annotations. No additional behavioral traits 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.

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

Description is a single, clear sentence that is front-loaded with the verb. It is concise but could be slightly more informative without adding verbosity.

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?

Description is adequate for a simple get operation, but it does not differentiate from the sibling ls_list_discount_redemptions tool or describe the response structure (no output schema). Could be more complete with usage context.

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

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

Schema coverage is 100% and already includes descriptions for both parameters. The description does not add any new semantic information beyond what the schema provides. Baseline score of 3 is appropriate.

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

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

Description clearly states it retrieves a specific discount redemption by ID, which is a specific verb+resource. It distinguishes from sibling tools like ls_list_discount_redemptions (which returns a list) and other get_* tools.

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

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

The description does not explicitly state when to use this tool versus alternatives. The name implies its use for a single redemption by ID, but no guidance on when to use ls_list_discount_redemptions or other related tools is provided.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds what data is returned (name, size, download URL, variant), providing useful behavioral context 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.

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

Single sentence, zero waste, front-loaded with verb and resource. Efficient and clear.

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

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

For a simple get operation with one required parameter and no output schema, the description fully explains what the tool does and what it returns, making it 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?

Schema covers both parameters with descriptions (100% coverage). Description mentions variant, which relates to the 'include' parameter, but adds minimal additional meaning beyond 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?

Description clearly states 'Get a specific file by ID' and lists exact data returned (name, size, download URL, variant). Distinguishes from sibling 'ls_list_files' by focusing on a single file retrieval.

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 when-to-use or when-not-to-use guidance. However, the description implies usage for fetching a specific file by ID, which is clear from context among many 'get_' siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, covering safety and idempotency. The description adds the specific fields returned but no additional behavioral context beyond that.

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 focused sentence with no unnecessary words, directly stating the action and output scope.

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

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

Given the absence of an output schema, the description helpfully lists included fields. However, it omits details on error handling or output format, but overall is sufficient for a simple retrieval tool with comprehensive annotations.

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

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

Both parameters have schema descriptions (coverage 100%), and the description adds no extra semantic value beyond listing output fields, which does not enhance parameter understanding.

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 it retrieves a specific license key by ID and lists the fields returned (key value, status, activation limit, expiry date), differentiating it from sibling tools like ls_list_license_keys which list multiple keys.

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

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

The description implies usage for single license key retrieval but does not explicitly contrast it with alternatives like ls_validate_license or ls_list_license_keys, nor provides when-not-to-use 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds that it returns instance name and creation date, but does not disclose additional behavioral traits beyond what annotations provide. No contradiction with annotations.

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

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

The description is a single, well-structured sentence that front-loads the main action. Every word adds value, with no redundancy or unnecessary information.

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 by ID operation, the description is fairly complete. It specifies the return fields (instance name and creation date). Annotations cover safety aspects. It could mention that the response includes additional fields, but the phrase 'including' implies there is more.

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%, with clear descriptions for both parameters (licenseKeyInstanceId and include). The tool description does not add any meaning beyond the schema; it only mentions the ID implicitly. Baseline score 3 is appropriate.

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

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

The description clearly states the action (Get), the resource (specific license key instance), and what is returned (instance name and creation date). It distinguishes from sibling tools like ls_list_license_key_instances which lists all instances.

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

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

The description implies usage when you have a specific license key instance ID, but it does not explicitly guide when to use this tool over siblings like ls_list_license_key_instances or ls_get_license_key. No exclusions or alternatives mentioned.

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

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

Annotations already mark it as read-only, idempotent, and non-destructive. The description adds value by specifying the returned fields (status, total, currency, customer info, payment details), which is not present in annotations or input 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?

The description is a single sentence that directly conveys the tool's purpose and return fields. It is concise and front-loaded with key information, with no superfluous content.

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

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

Given the simplicity of a read operation and the presence of annotations, the description is fairly complete. It lists expected outputs, compensating for the lack of an output schema. Minor gaps exist regarding error handling and parameter usage details, but not critical.

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 100% description coverage for both parameters. The description does not add significant meaning beyond the schema, merely restating 'by ID' which aligns with the orderId parameter. Baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves a specific order by ID and lists the included information (status, total, currency, customer info, payment details). It is unambiguous and distinguishes from sibling tools like ls_list_orders.

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 that this tool is for fetching a single order by ID, but it does not explicitly state when to use it over alternatives like ls_list_orders or other get tools. No exclusions or context are provided.

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

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

Annotations already mark this as read-only, non-destructive, idempotent, and open-world. The description adds no behavioral traits beyond those, but does not contradict them.

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?

Single sentence, 16 words, front-loaded with action verb and resource. 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 get operation, description covers purpose and core return fields. Lacks details on include parameter, error handling, or full return shape, but adequate given schema coverage and annotations.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds meaning by listing returned fields, but does not explain the optional 'include' parameter, so value is marginal.

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 a specific order item by ID, listing included fields (product name, variant, price, quantity). It effectively distinguishes from sibling ls_list_order_items which returns multiple items.

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 does not explicitly state when to use or avoid this tool, nor mention alternatives. Usage is implied from the verb 'get' and context, but lacks explicit 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?

Annotations already state read-only/idempotent/non-destructive, so the burden is lower, but the description adds a crucial behavioral disclosure: `unit_price` is misleading on tiered schemes and should be ignored, while `effective_unit_price` is the actual charged amount. It explicitly warns 'READ THAT, not `unit_price`' and separates behavior for tiered vs package pricing. This tells the agent how to correctly interpret the response data beyond what any annotation could convey.

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

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

The description is long but every sentence contributes: it states purpose, then gives a concrete reading directive with detailed rationale for two pricing schemes. It is front-loaded with the core purpose before the caveats, and the structure flows logically from general instruction to specific fallback cases.

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

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

For a two-parameter get-by-ID tool with a complete schema and read-only annotations, the description fully covers the domain-specific hazards of tiered and package pricing. It does not discuss error responses or include parameter options, but those are either standard expectations or covered by the schema. The description is more than sufficient for correct invocation and interpretation.

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%, with both `priceId` and `include` already described in the schema. The description does not add parameter-level meaning (it does not explain include options or constraints), so it does not exceed the baseline set by the high schema coverage.

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

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

The description opens with a clear verb-resource statement: 'Get a specific price by ID, including amount, currency, and billing interval.' This distinguishes it from siblings like ls_list_prices (which lists) and ls_get_product (different resource). The mention of specific returned fields leaves no ambiguity about what the tool does.

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 the tool fetches a single price 'by ID', making it obvious that this is the right choice when you already have a price ID and need full details. It does not explicitly name alternatives or exclusions, but the ID-based scope of the purpose is clear enough for an agent to choose it over list/scan tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering behavioral safety. The description adds the list of returned fields but does not provide additional behavioral context 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.

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

The description is a single sentence of 12 words with no wasted content. It is extremely concise and front-loaded with the essential information.

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

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

Given the tool's simplicity (single resource retrieval, no output schema), the description provides sufficient context including the fields returned. Annotations cover safety and idempotency, making it complete for the agent.

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 descriptions for both parameters. The description does not add any additional meaning beyond what is already in the input schema, so baseline 3 is appropriate.

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

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

The description clearly states the action 'Get' and the resource 'product by ID', and specifies returned fields (name, description, price, status). It distinguishes from sibling list tools by implying a single resource retrieval.

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

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

The description implies usage for retrieving a specific product's details but does not explicitly contrast with sibling list tools or provide when-not-to-use guidance. The context is clear but lacks 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context about the returned fields (name, slug, currency, sales statistics), providing value beyond annotations. No behavioral contradictions.

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

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

The description is a single, well-structured sentence that front-loads the action and resource, with no unnecessary words. Every part contributes to understanding.

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

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

For a simple get-by-id tool, the description is adequate. It covers the purpose and key output fields. No output schema exists, but the description compensates by listing returned data. The 'include' parameter is covered in the schema, so no major gaps.

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

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

Schema coverage is 100% with descriptions for both parameters. The description does not add extra meaning beyond the schema, so a baseline score of 3 is appropriate. It mentions output fields but not parameter specifics.

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

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

The description clearly states the verb (Get), the resource (store), and specifies that it returns name, slug, currency, and sales statistics. It distinguishes from sibling tools like ls_list_stores by focusing on a single store retrieval via ID.

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

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

The description implies usage for fetching a single store by ID, which is distinct from listing all stores. However, it does not explicitly mention when not to use it or provide alternatives, but the context is clear given the tool's name and description.

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

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by listing the specific data fields returned (status, billing interval, renewal date, customer info). No side effects or limitations are mentioned, but the annotations cover the safety profile adequately.

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, well-structured sentence that immediately conveys the tool's purpose. Every word adds value, and there is no unnecessary information. The description is appropriately sized and front-loaded.

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

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

For a simple read-only retrieval tool, the description is largely complete. It lists the key fields returned. There is no output schema, so the description compensates reasonably. It could mention error handling or rate limits, but given the annotations, this is acceptable.

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 does not add new information about the parameters beyond what the schema already provides. The mention of 'by ID' aligns with the subscriptionId parameter but does not enhance understanding of the 'include' parameter.

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

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

The description clearly states the verb 'Get' and the resource 'subscription by ID', and includes the specific data fields returned. It distinguishes itself from sibling tools like 'ls_list_subscriptions' by specifying a single subscription retrieval via ID.

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 that the tool is used when you have a subscription ID, but it does not explicitly provide when-to-use or when-not-to-use guidance compared to alternatives (e.g., using 'ls_list_subscriptions' for multiple subscriptions). No exclusions or alternatives are mentioned.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds context on the specific fields returned, enhancing transparency without contradiction.

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

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

The description is a single, well-structured sentence. It front-loads the verb and resource, then lists key fields. No unnecessary words.

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

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

Given the simplicity (2 params, no output schema), the description adequately indicates return contents. Missing error handling mention, but acceptable for a basic retrieval 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 parameter descriptions. The description does not add significant new meaning beyond what the schema provides; it mentions output fields but not parameter details.

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

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

The description clearly states the verb 'Get', the resource 'specific subscription invoice', and enumerates included fields (status, total, billing reason, payment details). It effectively distinguishes from list and mutation tools.

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

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

The description implies retrieval of a single invoice by ID, which contrasts with list operations. However, it does not explicitly state when to use this vs. alternatives like ls_list_subscription_invoices or ls_refund_subscription_invoice.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds critical behavioral context beyond annotations: the price record's effective_unit_price is the actual charge per unit, whereas unit_price is vestigial or per-package depending on pricing model. This insight directly affects how the agent interprets data, adding value beyond the structured hints.

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 the main purpose first and the include caveat second. Though the second sentence is dense, every clause serves a distinct purpose (what include=price returns, the field to read, why unit_price is unreliable). No fluff; it could be slightly more organized but remains 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 get-by-id tool with no output schema, the description is thorough: it tells the agent what to expect (quantity, pricing, subscription), how to retrieve the price record, and what to trust in the response. Given only two parameters and no complex nested structures, it covers all essential calling knowledge. Error scenarios are not described, but that is acceptable for a simple read operation.

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

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

Schema coverage is 100% for both parameters, but the description adds semantic depth: it explains the special include=price value and its effect on the response. The subscriptionItemId is straightforward, but the description's treatment of include goes beyond the generic schema description ('Comma-separated related resources') by identifying a specific useful inclusion and its output nuance.

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?

Clear verb 'Get' with specific resource 'subscription item' and explicit scope ('by ID'). Distinct from ls_list_subscription_items by the singular 'specific' phrasing. Also specifies what is included (quantity, pricing, associated subscription) and the price-record behavior.

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 concrete usage guidance for the include parameter ('pass include=price') and explains which field to read (effective_unit_price vs unit_price). While it doesn't explicitly say 'use this instead of ls_list_subscription_items', the 'specific... by ID' phrasing implies the singular use case. No exclusions are given, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description merely restates the read-only nature ('Get current usage'). No additional behavioral context (e.g., error handling, pagination, rate limits) is added beyond the annotations.

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

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

The description is a single sentence that is concise and front-loaded with the key action and resource. No redundant information is present.

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

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

Given the tool's simplicity (one read-only parameter), the description adequately covers purpose and scope. It does not document the return value, but the absence of an output schema is not critical for a straightforward usage check. Slightly more context (e.g., what the response contains) would improve completeness.

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 is only one parameter, subscriptionItemId, which is described in the schema as 'The subscription item ID'. The description does not add any extra meaning or context for the parameter. Since schema coverage is 100%, a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Get', the resource 'current usage for a metered subscription item', and the scope 'within the current billing period'. This distinguishes it from sibling tools like ls_get_subscription_item (which likely retrieves item details) and ls_get_usage_record (which might fetch a specific usage record).

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 the tool is for checking current metered usage, but it does not explicitly state when to use this versus alternatives like ls_get_usage_record or ls_list_usage_records. No guidance on prerequisites or when not to use is provided.

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

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

Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds 'including quantity and action type' but does not disclose error behavior, permissions, or rate limits. With annotations covering safety, 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?

Single sentence, front-loaded with key information, no redundant words. Every element 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 simple read operation with two parameters and no output schema, the description covers the essential purpose and scope. It could mention the 'include' parameter's effect, but schema already explains it.

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

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

Schema coverage is 100% with both parameters described. The description adds no new parameter-level meaning beyond confirming 'by ID' for usageRecordId, which is already in the schema.

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

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

The description clearly states the action (get), resource (usage record), and scope (by ID), with specifics (including quantity and action type) that distinguish it from sibling tools like ls_list_usage_records.

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

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

The description implies usage for retrieving a single record by ID but provides no explicit guidance on when to use this tool versus alternatives like ls_list_usage_records or ls_create_usage_record.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it returns user info including name, email, avatar, which is consistent. No additional behavioral traits beyond annotations are disclosed.

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

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

The description is a single clear sentence that is front-loaded and concise. Every word is meaningful with no 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?

Given no output schema, the description provides a decent overview of the return content. However, it lacks details on response format or edge cases. For a simple read operation, this is mostly 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 no parameters, and the schema coverage is 100%. The description adds value by listing the returned fields, which helps the agent understand what to expect. Baseline for zero 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 action ('Get'), the resource ('the authenticated user's information'), and specifies example fields ('name, email, and avatar'). It distinguishes from sibling tools like ls_get_customer which retrieves a specific customer rather than the current user.

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 use for getting the current user's information, but does not explicitly state when to use this tool versus alternatives such as ls_get_customer or ls_get_store. No exclusions or context for alternatives are provided.

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

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

Annotations already mark the tool read-only, idempotent, and non-destructive, so the description's added warning about the vestigial `price` field is valuable behavioral disclosure beyond the structured data. It also reveals that the response includes billing interval and trial settings, and gives a step-by-step alternative for the true price. There is no contradiction with the annotations.

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

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

The description is three sentences: one for purpose, two for the critical pricing warning. The warning is front-loaded and essential to safe use of the tool, and no sentence is filler. It is compact given the complexity of the caveat.

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-by-ID tool with no output schema, the description covers the most important trap (the misleading `price` field) and directs the agent to the correct price source. The `include` parameter is documented in the schema, and the read-only safety profile is in annotations, so an agent has everything needed 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 input schema already provides 100% parameter descriptions: variantId as 'The variant ID' and include as 'Comma-separated related resources.' The description doesn't add new parameter semantics beyond using variantId in its warning, so it stays at the baseline for high schema coverage.

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

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

The description opens with 'Get a specific product variant by ID,' a specific verb and resource, and adds the detail that billing interval and trial settings are included. This clearly distinguishes it from listing tools like ls_list_variants and from product-level tools like ls_get_product. The purpose is 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 does not explicitly frame when to use this tool versus alternatives, but it provides a clear directive: do not trust the `price` field and instead call `ls_list_prices` with this variantId to retrieve the authoritative price. This is practical guidance for when the agent needs pricing information, though it doesn't spell out exclusions such as 'use ls_list_variants for a list.' Overall the context is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the output fields (URL, events, last sent timestamp), giving the agent concrete expectations of the response content.

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?

Single sentence of 12 words, front-loaded with the action and key output details. No extraneous information.

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 getter with two parameters and no output schema, the description adequately covers purpose and output fields. It could mention that additional fields may exist, but given the simplicity, it is sufficiently 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?

Schema description coverage is 100% (both parameters documented). The tool description does not add extra meaning beyond the schema. Per guidelines, baseline is 3 when high coverage.

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

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

The description clearly states 'Get a specific webhook by ID,' identifying the verb and resource. It also specifies the returned fields (URL, events, last sent timestamp), which distinguishes it from list or update tools.

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

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

The description implicitly indicates use when a single webhook's details are needed. However, it does not explicitly specify when not to use or alternative tools like ls_list_webhooks for bulk retrieval. The context is clear but lacks direct 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?

Exceeds annotations by disclosing pagination structure (meta.page currentPage, lastPage, total), the absence of storeId scoping, and that results are bound to API key visibility. These are critical behavioral traits not covered by readOnlyHint, openWorldHint, idempotentHint, or destructiveHint. No contradiction with annotations.

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

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

Three dense sentences, front-loaded with the core purpose, then pagination, then the critical cross-store caveat. Every sentence adds distinct value; the caveat is lengthy but essential due to the tool's non-obvious scoping behavior. No filler.

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

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

For a list tool with no output schema, the description covers essential invocation details: scope, optional email filter, pagination response format, and a significant behavioral gotcha. Nothing an agent needs to call the tool correctly is missing.

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 already documents all four parameters with 100% coverage, so baseline is 3. The description only restates the userEmail filter and pagination behavior, adding no new parameter-level meaning beyond what the schema provides.

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

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

States a specific verb and resource ('List all affiliates') with clear scope ('for the authenticated user's stores') and optional filter ('by user email'). The description is clearly distinct from sibling ls_get_affiliate (singular vs. list) and other list tools, and the pagination note reinforces its list 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?

Provides explicit usage context: when to use the tool (list all affiliates, optionally filtered by email) and a when-not warning that LEMONSQUEEZY_ALLOWED_STORE_IDS does not gate this tool, recommending a scoped API key for true store enforcement. This acts as a clear exclusion and guidance for correct usage, even without naming an alternative sibling.

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?

Description adds valuable behavioral context beyond annotations by explaining pagination behavior and response structure (meta.page), which aids in result handling.

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

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

Two concise sentences, front-loaded with purpose and filters, immediately followed by pagination details. No redundant information.

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?

Description adequately covers purpose, filters, and pagination for a list tool. Annotations handle safety/prerequisites, and schema documents parameters fully.

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

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

Schema covers all 5 parameters with full descriptions; description only mentions 'store or variant' filters, adding no additional 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?

Description clearly states 'List all checkouts' with a specific verb and resource, and mentions optional filters by store or variant, distinguishing it from sibling list tools.

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

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

Description implies usage when you need to retrieve multiple checkouts with optional filters, but no explicit guidance on when not to use or comparison with alternatives. Context is clear given sibling tools.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds a valuable behavioral detail: 'Results are paginated — check meta.page in the response for currentPage, lastPage, and total.' This goes beyond the annotations and informs the agent about response navigation.

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, zero waste. The primary action is front-loaded, and the pagination note is succinct and relevant. Every word 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 definition is complete for a list tool: annotations cover safety, schema covers parameters, and the description covers pagination behavior. It doesn't mention default sorting or response fields beyond meta.page, but that's a minor gap given the simplicity of the operation.

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

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

Schema coverage is 100% with descriptions for all five parameters. The description only reiterates the filters (store/email) and pagination, adding minimal new meaning beyond what the schema provides. The baseline of 3 is appropriate because the schema handles parameter documentation.

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 ('List'), a clear resource ('all customers'), and optional filters ('by store or email'), which distinguishes it from sibling tools like ls_get_customer (single retrieval) and ls_create_customer. It is unambiguous and not a tautology.

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 clearly conveys when to use it: to list all customers, optionally filtered. It implies a contrast with ls_get_customer for single-record retrieval, though it doesn't explicitly name alternatives. The context is clear enough for an agent to choose it for list operations.

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

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

Beyond annotations (readOnly, idempotent, non-destructive), the description reveals pagination behavior ('check meta.page...') and the cross-store constraint with LEMONSQUEEZY_ALLOWED_STORE_IDS, explaining the API key as the true boundary. This adds substantial behavioral context not present in the annotations.

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

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

Three sentences, front-loaded with purpose, followed by pagination and cross-store notes. Every sentence adds value; no filler or repetition of schema/annotations.

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

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

Given no output schema, the description covers the essential response element (meta.page with currentPage, lastPage, total). It includes optional filters, pagination, and the cross-store constraint, making it complete for this tool's complexity.

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

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

Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds minimal param semantics by mentioning 'optionally filtered by discount or order', which maps to discountId and orderId, but doesn't elaborate beyond what the schema already documents.

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 starts with 'List all discount redemptions' — a specific verb and resource that clearly states the tool's function. It also mentions optional filters by discount or order, which distinguishes it from sibling tools like ls_get_discount_redemption.

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 clear context: listing all redemptions with optional filters and pagination. It also includes a specific conditional guideline (when LEMONSQUEEZY_ALLOWED_STORE_IDS is set, at least one filter is required). It doesn't explicitly state when to use alternatives like ls_get_discount_redemption, but the listing scope is clear.

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

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description adds pagination behavior (check meta.page) and optional store filtering, which enhances transparency. No contradictions. However, it does not disclose authentication or rate limit details.

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: first states purpose clearly, second adds crucial pagination detail. No unnecessary words, front-loaded, and concise.

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?

No output schema, but description only mentions pagination in response (meta.page) and not the actual return structure of discount objects. For a list tool, this leaves agents guessing about the data returned, making it incomplete.

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 each parameter described in the schema. The description adds little beyond 'filtered by store' (already in schema) and pagination for the response, not parameters. Baseline 3 is appropriate.

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

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

The description clearly states 'List all discounts, optionally filtered by store', which is a specific verb+resource pair. It distinguishes from siblings like create, delete, get discount tools, and other list tools.

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

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

The description implies usage for reading discounts with optional filtering, but does not explicitly state when not to use or mention alternatives. The pagination note provides context, but lacks exclusion criteria.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds valuable behavioral details: pagination via `meta.page` and the cross-store requirement for `variantId`, plus the API key boundary note. This goes beyond the annotations without contradicting them.

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

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

The description is front-loaded with the core purpose and remains short, but has some awkward phrasing (e.g., 'at least one of: variantId' and a mid-sentence capital 'Pair'). Overall, it is appropriately sized and readable, earning a 4 rather than a perfect 5.

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

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

For a list tool with no output schema, the description covers the essential behavior: listing, optional filtering, pagination, and cross-store constraints. It does not explain the `include` parameter, but the schema already describes it, so this is sufficient for the tool's complexity.

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

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

All parameters are documented in the schema (100% coverage), so baseline is 3. The description adds meaningful context by emphasizing the optional variant filter and the conditional requirement for `variantId` in cross-store scenarios, enhancing parameter understanding beyond the schema descriptions.

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

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

The description clearly states the verb ('List') and resource ('files'), with an optional filter by variant. This distinguishes it from the singular `ls_get_file` and other list tools by indicating the list operation and pagination behavior.

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 use this tool (listing files) and includes a specific conditional note about requiring `variantId` when `LEMONSQUEEZY_ALLOWED_STORE_IDS` is set. It does not explicitly mention alternatives, but the distinction from `ls_get_file` is implicit, and the cross-store guidance adds practical usage context.

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

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

The description adds significant behavioral context beyond the readOnlyHint/true and destructiveHint/false annotations. It discloses pagination behavior ('check meta.page...'), and importantly reveals an environment-dependent requirement (LEMONSQUEEZY_ALLOWED_STORE_IDS) and the true security boundary ('the API key's visibility is the true boundary'). This goes well beyond the annotations.

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

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

The description is relatively concise and front-loaded with the main purpose. However, the cross-store note becomes run-on and grammatically awkward ('Even with that set, Pair with a scoped LemonSqueezy API key'), which slightly undermines structure. It still earns a 4 for packing useful info without excessive length.

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

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

The description covers the core aspects of a list tool: resource, optional filters, pagination response, and a special environment condition. It lacks an explicit explanation of the 'instance' concept beyond 'activations' and doesn't describe the response shape (but no output schema exists, so the meta.page mention helps). For a list operation with schema-provided params, this is reasonably 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?

Schema coverage is 100%, so baseline is 3. The description adds extra meaning to licenseKeyId by noting it becomes required under a specific configuration, which is not evident from the schema alone. It also implies that include/pageSize/pageNumber relate to list behavior, but doesn't detail them beyond schema descriptions. Overall, it adds non-schema context, justifying a 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 opens with a specific verb+resource: 'List all license key instances (activations), optionally filtered by license key.' This clearly distinguishes it from sibling tools like ls_list_license_keys (different resource) and ls_get_license_key_instance (single-instance fetch). The parenthetical 'activations' further disambiguates the domain concept.

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 clear context: it's for listing instances with optional filtering and pagination. It includes a cross-store note explaining when licenseKeyId becomes required (when LEMONSQUEEZY_ALLOWED_STORE_IDS is set), which is useful usage guidance. However, it does not explicitly state when to prefer an alternative tool, though 'list' vs 'get' distinction is implicit.

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

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

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds valuable behavioral context: results are paginated and notes to check the 'meta.page' object for currentPage, lastPage, and total. This goes beyond the annotations. No additional info on rate limits or auth is needed for a read-only operation.

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

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

The description is extremely concise: two sentences covering purpose, filters, and pagination response hints. Every word adds value; no redundancy or fluff.

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

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

Given 7 optional parameters, no output schema, and good annotations, the description covers filtering and pagination adequately. However, it does not mention that the response contains a list of license key objects (implied by name) or describe the 'include' parameter's effect on response shape. Still, the core usage is well-covered.

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 baseline is 3. The description summarizes filters ('optionally filtered by store, order, or product') and mentions pagination, but does not add new details about parameters like 'include' or pageNumber/pageSize beyond what the schema provides. The pagination note is helpful but not parameter-specific.

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 lists all license keys with optional filters by store, order, or product. It distinguishes from sibling list tools (e.g., ls_list_customers, ls_list_orders) by specifying the resource (license keys). The verb 'List' and resource 'license keys' are precise.

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

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

The description implies usage when needing to list license keys with optional filters, but lacks explicit guidance on when not to use it or alternatives like ls_get_license_key for a single key. Given the sibling tools are all list tools for different entities, the agent can infer the correct tool, but no direct comparison is provided.

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

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

Annotations already declare readOnly/idempotent, but the description adds critical behavioral details: pagination response shape (meta.page with currentPage, lastPage, total) and the cross-store enforcement boundary with LEMONSQUEEZY_ALLOWED_STORE_IDS. It also notes the API key's visibility as the true boundary, which is valuable for security-aware invocation.

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

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

The description is compact (three sentences) and front-loads the core purpose. The cross-store note is dense and slightly awkward ('Even with that set, Pair with...') but every sentence adds value. Minor typographical/case issues prevent a perfect score.

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 list tool with complete schema annotations and no output schema, the description does a good job by mentioning pagination meta fields. It does not describe the shape of an order item entry, but given the standard REST list pattern and sibling tools, this is 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?

Schema coverage is 100% so parameters are documented, but the description adds conditional semantics: when LEMONSQUEEZY_ALLOWED_STORE_IDS is set, at least one of orderId, productId, or variantId is required. This is a nuanced constraint not evident from the schema alone.

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

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

The description clearly states the tool's verb ('List') and resource ('order items') while noting optional filtering by order or product. This distinguishes it from sibling tools like ls_get_order_item (singular) and ls_list_orders (different resource). The 'all' scope emphasizes it's a collection operation.

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 concrete usage context: optional filters and pagination behavior, plus a cross-store constraint requiring orderId/productId/variantId under certain settings. However, it does not explicitly contrast with alternatives like ls_list_orders or ls_get_order_item, so the when-to-use guidance is incomplete.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral disclosure by stating that results are paginated and pointing to meta.page for currentPage, lastPage, and total, which is outside the annotations. This is useful but does not cover rate limits or response ordering, so not a 5.

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

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

Two sentences, front-loaded with purpose and then the essential pagination detail. Every sentence contributes; there is no filler or repetition of schema contents.

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 list tool with all parameters optional and a complete input schema, the description covers the main behavior, optional filters, and pagination response shape. It does not discuss the include parameter or default ordering, but those are documented in the schema and are not necessary for basic invocation. The absence of an output schema is partly mitigated by the pagination metadata note.

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 each parameter is already documented in the schema. The description summarizes the two filters (store/user email) and pagination, but does not add new semantics beyond what the property descriptions already state. Baseline 3 applies correctly.

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

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

The description opens with the specific action 'List all orders' and scoping phrase 'optionally filtered by store or user email', making the resource and verb unambiguous. This sets it apart from single-order tools like ls_get_order and mutation tools like ls_generate_order_invoice/ls_refund_order. The scope ('all orders') is precise and leaves no room for confusion.

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 establishes a clear use case: retrieving orders at scale with optional store/email filters. It does not, however, name sibling tools or state when not to use this tool, so agents must infer alternatives from naming. Clear context, but no 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?

Even though annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description goes well beyond the structured metadata: it discloses pagination shape (meta.page), sorting order (newest-first by created_at), the trap of using unit_price instead of effective_unit_price, the tiered/package semantics, and cross-store enforcement conditions. This is exactly the kind of value the description should add 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.

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

The text is dense and front-loaded with the core function and filter, then the pagination note, then the pricing semantics, then the store note. It's long but every sentence earns its place given the complexity. A small deduction because the cross-store sentence is somewhat run-on and could be split for readability.

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?

There is no output schema, so the description must carry the burden of explaining the response. It covers pagination fields, the key price-semantics fields (effective_unit_price, effective_unit_price_note, unit_price_is_not_charged, unit_price_is_per_package), and the newest-record rule. For a read-only, 4-param list tool, this is 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?

Schema description coverage is 100%, so each parameter (include, pageSize, variantId, pageNumber) already has schema-level descriptions. The description adds value beyond those: it explains how variantId interacts with store scoping, and it explains pagination-related fields that the schema doesn't fully connect (pageNumber/pageSize feed into meta.page). The description also clarifies the meaning of the variant filter with the 'newest by created_at' note.

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

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

The description opens with a specific verb and resource ('List all prices') and immediately states the only optional filter (by variant), which is enough to distinguish it from ls_get_price (single price) and other list tools. It does a lot more than name what it does, so the purpose dimension is fully satisfied.

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 tells the agent when the tool is appropriate (listing prices, optionally scoped by variant) and includes a cross-store note about constraints when LEMONSQUEEZY_ALLOWED_STORE_IDS is set. It does not explicitly name an alternative tool to prefer in a different situation, so it loses one point from a full 5.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by explaining pagination behavior and where to find pagination metadata, which is beyond the annotations.

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

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

Two sentences: first states purpose and optional filter, second explains pagination. No redundant information, front-loaded with key details.

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

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

Given the schema fully describes all 4 parameters, annotations cover safety and idempotency, and no output schema exists, the description is complete. It covers optional filtering, pagination, and what to expect in the response.

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

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

Schema description coverage is 100%, so baseline is 3. The description mentions the store filter and pagination, but does not add detailed semantics beyond what the schema provides for individual parameters.

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

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

The description clearly states the tool lists products with an optional store filter and explains pagination. It distinguishes itself from sibling list tools targeting different resources.

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

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

The description implies usage for listing products, optionally filtered by store, but does not provide explicit when-to-use or when-not-to-use guidance relative to other list tools.

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?

Beyond annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses the non-obvious behavior that the tool ignores the allowlist and returns every store visible to the API key, including those outside the allowlist. It also reveals pagination details (meta.page with currentPage, lastPage, total). This adds significant behavioral context beyond what annotations provide.

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

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

The description is three sentences and front-loaded with the main purpose. The cross-store note is slightly long but packed with essential caveats. No fluff, but the third sentence could be tightened. Overall, efficient and well-structured.

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

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

Given the tool's simplicity (no required parameters, no output schema) and rich annotations, the description covers the key aspects: purpose, pagination response, and a critical authorization boundary. It is sufficiently complete for an agent to correctly select and invoke the tool, though a brief note on the returned store object shape would be marginally helpful.

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

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

The input schema already provides 100% coverage for all three parameters (include, pageSize, pageNumber) with descriptions. The tool description adds some context about pagination in the response, but does not elaborate on parameter values or syntax. Given the complete schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('List all stores') and the scope ('for the authenticated user'). It distinguishes itself from sibling tools like ls_get_store (single store retrieval) by emphasizing 'all stores.' The verb is specific and the resource is 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?

Provides clear context that the tool lists all stores for the authenticated user, and includes a crucial cross-store note explaining that LEMONSQUEEZY_ALLOWED_STORE_IDS does not gate this tool. It suggests pairing with a scoped API key for enforceability, which guides use. However, it does not explicitly name alternative tools (like ls_get_store) or state 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?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about pagination (check meta.page), which goes beyond annotations. No behavioral contradictions.

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

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

Two sentences, front-loaded main purpose, no unnecessary information. Every sentence adds value: the first states the action and filters, the second explains pagination.

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?

Adequate for a list tool with high schema coverage, but lacks details on response format beyond pagination, ordering, or default behavior. No output schema, so more context could 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 100%, so each parameter is already documented. The description does not add new meaning beyond restating filter options. Baseline score of 3 is appropriate as per guidelines.

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 'List all subscription invoices' with optional filters, using a specific verb and resource. It distinguishes itself from sibling tools like ls_get_subscription_invoice and ls_refund_subscription_invoice.

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

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

The description implies usage for listing invoices with filters but does not explicitly state when not to use it or mention alternatives. No guidance on edge cases or when other tools are more appropriate.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds substantial behavioral context beyond that: the paginated response envelope, the authoritative effective_unit_price on embedded price records rather than unit_price, and the API-key-level cross-store boundary. No contradiction with annotations exists.

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

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

The description is front-loaded with purpose and every section carries useful information, but it is dense and the cross-store sentence is slightly verbose with an awkward 'Even with that set, Pair...' phrase. It earns its length overall, though not with maximum polish.

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

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

Given the tool has no output schema, the description fills the gap well by explaining the pagination metadata shape and the meaning of embedded price records. It also covers important cross-store constraints, making the tool callable correctly in both single-store and multi-store environments.

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?

Even though schema coverage is 100%, the description adds critical parameter meaning: include=price's effect, effective_unit_price semantics, and the conditional requirement on subscriptionId/priceId under cross-store configuration. This is exactly the kind of non-obvious semantic guidance agents need.

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

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

The description opens with a specific verb and resource: 'List all subscription items' and immediately clarifies the optional filters by subscription or price. This distinguishes it from sibling resources like subscriptions, subscription invoices, and subscription item usage records, even without naming an alternative.

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 usage context: pagination via meta.page, how to include price records, and the cross-store requirement that subscriptionId or priceId must be supplied when LEMONSQUEEZY_ALLOWED_STORE_IDS is set. It does not explicitly compare against alternative tools, but the guidance is strong enough to select and call confidently.

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