Lemon Squeezy MCP by usefulapi

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

With only destructiveHint=true from annotations, the description carries the burden well: it discloses the end-of-billing-period grace period, the resulting `cancelled` state, the real-customer impact, and the underlying API call. This is materially more than the annotation provides.

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, front-loaded with the write/nature signal, then the lifecycle behavior, then the API reference. No filler or redundancy.

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

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

For a single-parameter mutation with no output schema, the description covers purpose, lifecycle outcome, and real-world impact. Nothing an agent needs to call it 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?

One required parameter with 100% schema description coverage, so the schema already documents `subscription_id`. The description adds no format or sourcing details for the id, so the 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?

States a specific verb and resource ('Cancel a subscription') and adds scope ('LIVE') plus a 'WRITE:' marker that separates it from the read-oriented get/list siblings. An agent can distinguish it from update_subscription without opening either schema.

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

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

Usage is implied by the destructive nature and the 'LIVE subscription' qualifier, but the description never states when to prefer cancellation over siblings like update_subscription, nor any preconditions or exclusions. Adequate context but no explicit routing 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?

The only annotation is destructiveHint=true, so the description carries most of the burden. It usefully discloses the underlying API call (POST /checkouts) and that a shareable url is returned, but it says nothing about authentication, whether checkouts can be reused, or expiry behavior beyond the expires_at param.

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 tight sentences plus a short API line, front-loaded with the operation and scope, then the return value. Nothing is wasted, though the trailing 'API: POST /checkouts' is mildly redundant filler for an agent.

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 seven-param create tool with nested JSON:API objects and no output schema, the description covers the essential question (what comes back: the checkout with its url) and the HTTP operation. It omits any guidance on the nested object shapes, but the schema supplies those.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters including the nested checkout_data/product_options/checkout_options objects. The description only echoes store + variant and adds no syntax or format detail, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Create a hosted checkout / payment link for a store + variant') and prefixes it with 'WRITE:', making it instantly distinguishable from the read-only list/get siblings. An agent can tell this is the one creation tool in this family without opening the schema.

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

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

The 'WRITE:' prefix and 'for a store + variant' imply when it applies, but there is no explicit when-to-use/when-not guidance or named alternative. Since no sibling performs a comparable create-checkout action, the omission is less costly, but the description still leaves usage 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 declare readOnlyHint=true, so the safety profile is covered. The description adds only the raw REST endpoint mapping; it omits error behavior (e.g. not-found), auth requirements, and whether the response is cached or paginated.

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

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

Two short sentences, zero redundancy, with the core action front-loaded and the endpoint detail appended for convenience.

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

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

For a simple single-resource GET with fully documented params and a readOnly annotation, this covers what an agent needs to invoke it. There is no output schema and the description says nothing about the returned customer shape, which is the only real 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 description coverage is 100%, so both customer_id and the optional include sideload parameter are already documented in the schema. The description's 'by id' adds no syntax or format detail beyond that baseline.

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

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

States a specific verb (get) and resource (a single customer by id), which cleanly separates it from lemonsqueezy_list_customers. It does not explicitly name that sibling, but 'single' plus 'by id' makes the distinction 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?

Usage is implied: call this when you already have a customer id. There is no explicit when-to-use/when-not guidance, no mention of what to do if the id is unknown, and no pointer to list_customers for discovery.

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?

readOnlyHint=true already tells the agent this is a safe read, so the lower bar applies. The description adds only the underlying HTTP route, saying nothing about not-found behavior, auth/scopes, or how the sideloaded includes affect the response.

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

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

Two short sentences with the purpose front-loaded and nothing padded. The trailing 'API: GET /orders/{id}.' is largely redundant with the tool name and schema, which is the only minor waste.

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 trivial single-resource fetch with no output schema and a readOnly annotation, the minimal description is close to adequate. It still omits what the returned order contains and how the optional include parameter changes the payload, which an agent calling it would benefit from knowing.

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 order_id and include are documented in the schema, including the JSON:API include syntax example. The description adds no parameter meaning beyond that, so the 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?

