BetterLaunch

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the description earns credit for adding that lookups are restricted to 'public' products and that unknown or withdrawn products surface as a tool error rather than an empty result. That error semantics is the main thing an agent could not infer from 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 tight sentences with no filler; the core scope ('public product details and taxonomy by exact slug') is front-loaded and the caveat follows.

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 does name the returned content (product details and taxonomy) and covers the failure mode. The gap is the locale parameter's effect on the returned taxonomy, which an agent may need to know.

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

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

Schema coverage is 0%, so the description bears the burden; it clarifies that the slug must be an exact match (not fuzzy), which is genuinely useful. It says nothing about the locale parameter or what localization affects in the returned taxonomy, leaving half the parameters undocumented.

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

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

States a specific verb and resource ('Get public product details and taxonomy') and qualifies it with 'by exact slug', which separates it from the fuzzy search_products sibling. It does not explicitly name list_products or search_products, but the exact-lookup framing makes the distinction inferable.

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 is clear: exact-slug retrieval rather than listing or searching. However, it never says when to prefer search_products over this tool, nor that the slug must already be known, leaving the routing 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 read-only, idempotent and non-destructive, so the safety profile is covered. The description adds substantive context beyond that: only *active* categories, empty categories are deliberately included, and product counts are *public* ones, which tells the agent what it will and won't see.

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 front-loaded sentence with the resource, the scope qualifier and the payload all stated once. No filler, no repetition of the tool name as a sentence.

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 usefully previews the returned fields and the empty-category edge case, which is what an agent needs to interpret results. Ordering, pagination and count semantics are unstated, a minor remaining gap for a no-argument list tool.

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

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

The tool takes no parameters, so the baseline of 4 applies; the schema is empty and nothing is left for the description to disambiguate.

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 active BetterLaunch categories') and enumerates what is returned (bilingual names, slugs, public product counts). No sibling tool in the set (get_product, list_products, list_tags, search_products) covers categories, so the 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?

Usage is only implied by the name and the word 'active'; there is no statement of when to prefer this over sibling listing tools or any exclusion. The 'including empty categories' clause hints at when a filtered alternative would be wrong, but no alternative is named.

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 the safe read-only, idempotent, closed-world profile, so the bar is lower; the description still adds useful behavior: public-only visibility, an 18-per-page cap, and that invalid/inactive taxonomy yields a tool error. It could go further on what the error payload or result shape looks like.

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

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

Two tight sentences, front-loaded with the core action and scope, with the error behavior appended where it is useful. Nothing is 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?

With no output schema, the description should close more gaps for a five-parameter tool; the pagination cap and error behavior help, but the unmentioned q and sort semantics leave an agent guessing about filtering and ordering.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, yet two of the five parameters (q and sort) are never mentioned. It only gestures at kind/slug and the page size, leaving the search term and the newest/popular/name ordering options undocumented.

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

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

Specific verb and resource ('Browse public products') plus a clear scoping constraint ('in one active category or tag'), which implicitly separates it from the sibling search_products. It stops short of naming the sibling explicitly, so it earns a 4 rather than 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?

Usage is implied by the taxonomy-scoping phrase, but there is no explicit statement of when to prefer this over search_products or get_product. The note about unknown/inactive taxonomy is a failure mode, not selection 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 establish that this is a safe, read-only, idempotent, non-destructive operation. The description adds useful behavioral context by specifying the returned fields and the inclusion of unused tags, though it does not mention pagination, ordering, or authorization requirements.

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 definition is a single front-loaded sentence with no redundant or filler content. Every phrase contributes to specifying scope or returned data.

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

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

For a simple zero-parameter list tool with no output schema, the description gives enough detail about what is returned: bilingual names, slugs, product counts, and unused tags. It could be slightly more complete by mentioning ordering or pagination behavior, but no critical information 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?

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics for the description to clarify.

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 and resource: listing active BetterLaunch tags with bilingual names, slugs, and public product counts. It is clearly distinct from product- and category-listing siblings, but it does not explicitly name those alternatives or contrast itself with them.

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

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

The description explains what is listed and notes that unused tags are included, but it gives no explicit guidance on when to use this tool versus alternatives such as list_categories or search_products. Usage is only implied by the tool name and resource.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real value by disclosing a result cap ('at most 10 summaries of each kind') and the public/active filtering constraint. It stops short of saying how results are ordered or matched.

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 filler, with the capability stated first and the result-size constraint immediately after. Nothing is wasted and nothing is buried.

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 must carry the return contract, and it only partly does: it says summaries are returned capped at 10 per kind but not what a 'summary' contains or whether the three kinds come back together. For a one-parameter search tool this is adequate but leaves real gaps for an agent composing a call.

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

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

The schema has 0% description coverage on the sole parameter 'q', so the description carries the full burden and fails it: nothing explains what q matches against (products, categories, tags, or all three), whether it is free text or a prefix, or how the 1-100 character constraint behaves. The reader must infer that it is a search query.

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 ('Search') and three concrete resources (public BetterLaunch products, active categories, tags), which is more informative than the bare name. It does not, however, explicitly differentiate itself from the close siblings list_products/list_categories/list_tags, leaving the search-vs-list distinction implicit.

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 only implied: the keyword 'Search' plus 'public'/'active' hints that this is a query-driven lookup rather than an enumeration, suggesting list_products et al. as the alternative. No explicit when-to-use or when-not-to-use guidance is given, and no sibling is named.

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