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

Annotations already cover safety (readOnlyHint=true) and open-world scope. The description adds real value beyond that by disclosing the contents of the payload and pre-empting the natural follow-up (limitations, citation instructions) – which matters since there is no output schema to inspect. Minor gap: no mention of output 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?

Two sentences, front-loaded with the core purpose, followed by a dense enumeration of contents and then usage triggers. The middle enumeration is long but every item earns its place as a discoverable payload field; a single semicolon-joined sentence is slightly harder to scan than a short list.

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 zero params, no output schema, and annotations covering the safety profile, this description supplies what an agent needs: exact contents and the questions it answers. Only the return format and approximate size are unstated, which is a minor omission for a simple metadata read.

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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. It correctly implies the tool is parameter-free by describing no filtering or scoping options.

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?

"Describes the Unlock Pulse dataset itself" is a specific verb+resource, and the enumeration (server version, refresh time, coverage counts, blockchains, sources, formula, limitations, citation) makes the scope unmistakable. An agent can tell instantly this is the metadata/provenance tool, not one of the sibling data-retrieval tools.

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

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

The final sentence gives concrete trigger conditions: user asks where numbers come from, how fresh or complete they are, or how to cite. It does not explicitly name the sibling tools or state when NOT to use this, so it stops short of full 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?

Annotations already declare this as a read-only, open-world tool, so the description need not restate safety. It adds useful behavioral context by describing the historical statistics returned and by clarifying that the result is methodology/track-record information, not a single-token prediction.

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

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

The description is compact and front-loaded: the first sentence says what it explains and returns, the second says when to use it, and the third gives a scoping exclusion. Every sentence contributes useful information without repetition.

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

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

For a zero-parameter, no-output-schema tool, the description gives enough detail about the rating method, historical comparison, and usage boundaries. It could be slightly more complete by specifying the historical lookback window beyond 'past unlocks,' but the core behavior is clear.

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

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

There are zero parameters, so parameter semantics are not a meaningful source of ambiguity. The baseline for a zero-parameter tool is 4, and the description adds relevant context about what the tool evaluates without implying hidden inputs.

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: it explains the strong/medium/small rating and gives the historical unlock track record. It also explicitly distinguishes itself from a single-token forecast, so an agent can separate it from unlock tools that answer per-token questions.

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 use cases: when the user asks what 'strong' means, whether unlocks move prices, or how reliable the rating is. It also states a clear exclusion ('Not a forecast for any single token'), though it does not name the sibling tool to use for that forecast case.

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 readOnly/openWorld; the description adds genuinely non-obvious behavior: a 30-day look-back cap, coverage of 'a few dozen tokens, not the whole calendar', the covered_tokens field for discovery, and the disclosure that wallet roles marked 'our attribution' are analysis rather than project statements. Example findings show the output shape.

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?

It is a long description, but front-loaded with the core purpose and then the usage triggers, exclusions, and caveats in a sensible order. A few clauses (the parenthetical example findings, the repeated 'locked wallets' phrasing) could be trimmed without losing meaning.

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

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

No output schema exists, yet the description covers what comes back (per-token roles, outflows, mints/burns, next unlock per documents, a short finding, covered_tokens), plus limits on data source and time window. An agent can call this correctly and interpret the result.

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 still adds the preference ordering (ticker preferred over name or slug) and restates the empty-token behavior in context. It does not mention the days or lang parameters, which the schema already covers adequately.

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

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

The description opens with a precise verb+resource: on-chain state of a token's locked allocations, enumerating what that includes (vesting contracts, wallet roles, outflows, mints, burns, upgrades, next unlock) and the derived finding. It is unmistakable against siblings such as get_token_unlocks or get_dataset_info.

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 phrases are given ('are team tokens moving', 'did the unlock really happen', 'who is selling'), plus the no-token fallback ('recent movements across all covered tokens') and a direct redirect: 'For the unlock calendar use get_token_unlocks.'

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 read-only, open-world lookup, and the description adds substantial behavioral detail: the 60-day window, the contents of the result, the found=0 semantics, the onchain_check handoff, and the effect of lang=ru on page links.

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

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

The description is front-loaded with the core purpose and then adds only necessary operational details: accepted token formats, found=0 behavior, conditional follow-up, and language handling. Every sentence contributes useful guidance.

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 lack of an output schema, the description sufficiently explains what the result contains, how absence of unlocks is represented, and when to call get_onchain_check. For a two-parameter read-only lookup, nothing material 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 token parameter is already described in the schema, but the description adds concrete examples (ARB, Arbitrum, arbitrum). It also explains lang behavior beyond the enum/default by stating that lang=ru returns Russian page links.

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: scheduled unlocks in the next 60 days for one token. It also scopes the tool to a single token and mentions return contents, which distinguishes it from broader sibling tools like get_upcoming_unlocks.

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 clear context for use, including acceptable token formats, the non-error found=0 outcome, and a conditional next step to call get_onchain_check. It does not explicitly compare against get_upcoming_unlocks or state when not to use this tool, so it falls short of full alternative routing.

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 and openWorldHint, so safety is covered; the description adds valuable non-structured behavior: hourly refresh with data_updated_utc, result truncation to 'limit' with a 'matched' count for total filter matches, and the important coverage caveat that the futures filter only sees KuCoin and Binance USDT perpetuals. It stops short of describing ordering guarantees of the returned list beyond the sort param or any error/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?

Front-loaded with the core definition and scope, then usage examples, then routing to siblings — a logical order. It is fairly dense and the sibling-routing sentence plus the futures caveat could be tightened, but no sentence is pure 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 output schema, the description carries the burden of telling the agent what comes back, and it does partially: it names data_updated_utc and 'matched', and explains the strength rating. It doesn't enumerate the other per-unlock fields (token symbol, date, size), leaving some uncertainty about result shape.

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 83%, so most parameters are already documented, but the description adds meaning the schema lacks: what 'strong/medium/small' actually measures (size relative to circulating supply), the futures filter's exchange coverage limitation, the 30-day default vs 60-day cap implied by the look-ahead, and that lang=ru yields Russian page links. It does not add anything for 'limit' or 'days' 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 — a calendar of scheduled token unlocks within a bounded window — plus what each entry carries (strength rating relative to circulating supply). It is clearly distinct from the sibling get_token_unlocks (single-coin) and get_dataset_info (coverage), so an agent can route correctly 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?

Gives concrete example questions the tool answers ('biggest unlocks in November', 'strong unlocks with perpetual futures') and explicitly names the alternative for each adjacent need: get_token_unlocks for a single coin, get_method_and_track_record for rating meaning and history, get_dataset_info for coverage and sources.

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