States a specific verb+resource ('Get a single order') and pins it to an id lookup, which implicitly separates it from lemonsqueezy_list_orders. It does not name the sibling alternatives, but the singular scope 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?

'by id' implies the precondition that the caller already holds an order id, which is a weak usage signal. There is no explicit when-to-use vs list_orders or guidance on retrieving ids first, so guidance remains implied rather than stated.

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

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

The readOnlyHint annotation already establishes this is a safe read. The description adds only the raw HTTP route (GET /stores/{id}), which conveys no behavior beyond what the annotation and name already imply — no auth requirements, error semantics for a missing id, or pagination/sideload behavior.

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

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

Two very short sentences, zero filler, with the operation and its scope front-loaded and the endpoint appended as supporting 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 no output schema, the description should ideally say what a store object contains or what the include sideloading yields. For a simple id-based lookup with full schema coverage and a readOnly annotation, the definition is adequate but leaves the response shape entirely unspecified.

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 store_id and the optional include parameter are documented in the schema itself, including the JSON:API include format and example. The description adds nothing beyond the schema, so the 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?

States a specific verb and resource ('Get a single store by id'), and 'single' implicitly distinguishes it from the sibling lemonsqueezy_list_stores. It stops short of naming that sibling explicitly, so the differentiation is inferable rather than stated.

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 tool's purpose implies its usage (fetch one store when you already have an id), but there is no explicit when-to-use statement, no mention of when to prefer lemonsqueezy_list_stores, and no preconditions. Guidance is implied only.

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?

readOnlyHint=true already tells the agent this is a safe read, and the description only echoes that with the literal 'GET /subscriptions/{id}' path. It adds nothing about auth requirements, error behavior for an unknown id, or what the response contains, so it contributes little beyond the annotation.

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

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

Two short, front-loaded sentences with no padding. The API path restates what the verb already conveys, a minor redundancy but not enough to hurt structure.

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 id-based read with full schema coverage and readOnlyHint, the description is adequate; return values need not be explained since no output schema is claimed. It could be stronger by noting that the id is a subscription id specifically, not a customer or order id.

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%, including the include= sideload syntax, so the schema already carries both parameters. The description adds no format or constraint detail beyond it, making the baseline 3 the right score.

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

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

States a specific verb (get), resource (subscription), and scope (single, by id), which implicitly separates it from lemonsqueezy_list_subscriptions. It stops short of naming any sibling explicitly, so an agent must infer the boundary rather than being told it.

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?

There is no explicit when-to-use guidance, no mention of the list vs single-by-id choice, and no prerequisites. The only guidance is implied by 'by id' – an agent must work out for itself that this requires an existing subscription id rather than a customer or order id.

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, so the safety profile is covered. The description adds genuine context by noting the subject is derived from the API key rather than passed in, but says nothing about the response shape or failure behavior on an invalid key. With annotations carrying the safety burden, a 3 is appropriate.

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, each earning its place: identity statement, usage hint, then the raw endpoint. The core purpose is front-loaded ahead of the supporting 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?

For a no-parameter, read-only lookup with no output schema, the definition is nearly sufficient. The one minor gap is that it doesn't hint at what the returned user/account record contains, which the absence of an output schema leaves entirely unspecified.

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

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

The tool takes zero parameters, so the baseline is 4; the description usefully clarifies that the target identity comes implicitly from the API key, leaving nothing ambiguous about how the call is scoped.

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 ('Get the currently authenticated user/account') and pins down the identity source ('behind the API key'), which cleanly separates it from siblings like get_customer or get_store that take an explicit identifier.

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?

Explicitly recommends itself as a 'Good first call to confirm auth,' giving the agent a concrete trigger for when to reach for it. It names no alternative or exclusion, but none is needed for a zero-parameter self-lookup.

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, so the safety profile is covered. The description adds the underlying API mapping (GET /customers with filter[store_id], filter[email]), which helps an agent reason about the call, but says nothing about pagination behavior, rate limits, or result ordering.

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

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

