FastDrop

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

Annotations already establish the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), so the description only needs to add context. It does so by disclosing what is compared — pricing, open source status, MCP verification and tool list, rating, votes, launch date, awards, maker — which tells the agent what data will come back beyond the annotation layer.

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 a colon-delimited list of comparison fields; no filler, and the operation and scope are stated before the 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?

With an output schema present, return-value documentation is not required, and annotations cover the safety profile. The description covers operation, cardinality, and compared fields; only edge behavior (fewer than 2 or more than 4 slugs, invalid or non-live slugs) is left 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 schema documents 'slugs' with 100% coverage including the '2-4 product slugs' cardinality, so the baseline is 3. The description adds the 'live' constraint on eligible products, which is meaning the schema does not carry, justifying a small bump. It adds nothing about slug format or error handling for invalid/duplicate slugs.

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 (side-by-side comparison) and resource (live FastDrop products) and enumerates the compared dimensions, so the agent knows exactly what output to expect. It doesn't explicitly name the sibling it differs from (e.g., get_product for a single product or find_alternatives), but the '2-4 products' scope implicitly separates it from those 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?

Usage is implied: comparing multiple products at once, and the 'live' qualifier hints that only live products are eligible. However, there is no explicit when-to-use/when-not-to-use guidance or routing to alternatives like get_product for a single lookup or find_alternatives for substitutes.

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 this a safe read (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description still adds value by disclosing the ranking factors (shared tags, overlapping probed MCP capabilities, pricing model) and that each result carries a match rationale.

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, front-loaded with what the tool does and then what makes each result meaningful. Every clause 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?

An output schema exists, so return structure needn't be explained, and the description covers purpose, ranking behavior, and result rationale. The only minor omission is any note on result volume or how ranking ties break, which is not critical for a read-only discovery 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%, so both parameters (slug, limit) are fully documented in the schema and the description adds no format, constraint, or example detail beyond it. Baseline 3 is appropriate when the schema carries the parameter burden.

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 names a specific verb+resource ('Live FastDrop products similar to a given one') and immediately specifies the ranking criteria, distinguishing it from lookalike siblings like search_products and compare_products. An agent can tell what it returns and how results are ordered.

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 'similar to a given one' — you call it when you already have a product slug and want related ones — but there is no explicit when-not-to-use guidance or reference to siblings such as search_products or compare_products. Adequate but with a clear routing gap.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real value: it discloses the per-product deal shape (offer, optional code, claimUrl), warns that 'exclusive' is the maker's unverified claim and must be disclosed to the user, and states that deals never affect rank. Those trust and integrity caveats are not derivable from annotations or 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?

Four short sentences, front-loaded with purpose then usage trigger, then output shape and caveats. The first sentence is somewhat promotional ('that makers offer people who find their product here') and could be trimmed, but overall there is little 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?

With an output schema present the description needn't explain return values, yet it usefully previews the deal fields and flags the unverified 'exclusive' claim. Combined with rich annotations and fully documented params, an agent has what it needs to call and interpret 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?

Schema coverage is 100%, so tag, limit, and query are fully documented in the schema itself with enum values and range/default notes. The description adds nothing about how to construct a query or choose a tag. Baseline 3 is appropriate when the schema does all the work.

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 defines the resource clearly (deals: discounts, extended trials, promo codes) and the trigger sentence ('Use when the user hunts for a deal, discount, coupon or promo code on an AI tool, app or MCP server') establishes the retrieval action. The opening phrase 'Launch deals on FastDrop' is slightly ambiguous about whether the tool launches or looks up deals, which costs it the top mark. It still distinguishes itself from siblings like search_products and find_tools by scoping to deals specifically.

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

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

It gives explicit user-intent triggers (hunting for a deal, discount, coupon, promo code) and the domain (AI tool, app, MCP server). It does not name or exclude alternative sibling tools such as search_products, so an agent must infer routing. Clear context, but no explicit when-not or alternatives.

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 useful context beyond that: results come from real tools/list data rather than marketing copy, so a match implies the capability actually exists. It doesn't discuss rate limits, coverage gaps, or failure modes, 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?

Front-loaded with the core purpose, then usage triggers, then query guidance, so an agent can stop reading early if it only needs the first sentence. The three inline example phrasings are useful but make the middle dense; a slightly tighter example set would read better.

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?

An output schema exists, so return-value detail isn't required, and the annotations carry the safety profile. The description still covers the essentials an agent needs: what it searches, when to invoke it, and how to phrase the query.

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, but the description adds real meaning by prescribing query phrasing in plain capability words ('send transactional email', 'query postgres') rather than product names. It also notes that results list matching tools, though it says nothing about the limit parameter beyond the schema.

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

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

The description states a specific verb and resource ('Find an MCP server or AI tool that can do a job') and scopes the domain to MCP servers/integrations, which clearly separates it from product-oriented siblings like search_products, compare_products and find_alternatives. An agent can route to it 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?

It gives explicit trigger conditions with concrete user phrasings ('is there an MCP for Stripe?', 'something that can scrape websites'), which is strong positive guidance. It does not name a when-not case or point to a specific alternative sibling (e.g. find_alternatives) for adjacent needs, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavior beyond that: auth changes personalization, own launches and already-voted items are excluded, tag-matches rank first, and each item carries a needs-a-vote/needs-a-review flag plus a boost progress object. This is genuinely useful operational context that the structured fields do not supply.

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 ranking rules are front-loaded, which is good, but the second half explaining the participation loop and queue promotion is long and reads more like product-meta than invocation guidance. Several clauses could be trimmed without losing selection value.

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

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

An output schema exists, so return values need not be described, yet the description helpfully explains item flags and the boost object. Auth-dependent behavior is covered, and with only one optional parameter the definition gives an agent enough to call 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?

There is only one parameter (limit) with 100% schema description coverage including its 1-20 range and default, so the schema carries the semantics. The description adds nothing about the parameter, making the baseline 3 appropriate.

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

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

The description states a specific resource (a live-launch engagement feed) and its ranking rules (supportive makers first, fewest votes first, zero-review items flagged), which sets it apart from generic listers like list_launches. It is clear what the tool surfaces, though the purpose is embedded in a long prose block rather than stated up front as a single verb+resource.

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 rather than stated: the feed is for finding launches that need a vote (toggle_vote) or a review (post_review), and the auth/no-auth distinction is noted. However, it never explicitly says when to call this instead of siblings such as list_launches or get_launch_day_status, leaving selection 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely useful behavior beyond them: deeplinks only appear where the client supports them, and secrets are always placeholders rather than real values. It does not mention any auth or rate-limit considerations, but for a read-only config generator that is a minor gap.

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

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

Two tight sentences: the deliverable first, then the usage trigger and the placeholder caveat. Nothing is redundant and no sentence is 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?

An output schema exists, so the description needn't explain return shape. For a two-parameter, read-only tool with full schema coverage and annotations, the description covers purpose, trigger, and the one non-obvious behavior (placeholder secrets) adequately.

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 the slug and client enum are fully documented in the schema, including the 'all clients' default. The description's client list mirrors the enum without adding syntax or selection guidance, 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 deliverable (ready-to-paste install config for a FastDrop product's MCP server) and enumerates exactly which clients it covers. This is clearly distinguishable from sibling catalog tools like get_product or search_products.

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?

