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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds useful context that the catalog is built-in, works offline, and requires no account. This is meaningful extra behavioral information, though it does not detail matching behavior or return format.

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

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

The description is front-loaded with the core action and resource, then adds usage and offline context without wasted sentences. The site examples are long but directly useful for recognizing the catalog's scope.

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

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

For a simple read-only discovery tool with one optional parameter and no output schema, the description covers what it searches, why to use it, what to find, and the offline/no-account constraint. Nothing essential for correct invocation 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 description coverage is 100%, and the single search parameter is already documented with examples in the schema. The description does not add syntax or matching details beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: search the built-in list of 120+ ready-made data bots. It also names the sibling tool it feeds into by saying to find the worker name and inputs before calling run, so an agent can distinguish discovery from execution.

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 clearly says to use this tool to find a bot's worker name and inputs before calling run, giving an explicit usage context. It does not spell out when not to use it or cover every sibling alternative, but the intended workflow is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds 'Free' and the freshness signal (latest snapshot date), but says nothing about result volume, ordering, or whether categories can disappear between calls — useful but not rich beyond the annotations.

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

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

Two short sentences with zero waste: the listing and its freshness come first, then the usage guidance. Every clause carries information an agent would act on.

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?

A simple, read-only, no-argument discovery tool whose annotations cover safety, and the description covers purpose, cost, freshness, and the handoff to coupang_top. Only minor gaps remain (no output schema, no hint at result shape beyond the snapshot date), which is adequate for a tool this simple.

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 there is nothing for the description to disambiguate and it correctly says nothing about arguments. Baseline 4 applies for a no-parameter tool.

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 a precisely scoped resource: Coupang categories whose daily best-selling top 30 is ready, plus the latest snapshot date. It is clearly distinguishable from sibling coupang_top, which it names as the downstream consumer of the category choice.

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 concrete use cases ('which categories can you rank?' and picking a category for coupang_top), which is exactly the discovery role an agent needs. It does not explicitly state when NOT to use it, but with only one sibling overlap (coupang_top) the routing is effectively clear.

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

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

The description goes well beyond the annotations (readOnlyHint=false, idempotentHint=true) by disclosing that data is a once-daily snapshot reused across calls, that each category/day costs 300 credits regardless of limit, that re-fetching the same snapshot is free, that free credits are consumed first, that an ambiguous/non-matching category name returns a list and charges nothing, and that the first paid use requires accept_terms. This is exactly the cost/idempotency/terms context an agent needs before invoking a credit-spending, non-read-only tool.

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 trigger condition is front-loaded in the first clause, and every later sentence carries load-bearing pricing, caching, or terms information. The parenthetical column enumeration ('sale price, coupons, seller type, monthly buyers …') is slightly padded for what it conveys.

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

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

There is no output schema, yet the description enumerates the returned columns, names the `snapshot_date` field, and explains the list-return path for ambiguous category names, alongside cost, caching, and consent requirements. An agent has everything needed to call this correctly and to explain the charge to the user.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning on top by explaining that cost is per category per snapshot regardless of `limit`, that `snapshot_date` reports the caching day, and that `accept_terms` gates only the first paid use. It does not explain how `csv_path` interacts with row return (that stays in the schema), keeping it just short of a 5.

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 — retrieving today's top 30 best-selling products for a Coupang category, with the exact column set (price, reviews, delivery, detail-page columns) and the optional price-comparison use. It is unmistakably distinct from the sibling tools (login, me, catalog, run, fetch, coupang_categories), which the agent can rule out immediately.

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?

"Use when the user wants today's best-selling / top 30 products of a Coupang category ... or a price comparison" gives a clear triggering condition. It lacks an explicit 'use coupang_categories first to resolve a name' routing instruction and states no exclusions, so it stops short of a full when/when-not/alternatives treatment.

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

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

The annotations already establish that this is a read-only, open-world operation. The description adds useful behavioral context beyond annotations: it may wait up to wait_seconds while collection is ongoing, and reading rows incurs no extra cost.

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

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

The description is front-loaded with the core action, followed by usage condition, wait behavior, and cost note. Each sentence adds distinct value with no filler.

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

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

For a read-only fetch tool with rich schema parameter descriptions and no output schema, the description covers purpose, usage, waiting behavior, and cost. It stops short of explaining return shape, but the schema already carries file-saving and row-limit details.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds some clarity around dataset_id coming from run and wait_seconds behavior, but it does not cover csv_path or max_rows beyond what the schema provides.

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

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