One sentence plus a compact API mapping line, front-loaded with the core action and filtering scope. No wasted prose, though the parenthetical endpoint detail is somewhat redundant for an agent already given structured params.

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 5-parameter, all-optional list tool with no output schema, the description covers filtering but not the shape or pagination envelope of the returned customer list. Functional but incomplete on the return side, which no output schema compensates for.

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 (email, include, store_id, page_size, page_number) is already documented in the schema; baseline is 3. The description's mention of the API filter syntax adds marginal mapping value but no semantics 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?

States a specific verb and resource ('List customers') and immediately scopes it as optionally filtered by store and/or email. It is distinguishable from get_customer by the list verb, though it does not explicitly name that sibling as the 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 implies usage (fetch customers with optional store/email filters) but never states when to use this versus lemonsqueezy_get_customer or the other list_* tools, nor any prerequisites. Adequate but no explicit routing 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?

The readOnlyHint annotation already establishes this is a safe read, so the bar is lower. The description adds the concrete API endpoint, which is mildly useful context, but says nothing about pagination behavior, result volume, or authentication needs beyond what the schema implies.

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 terse, front-loaded sentences with zero padding; the primary operation leads and the API detail follows. Slight redundancy with the schema's store_id description keeps it from a 5.

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

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

For a simple read-only list endpoint with four optional, fully documented parameters and no output schema, the description covers what an agent needs to invoke it correctly. Return-shape and pagination expectations are the only mild gaps.

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

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

Schema description coverage is 100%, so all four parameters (include, store_id, page_size, page_number) are already documented in the schema. The description only echoes the store_id filter, adding essentially no meaning beyond the structured fields; 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?

States a specific verb (List) and resource (discounts) with the optional scope (one store), and the API mapping GET /discounts pins down exactly what is being called. It is not confused with get-style siblings, though it does not explicitly differentiate itself from them.

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

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

'Optionally filtered to one store' implies the main use case, but there is no when-to-use/when-not guidance and no mention of alternatives (e.g. fetching a single discount vs listing all). Usage is implied rather than stated.

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

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

Annotations declare readOnlyHint=true, so the safe-read profile is already covered. The description adds the underlying endpoint (GET /license-keys) and filter query-param naming, but says nothing about pagination semantics or result shape beyond what the schema provides.

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 core action and scope, with zero filler. The endpoint detail is compactly appended rather than padding.

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

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

For a read-only list tool with a fully documented six-param schema and no output schema requirement, the description covers the essentials. It notably omits pagination behavior, since page_size/page_number exist, which 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 description coverage is 100%, so the baseline is 3. The description maps the filter params to their API form (filter[store_id], filter[order_id], filter[product_id]), which is minor added value but does not document include, page_size, or page_number.

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+resource ('List license keys') and names the three optional filter dimensions (store, order, product). This clearly distinguishes it from the other list_* siblings that target different resources, though it does not explicitly address them.

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

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

The word 'optionally filtered by store, order, or product' implies how to narrow results, but there is no explicit when-to-use guidance, no prerequisites, and no mention of alternative tools for related lookups.

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?

readOnlyHint=true already declares this as a safe read. The description adds the underlying endpoint (GET /orders) and the filter parameter names, which is modest extra context, but says nothing about pagination limits, rate limits, or default result counts beyond what the schema documents.

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 compact sentences with the core purpose front-loaded and the API mapping trailing. No filler; every clause carries 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 filtered-list tool, the definition covers what is listed and how to filter it. However, with no output schema, the description gives no indication of the shape of returned order data or pagination behavior, leaving a gap an agent must discover at call time.

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 five parameters (include, store_id, page_size, page_number, user_email) are already documented. The description only echoes the API filter names, adding minimal meaning beyond the schema, so the 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?

States a specific verb and resource ('List orders') plus the scoping dimensions (store, buyer email). It is clearly distinguishable from the singular sibling get_order, though it never names that sibling explicitly to reinforce the list-vs-single distinction.

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

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

The optional filters imply when the tool is useful (bulk retrieval, filterable by store or buyer), but there is no explicit when-to-use guidance or contrast with get_order for a single order. Usage is left to inference.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds the underlying API endpoint (GET /prices) and filter syntax, which is useful context, but discloses nothing about result volume, pagination behavior, or sideload semantics beyond what the schema already states.

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

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