Explicit trigger: 'Use when the user asks how to install, connect, or add a server found on FastDrop.' That is a clear usage context, though it names no exclusions or alternative sibling tools for adjacent needs.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds real value beyond them: the UTC-day scoping of 'today', the fact that the response is conditional on whether the caller manages the product, and the extra boost-progress section that only appears for managers.

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 capability and then the conditional manager-only addition. Dense but every clause conveys content; only the parenthetical '(UTC day)' is a clarifying gloss rather than new 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?

With an output schema present the description need not document return values, yet it still summarizes the key fields, and it flags the conditional manager branch that an agent should expect. Combined with full parameter coverage and clear annotations, nothing essential is missing; only explicit alternative-routing is absent.

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 a single 'slug' parameter with 100% schema description coverage, so the schema already carries its meaning. The description adds nothing about slug format or resolution (e.g. whether it is the product slug vs. launch slug), 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 names a specific verb+resource (fetch a live product's standing on today's FastDrop board) and enumerates the concrete payload: rank, qualifying votes today, the next launch above, votes needed to pass, hours left. That is far more specific than the title and clearly separates it from get_product or list_launches, though 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?

Usage is implied by the phrase 'live product ... today's board', which tells the agent this only applies to currently-launching products, and it notes the manager-only extra section. There is no explicit statement of when not to use it or which sibling to prefer for board-wide data (e.g. list_launches).

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 readOnly/idempotent/openWorld, and the description adds genuinely new behavioral facts: results are capped at 50 per call, ranked by votes, and 'ranks can shift between calls as votes change' (a non-determinism caveat the annotations do not capture), plus the public-only/no-contact-details boundary.

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 dense sentence, front-loaded with the verb/resource before the payload list and pagination caveat. No filler clauses; every segment carries information an agent would otherwise have to infer.

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 an output schema present, return-value detail is not required, yet the description still covers payload scope, page size, ranking basis, and pagination instability. Nothing needed to call or interpret 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 coverage is 100% so baseline is 3, but the description adds real meaning: the handle is the profile handle (echoed as source location, without @) and offset is tied to the 'nextOffset' cursor from the previous call, which is the non-obvious usage rule. It does not restate defaults beyond what the schema already gives.

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 builder's public FastDrop profile by handle') and enumerates the payload (label, bio, links, awards, stats, live products), which clearly separates it from siblings like get_product or search_products. An agent knows exactly what entity is being fetched.

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 tells the agent where the handle comes from ('from a product's maker.handle or a /u/<handle> URL'), which is real routing guidance, and the 'public data only' framing sets context. It stops short of naming alternatives or stating when-not to use it, so it is clear context rather than full when/when-not 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 readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds genuinely non-obvious context about the returned data's provenance, notably that the tool list is probed from the endpoint rather than maker-supplied tags, plus the 'when available' caveat on the verification timestamp. It stops short of describing failure behavior for an unknown or dead slug.

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 operation and scope, followed by a tight enumeration of return fields. Every clause carries information; nothing is redundant or 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?

An output schema exists, so field structure need not be re-explained, yet the description still usefully clarifies what the probed tool list means semantically. For a one-parameter read tool this is nearly complete; only the not-found/dead-endpoint behavior is left unstated.

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 the single slug parameter already documents its format ('Product slug from the /p/<slug> URL'). The description only restates that lookup is by slug, adding no syntax or resolution detail beyond the schema, so the baseline of 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 (Get), resource (FastDrop product), and cardinality/scope (one, by slug, live). The singular 'one ... product by its slug' cleanly separates it from sibling list/search tools like search_products and compare_products without needing to name 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 slug-based framing implies the precondition (you must already have a slug), which is useful, but there is no explicit statement of when to prefer this over search_products, compare_products, or find_alternatives, and no when-not guidance. 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds beyond this: it reveals the two-level tree structure and that removed comments appear as tombstones, which is useful for agent understanding.

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

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

The description is concise: two sentences that are front-loaded with the core purpose and immediately provide valuable detail. 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 rich annotations, output schema, and clear parameter schema, the description adds necessary context (tree structure, tombstone, authentication) to make the tool fully self-explanatory.

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, so the description adds no additional meaning. This meets the baseline expectation.

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 lists comments by product slug, and specifies the two-level tree structure (top-level and replies). This distinguishes it from sibling tools like list_reviews or get_product.

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

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

The description provides clear context: it lists comments for a live FastDrop product by slug, and notes it is unauthenticated. However, it does not explicitly state when not to use it or compare to alternatives.

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, non-destructive, open-world. The description adds real value beyond them by explaining the response fields that carry non-obvious meaning: MCP endpoint URL, mcpVerified (probe success), and mcpAuthRequired when the endpoint returned 401/403. This tells the agent how to interpret ambiguous results, which annotations cannot. It omits pagination/ordering edge cases, 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?

Three dense sentences: what it is, when to use it, what comes back. Ranking scopes are front-loaded ahead of usage guidance, and no sentence is 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?

With an output schema present, the description need not explain return structure, and it still flags the interpretation-critical fields. Filters, defaults, and intent mapping are all covered for a two-parameter, no-required-args read 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 limit (1-50, default 20) and window (enum, UTC, default all) fully documented in the schema. The description largely restates the window options and ranking basis without adding format or interaction 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?

States a specific verb and resource (list launches) plus the ranking basis (votes) and available scopes (all time, today, this week). An agent can distinguish this from siblings like search_products or get_engagement_feed, which are retrieval by query/feed rather than ranked launch listings.

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?

Gives an explicit use context: 'Use when the user asks what's new or trending in AI tools, MCP servers, or indie software, or what people launched today or this week.' That maps intent to window values, which is genuinely helpful. It does not name alternatives (e.g. search_products for keyword lookup) or state exclusions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds that it is unauthenticated and details return data, going beyond annotations. No 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 concise sentences with front-loaded purpose. No unnecessary words, every sentence adds value.

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

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

Given rich annotations, complete schema, and output schema, the description covers essential aspects: purpose, authentication, and return data. No gaps identified.

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 100% of parameters with descriptions. Description adds context about 'by its slug' but does not significantly exceed schema explanation. 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?

Description clearly states 'List reviews for a live FastDrop product by its slug' with specific verb and resource, and includes return fields. Distinguishes from siblings like list_comments and list_launches.

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 mentions 'Unauthenticated - available to any agent' and implies usage for reading reviews. Lacks explicit when-not-to-use but provides sufficient context given siblings are for different resources.

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/openWorld, so the safety profile is covered. The description adds real value beyond that: result ranking by votes, verification status via mcpVerified, and freshness where available. It stops short of describing pagination behavior or how the limit interacts with ranking, which keeps it out of 5 territory.

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?

Four tight sentences, front-loaded with the core purpose before usage triggers, then the exclusion, then the optional filter. No filler; every clause carries routing or behavioral 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?

An output schema exists, so return values need not be re-explained, and the description still volunteers ranking and verification metadata. Combined with full parameter documentation and clear sibling routing, an agent has everything needed to call this 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 description coverage is 100%, so all four parameters are already documented, including the enum slugs and the limit range. The description restates the tag and x402 concepts ('curated tag', 'x402-payable services (Bazaar catalog)') but adds little syntax or precedence guidance 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 ('Look up products launched on FastDrop') and enumerates the three match surfaces: name, tagline text, and curated tag. It also names the sibling it is not (find_tools), so an agent can route 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?

Explicitly enumerates the triggering situations with concrete user phrasings ('what is Koala SEO?', 'new AI tools for marketing') and draws a hard boundary with an alternative: 'For a tool that can do X, prefer find_tools.' This is textbook when-to-use guidance.

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