The description states a specific verb and resource: 'Get the rows of an earlier run by dataset id.' It also ties the dataset id back to the sibling tool 'run', so an agent can distinguish this fetch operation from run itself.

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 a clear triggering condition: 'Use it when run said the collection was still going.' That is enough to know when this tool is appropriate, though it does not explicitly name alternatives or exclusions.

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

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

Annotations only declare the safety profile (non-read-only, open-world, non-idempotent, non-destructive). The description adds the critical behavior an agent cannot get elsewhere: the two-call protocol, the fact that it never blocks, that the first call returns a link and a code that must be shown to the user, and that the key is never exposed. This is exactly the extra context the annotations cannot carry.

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 with zero waste, front-loaded with purpose, then usage triggers, then the call protocol and key-handling note. Every sentence carries information the agent needs.

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

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

There is no output schema, and the description compensates by explaining what the first call returns (link + code), what the second call does (finish and save the key), and what is never shown (the key). For a single-optional-parameter auth tool, nothing necessary 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% and the single 'restart' parameter is documented in the schema, so the baseline is 3. The description does not mention restart at all, but the two-step flow it describes implies state that makes restart meaningful.

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 first sentence names a specific verb and resource ('Connect the user's HashScraper account') plus the mechanism (browser device login, free sign-up). An agent immediately knows this is an authentication/onboarding tool, which is clearly distinct from the data-oriented siblings (coupang_top, catalog, run, fetch).

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 explicit triggers ('Use it first when another HashScraper tool says "Not connected", or when the user asks to connect or reconnect') and an explicit exclusion ('Skip it if HASHSCRAPER_API_KEY is set'). Both when-to-use and when-not-to-use are stated, leaving nothing 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 and openWorldHint=true, so the description is not carrying the safety burden. It still adds genuinely useful behavior the schema cannot express: credits refill at midnight KST, which affects when a result goes stale, and it implies an authenticated-account prerequisite via 'connected 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, both earning their place: the first defines the payload, the second defines the call site. The timezone caveat is parenthetical rather than buried, and there is no filler.

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

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

With no parameters and no output schema, the description has to describe the return values itself, and it does: email plus remaining daily credits. The only minor gap is what happens when no account is connected, which an agent may hit given the 'login' sibling exists.

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 there is nothing to disambiguate and the baseline is 4. The description correctly adds no parameter noise and instead spends its words on the returned values.

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 name 'me' is opaque, but the description immediately specifies the resource and returned fields: the connected account's email and remaining daily free credits. It implicitly distinguishes itself from the 'login' sibling by scoping to an already-connected account, though it never names that distinction 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?

It gives a concrete trigger: 'Use before a paid-looking collection to check what is free.' That tells the agent when to reach for this tool rather than spending credits blindly. No explicit when-not or named alternative is provided, but no sibling meaningfully competes for this purpose.

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

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

Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false; the description adds the behavior that actually matters: credit consumption (daily free credits unless use_credits=true), a terms-consent gate that must not be forged by the agent, and the async timeout return path (dataset id + later fetch). It also discloses the non-idempotent cost of re-running, matching the annotations rather than contradicting them.

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

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

Four sentences, front-loaded with the core action and cost model, then the timeout fallback. The heavy parenthetical packing and em-dash example list make it denser than ideal, but 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?

Covers the whole call cycle an agent needs for a 7-param, nested-object tool: prerequisite lookup, credit and consent gating, wait behavior, and what comes back (rows, a CSV path, or a dataset id for later fetch) even though there is no output schema. Nothing required to invoke it correctly 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%, so baseline is 3, but the description adds cross-parameter semantics the schema can't: the `wait_seconds` timeout producing a dataset id instead of rows, and the credit/terms conditions governing `use_credits` and `accept_terms`. It does not explain `max_rows` vs `csv_path` interaction (only the schema does that), so it stops short of a 5.

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 concrete verb and resource ("Collect public web data with one HashScraper bot and return the rows") and grounds it with examples of bot outputs (product price, blog posts, reviews, map places). It also names the sibling it depends on ("find the worker with catalog first") and the fallback sibling (`fetch`), so an agent can distinguish it from catalog/fetch 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?

Explicit routing rules: look up the worker in `catalog` before calling, call `fetch` later instead of running again if collection is unfinished, and set `use_credits` only when the user wants to spend their own credits. It also gives a hard precondition for `accept_terms` (only after the user agrees). Both the when and the when-not cases are covered.

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