Two short sentences with zero filler; the core purpose is front-loaded and the filter scope plus endpoint follow immediately. Nothing redundant.

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

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

For a read-only, non-destructive list tool with fully documented schema and no output schema, the description is essentially complete. Minor gaps (no mention of pagination defaults or sideload behavior overview) are already handled by the schema, so they don't materially hinder calling 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 description coverage is 100%, so all four parameters are already documented in the schema. The description only echoes the variant filter via 'filter[variant_id]' and adds no meaning beyond the schema's own parameter descriptions. 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?

States a specific verb and resource ('List price models') and clarifies the optional filter scope to a single variant. It is clearly distinguishable from list_variants/list_products, though it doesn't explicitly name sibling tools. 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 phrase 'optionally filtered to one variant' implies when the variant_id filter applies, but there is no explicit when-to-use guidance, no exclusions, and no reference to alternative list tools an agent might otherwise reach for. Usage is implied rather than directed.

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, so the safety profile is covered. The description adds only the raw HTTP route (GET /products), which is not a behavioral trait an agent needs; it says nothing about pagination defaults, result ordering, rate limits, or empty-result behavior.

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

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

Two short clauses with zero waste; the core action and its main scoping option are front-loaded before the API 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?

For a simple read-only list tool with no output schema and fully documented params, this is nearly sufficient. The remaining gap is that pagination behavior and the shape of the returned product list are never hinted at, but the annotations and schema carry most of that burden.

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 4 well-documented parameters, so the baseline is 3. The description's mention of the store filter is consistent with the schema's store_id but adds no syntax or format detail (e.g. how include or page_number behave) beyond what is already documented.

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+resource ('List products') and adds the scope modifier ('optionally filtered to one store'), which is enough to separate it from list_stores, list_variants, list_prices in the sibling set. It stops short of explicitly naming an alternative, so it does not reach the 5 tier.

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 a listing endpoint with an optional store filter, but never says when to reach for this versus lemonsqueezy_get_store or lemonsqueezy_list_variants, nor any prerequisite such as needing a store id. No exclusions or alternatives are given.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds only the raw endpoint (GET /stores) and says nothing about pagination behavior, result caps, or account scoping beyond 'in the account'.

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

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

Two short sentences with the purpose front-loaded; no sentence is wasted, though the 'API: GET /stores' line adds little for an agent that already has the schema and 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?

For a simple read-only, zero-required-parameter list tool with full schema coverage and no output schema, the purpose statement is sufficient to invoke it. However, it omits pagination expectations, which is the one piece of behavioral context a listing tool needs.

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%, and the schema fully documents include, page_size, and page_number with JSON:API semantics and defaults. The description adds no parameter meaning beyond that, so baseline 3 applies.

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

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

States a specific verb and resource ('List all stores in the account') plus the underlying endpoint. The verb 'List' distinguishes it implicitly from the singular get_store sibling, but no sibling is named explicitly.

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 when-to-use, prerequisites, or alternative routing is given. It never says when list_stores is preferable to get_store, or that the result set is paginated and how to traverse it.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the underlying API endpoint mapping (GET /subscription-invoices), which is useful context, but says nothing about pagination behavior, return shape, or rate limits.

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 tight sentences with the purpose front-loaded and the filter list following. The API endpoint clause is somewhat redundant given the schema, but the definition remains compact and readable.

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

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

For a read-only list tool whose annotations carry the safety profile and whose schema fully documents the parameters, the description is nearly sufficient. The absence of an output schema is not a gap here since list results are self-evident.

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 all six parameters are already documented with meaning (including include, page_size, page_number). The description's mention of the three filters merely duplicates the schema, adding no syntax or format detail, so the 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 states a specific verb (List) and resource (subscription invoices), and names the three filter dimensions the tool accepts. It is clearly distinguishable from siblings like list_subscriptions, though it does not explicitly contrast itself with any sibling.

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 says the filters are optional, which implies a broad retrieval use case, but gives no when-to-use vs when-not guidance and no mention of alternatives (e.g., get_subscription for a single record). Usage context is only implied.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the underlying API endpoint and filter-expression mapping, which is useful context, but says nothing about pagination defaults, result ordering, or what the response contains.

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 tight sentences, front-loaded with the capability before the API detail, and no padding. The trailing endpoint/param list is somewhat redundant with the schema but compact enough to keep.

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 nine-parameter list tool with no output schema and no destructive hints, the definition covers filtering well but leaves the return shape and pagination behavior unaddressed. An agent can call it correctly but not predict what comes back.

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 nine parameters are already self-documenting, giving a baseline of 3. The description reinforces this by mapping the friendly parameter names to their API filter expressions (filter[store_id], filter[status], etc.), which is a marginal addition rather than new semantics.

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

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

States a specific verb (List) and resource (subscriptions) plus the filter dimensions available, so the agent knows exactly what it retrieves. It does not explicitly differentiate itself from the singular lemonsqueezy_get_subscription or from lemonsqueezy_list_subscription_invoices, so it stops short of a 5.

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

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

The enumeration of filter dimensions implies when this tool is the right choice (broad retrieval narrowed by store/status/product/customer/email), but there is no explicit when-to-use statement, no exclusions, and no routing to get_subscription for a single record. Usage is inferable 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 readOnlyHint annotation already establishes this as a safe read operation, so the description's main burden is lifted. It adds only the API endpoint mapping, with no detail on pagination behavior, result shape, or rate limits beyond what the annotations and schema 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?

Two tight sentences with zero filler; the core purpose is front-loaded and the API hint trails it. Nothing could be cut without losing 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 read-only, zero-required-parameter list tool with a fully documented schema and no output schema, the description covers purpose, optional filtering, and the backing endpoint. Only minor detail (e.g., that results are paginated by default at 10/page) is absent, and the schema covers that.

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 four parameters (include, page_size, page_number, product_id) are already documented in the schema. The description reiterates the product_id filter but adds no syntax or format detail beyond it. Baseline 3 applies when the schema does the heavy lifting.

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?

Names a specific verb (List) and resource (variants), and clarifies the resource with a parenthetical definition ('price/plan tiers'), which helps an agent understand what a variant is. It also names the underlying API endpoint. It does not, however, distinguish itself from the closely related sibling lemonsqueezy_list_prices, which an agent could easily confuse with variants.

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?

'Optionally filtered to one product' gives a hint about the filter parameter's use, but there is no explicit statement of when to call this versus list_products, list_prices, or other list tools. Usage is implied rather than guided.

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

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

Annotations only supply destructiveHint=true; the description carries the rest and does so well, marking it as a WRITE, stressing that it mutates a real customer's billing, and naming the endpoint (PATCH /subscriptions/{id}). It does not disclose side effects an agent would want, such as proration on plan change or reversibility of a cancel, so it is strong but not exhaustive.

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

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

Two compact sentences at most, front-loaded with the "WRITE:" warning before the capability list, then the endpoint. No filler and the most decision-relevant information (write, live, billing impact) comes first.

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

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

For a destructive one-resource mutation with no output schema, the description supplies the operation type, target, mutation modes, blast radius, and endpoint — enough to call it responsibly. What is missing is behavioral detail on the mutation itself: whether plan switches prorate, whether a cancel here differs from the dedicated cancel tool, and whether supplying multiple fields in one call is supported.

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 already carries its own documentation and the baseline is 3. The description restates the parameter purposes inline (variant_id for plan/tier, pause/unpause, billing anchor) without adding format, constraints, or interaction rules 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?

"WRITE: Modify a LIVE subscription" gives a specific verb (modify), resource (live subscription) and enumerates the exact mutation modes (plan/tier via variant_id, cancel, pause/unpause, billing anchor), so the agent knows precisely what this call changes. It stops short of differentiating from the sibling `lemonsqueezy_cancel_customer_subscription`, even though "cancel" is listed among the modes here, leaving a small overlap unresolved.

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?

"This affects a real customer's billing" implies caution and live-subscription scope, and "LIVE" hints at a precondition, but there is no explicit when-to-use guidance, no statement of when NOT to use it (e.g. versus the dedicated cancel tool), and no instruction on which of the five optional fields must be supplied together. Usage is inferable but not stated.

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