ChainHelix for Machines

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

With readOnlyHint already declaring the safety profile, the description adds real context: data provenance ('read from its own onchain registration', permanent Greenfield evidence), explicit freshness semantics (probedAt/ageSeconds, ~2-3 minute sweep of the live set, rolling full-registry pass), and a per-call price of 5 cents. It is a substantial disclosure beyond annotations; only error/miss behavior for an unknown id is unaddressed.

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?

Information-dense with no wasted filler, and the core resource is front-loaded, but it is delivered as a single sprawling run-on sentence with semicolon-nested clauses that force re-reading. Pricing is tacked on at the end rather than structured separately. Content is valuable; packaging is poor.

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 spelled out, yet the description still enumerates the report's contents and explains the freshness fields. Provenance and cost are covered. Missing only edge-case behavior (invalid/nonexistent id) for a tool whose main risk is an empty 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% and the schema itself defines id as an ERC-8004 token id on BNB Smart Chain with an example (251399). The description adds no further meaning about the parameter, so the schema does the work and 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 resource (one agent's full report on BNB Smart Chain) and enumerates the payload: newest probe, probe history, test hires with result/latency/size/cost, Greenfield evidence, registration link, hire instructions. That is far more specific than the bare name. It does not name a sibling (agent_standing, search_agents, deep_report) to distinguish this from other agent-facing reads, so it stops short of a 5.

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

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

Usage is only implied: you need a single agent id when you want the complete dossier rather than a search or a standing snapshot. There is no explicit when-to-use, when-not, or named alternative among the many sibling tools (search_agents, agent_standing, verified_agents). The freshness explanation hints at when staleness matters but never states a selection rule.

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?

With readOnlyHint already present, the description adds substantial behavioral context beyond annotations: evidence sources, signed EIP-191 output valid 24 hours, special handling for ChainHelix agents as first_party with no verdict or signature, free unsigned access, and a 2-cent per-call price. It discloses cost, auth/signing requirements, and edge-case behavior clearly.

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 front-loads the core purpose and packs in relevant evidence, signature, pricing, and special-case details without obvious filler. It is dense and could be structured more cleanly, but each sentence contributes useful context for an agent deciding how to call it.

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 presence of an output schema, readOnlyHint, and full schema description coverage, the description supplies the missing behavioral context: evidence provenance, signature validity, pricing, and ChainHelix-agent handling. An agent has enough information to understand what the call returns and the operational constraints.

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 schema already defines id as 'the ERC-8004 token id on BNB Smart Chain.' The description reinforces that this is one agent and uses <id> in the free URL, but adds no format or validation detail beyond the schema, so the baseline 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: the standing of one ERC-8004 agent on BNB Smart Chain, with concrete evidence sources, a live probe check, and registry feedback rows. The word 'one' implicitly distinguishes it from bulk standing tools, though it does not explicitly name sibling alternatives such as standing_bulk or agent_report.

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 'one ERC-8004 agent' and the URL pattern for free unsigned access, but the description does not explicitly say when to use this tool versus standing_bulk, standing_watch, verified_agents, or agent_report. It gives context about ChainHelix agents and signature validity, but no direct tool-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?

Beyond the annotations, the description discloses critical behavior: the claim is sealed on opBNB, the exact commitment time is recorded, claim text and salt publish automatically at reveal, the attestation proves timing but not truth, and the tool costs 5 cents per call and is not covered by an API key. These details substantially exceed the structured annotations and do not contradict 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?

The description is front-loaded with the core sealing concept and then covers parameters, identity, mechanics, caveats, verification, and pricing. It is reasonably sized for a paid on-chain mutation tool, though the opening phrasing is slightly marketing-like rather than purely operational.

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 tool's complexity, the description covers what it does, how to call it, who the identity is, what is published at reveal, what it does not prove, cost, API-key limitation, and where to find the verification spec. An output schema exists, so return-value details are not required in the description.

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 both parameters, including ranges and defaults. The description repeats the payload and revealDelayHours semantics but adds no meaningful format or constraint beyond the schema, making 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 names a specific action and resource: sealing a claim commitment on the opBNB chain and revealing it later. It also distinguishes the tool from attest_spec by pointing to that sibling for verification. An agent can tell this is the create/attest operation rather than a status or list operation.

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 gives clear implied usage by explaining what to send and when a claim gets revealed, and it points to attest_spec for verification. However, it does not explicitly say when to use this tool versus attest_status, list_attestations, or list_reveals, so sibling routing remains mostly implicit.

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

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

readOnlyHint=true already declares this is a safe read, and an output schema covers the return shape, so the description only needs to add context. It contributes the set of tracked categories, but says nothing about refresh cadence, whether counts are windowed/all-time, or how 'gaps' is defined.

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 no filler; the resource is stated before the metric list, so an agent gets the gist immediately.

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, readOnly annotation, and an output schema, the description supplies nearly everything an agent needs to call it. The remaining gap is sibling disambiguation and the meaning/scope of 'gaps', which matters for interpreting results.

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; baseline credit applies. The enumerated count categories effectively describe the output dimensions even though no inputs exist.

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

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

Names a specific resource (attestation stream) and explicitly enumerates the metrics returned: committed, anchored, revealed, gaps. It does not, however, distinguish itself from near neighbors like attest_status, list_attestations, or session_stats, which an agent could easily confuse it with.

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

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

The word 'Live' and the aggregate-count framing imply a monitoring/polling use case rather than listing individual attestations, so usage is inferable. But there is no explicit when-to-use, when-not-to-use, or named alternative ('use list_attestations to see individual records').

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description doesn't need to re-establish safety. It adds genuinely useful context about what the payload contains — the hashing and on-chain verification procedure for sealed claims — but says nothing about whether the spec is static, versioned, or how large it is, which matters for a zero-parameter doc fetch.

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 fragment with no filler. It is efficient, though the fragment form (no verb) costs a little immediate readability compared with 'Returns the machine verification spec…'.

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 parameters and an output schema present, the description only needs to convey what domain of spec this is and why an agent would fetch it — which it does. The one missing piece is any cue about how this spec relates to the attest/attest_status workflow it describes.

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 at all, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly avoids inventing argument behavior for an argument-free call.

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

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

Names a specific resource — the machine verification spec for the attestation service — and scopes its contents (hashing of sealed claims, on-chain anchoring, independent verification). That distinguishes it from generic spec siblings such as instrument_spec or standing_spec. It never uses a verb ('returns'/'get'), so the agent must infer it is a retrieval tool, which keeps it below 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?

There is no guidance on when to call this versus the many adjacent siblings (attest, attest_status, attestation_stats, proof_spec, receipt_spec, delivery_spec). No preconditions, no exclusions, no mention that it is a read-the-docs style endpoint rather than an action.

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=true; the description adds genuinely non-obvious behavior: output is time-gated on reveal (receipt only before, claim text plus salt after), and nonce-keyed calls return a different payload including opBNB batch tx and Merkle path once sealed. That is useful behavioral context beyond the structured fields.

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, front-loaded with the core 'check one sealed claim' purpose and followed by the reveal-time and nonce variants. No filler, though the heavy domain jargon ('sealed', 'receipt', 'salt') slightly slows parsing.

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 shapes needn't be spelled out and the description still covers both call modes and the reveal-time visibility rule. Missing: the seq-vs-hash selection rule and error behavior (e.g., unknown seq/hash), which matter for a 4-parameter lookup.

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, but the description adds semantics the schema cannot express: nonce is not just another filter but a mode switch to paid-answer receipt lookup. It still doesn't state what happens if both seq and hash are supplied or neither is, despite tenant being the only required field.

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 (Check) and resource (one sealed claim) and clearly partitions the tool into two modes: lookup by tenant+seq/hash vs. a receipt lookup keyed by nonce. It doesn't name any sibling (attest, list_attestations, verify_reveal) so an agent still has to infer which of those this replaces, keeping it short of a 5.

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

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

The description explains the condition that switches behavior ('with a nonce it returns...', 'before reveal time... after it...'), which is real usage guidance for parameter-driven mode selection. However it never says when to prefer this over attest/verify_reveal/list_attestations, so sibling routing is left to inference.

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

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

Beyond the readOnlyHint annotation, the description discloses cost ('2 cents per call'), publication lag ('about 90 minutes after it ends'), and important output caveats such as valueEth null and count-only events. It also explains per-chain return semantics in detail, giving the agent rich behavioral context before calling.

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 purpose is front-loaded, but the body is a dense, semicolon-heavy block covering five chains, multiple value fields, freshness, pricing, and parameter behavior. The information is useful, but the structure is hard to scan and could be more concise.

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 an output schema exists, the description does not need to explain return values, yet it still supplies the key caveats an agent needs. It covers all l2 options, window constraints, freshness, cost, and count-only/value-null distinctions, so it is complete for correct invocation.

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, but the description adds meaningful semantics: it explains what each l2 value returns and clarifies that omitting l2 selects all five. It also reinforces window hours and adds the 90-minute publication lag beyond the schema's default and max.

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 and scope: 'Bridge activity over a window' across five named L2 bridges, with per-chain details. It is clear what the tool returns, but it does not explicitly distinguish itself from sibling flow/report tools such as stablecoin_flows or whale_flows.

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 'Read from the Ethereum side' and 'Read from the BNB Chain side', and it gives operational constraints such as default window, max window, and omitting l2 for all five. However, it does not say when to choose this tool over alternatives or name any sibling tools for comparison.

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=true, and the description adds genuinely non-structured facts: the output is a sampled series (not a full dump) with high/low/latest aggregates, and each call costs 2 cents. Cost disclosure is exactly the kind of behavioral context annotations cannot carry. Minor gap: sampling cadence/resolution is unstated.

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

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

Three short sentences, front-loaded with what the tool returns before constraints and price. The window default/max sentence partially duplicates the schema, which is the only waste.

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

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

For a one-parameter read-only tool with an output schema, the description supplies what structure cannot: sampled-series semantics, aggregate fields, and per-call price. Nothing essential to correct invocation is missing, though sampling resolution and the cheaper/more detailed alternatives are left implicit.

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 parameter already documents 'whole hours, 1 to 168, default 24, example 6'. The description repeats default 24 and max 168 without adding unit, format or edge-case meaning beyond the schema. Baseline 3 is appropriate when the schema does 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?

States a specific resource (Bitcoin mempool) with a specific shape: fastest fee, transaction count and size as a sampled series, plus window high/low/latest. An agent knows exactly what it returns. It does not name or distinguish itself from adjacent siblings such as congestion, gas_state or mev_pressure, which keeps it from 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 'over a window' framing (historical/aggregated mempool view) but there is no explicit when-to-use or when-not-to-use statement, and no alternative tool is named. The agent must infer that this is the time-series counterpart to the instantaneous mempool siblings.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds two genuinely non-schema facts: a per-call price of 2 cents and the 720-hour ceiling. It says nothing about data latency/freshness or whether the window aggregates into buckets, which matters for a time-windowed market query.

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 payload description leads and the parameter constraints follow. The pricing sentence is short and earns its place as cost information. No redundant restatement beyond the window bounds already in the schema.

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 return shape needn't be spelled out, and the single optional parameter plus readOnlyHint means little else is load-bearing. The only real gap is disaggregation guidance relative to the dense MEV sibling cluster.

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%: the window parameter is fully documented with range 1-720, default 24, and an example. The description restates the same hours/default/max facts rather than adding meaning such as how the window is anchored (rolling vs. calendar) or how larger windows affect sampling. 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?

Names a specific dataset (Ethereum block builder / relay market) and states the three things it returns: blocks delivered, value per relay, and top builders by blocks. That is a concrete verb-and-resource claim an agent can match to an information need. It does not distinguish itself from the many MEV-adjacent siblings (mev_intel, mev_bots, mev_pressure, mev_pool_check), leaving the choice to inference.

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

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

No explicit when-to-use, when-not-to-use, or named alternative. The only usage context is implicitly the word 'market' and the window parameter. With roughly a dozen MEV siblings in the list, some routing guidance would be the highest-value addition here.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description carries a lower burden. It adds the useful 'standing record on file' framing, but the returned fields it lists are largely restated by the output schema, and it says nothing about behavior for wallets with no record on file.

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 return contents come first and the usage hint follows; nothing is wasted. The trailing 'Send an EVM address' fragment is abrupt and slightly interrupts the sentence flow, keeping it at a 4.

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 spell out return values, and annotations cover the safety profile. Purpose, input, and usage context are all present; only the no-record-on-file behavior is left implicit.

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 one parameter at 100% schema description coverage, including format and an example address, so the schema does the work. 'Send an EVM address' in the description adds nothing beyond it, making the baseline 3 correct.

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 resource (the standing clearance on file for a wallet) and enumerates its contents: cleared buyer record, paid period, signed sanctions statement, renewal count and next renewal date. It is not a plain verb+resource sentence, so it stops short of a 5, but an agent can tell exactly what it retrieves.

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?

'Send an EVM address' gives the call shape, and 'A seller reads this before taking a job instead of paying for a screen' supplies a concrete trigger and names the alternative it replaces (paying for a screen, i.e. the screening siblings like screened_payer). It stops short of naming when-not conditions or a sibling by tool name.

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=false), it discloses a non-obvious behavioral trait: today no order is created and the call effectively fails, and when a sale is live it issues payment address + claim token. It omits auth/permission requirements and whether repeated calls create duplicate orders.

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 critical fact (not on sale) is front-loaded, which is good, but the second half is one long clause dense with parenthetical per-chain currency lists that is hard to parse. Several clauses could be tightened without losing information.

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

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

With an output schema present and full schema coverage, the description needn't explain returns, yet it does describe address/amount/claim token, plus the current failure mode — enough for an agent to call it and interpret the result 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 the enum values are already documented; the description still adds real meaning by mapping each chain to its accepted stablecoins (bnb: USDC/USDT/USD1/U, tron: USDT, sui: USDC, etc.), which is not in 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 concrete verb and resource (buy an API key) and explains the artifact produced (payment address, exact stablecoin amount, claim token for the chosen plan/chain). It doesn't name a sibling like claim_key or key_order_status, so the boundary with those tools is left 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?

It clearly establishes the current state (purchases are unavailable, every plan answers 'This plan is not on sale.') which tells an agent when NOT to expect success, but it never states when to prefer this over hire_quote, claim_key, or key_order_status.

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

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

Annotations already declare readOnlyHint=true, so the description isn't burdened with safety signaling. It adds genuine context: 'up to 500 candles newest last' discloses result ordering and cap, and 'Price: 2 cents per call' surfaces a cost the agent would otherwise not know.

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 with the resource front-loaded, followed by ordering and cost clauses. Every clause earns its place; no repetition of schema content.

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?

Output schema exists so return values needn't be explained, and annotations cover safety. The description supplies ordering, cap, timeframes, and pricing, leaving only defaults (in schema) unmentioned – nearly complete for a simple 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%, so chain, limit, and timeframe are fully documented in the schema. The description adds only the ordering detail ('newest last') beyond the schema's per-parameter docs, so 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?

Names the specific resource (open/high/low/close/volume/trade-count candles) for one chain, which distinguishes it from the sibling 'prices' tool by specifying bar granularity. An agent can tell what it returns 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 conveys the scope ('for one chain') and the timeframe range, but never explicitly states when to choose this over siblings like 'prices' or 'market_state', nor any when-not conditions. Usage is implied rather than guided.

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

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

readOnlyHint=true already covers the safety profile, and the description adds meaningful context beyond annotations: per-call cost (5 cents), the partial-failure contract (failed sections appear in an 'unavailable' field), and the bitcoin-only mempool caveat. It does not disclose latency or how the cost is metered/charged for failed sections, which would have pushed this higher.

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 that front-loads the value proposition ("the whole read in one answer") before the section list, followed by a short failure-mode clause and the price. The enumeration is long but each item distinguishes the tool's payload, so it earns its space; a minor trim would improve scanability.

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 annotations covering read-only safety, an output schema covering return shape, a fully documented single parameter, and description coverage of contents, cost, and partial-failure behavior, an agent has everything needed to decide to call this 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 description coverage is 100% with a single enum-constrained parameter, so the schema already fully specifies the chain argument. The description adds no syntax or naming guidance beyond the schema beyond mentioning the bitcoin mempool special case, 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 and resource - a single call returning the complete read for one chain - and enumerates every section it aggregates (market state/momentum, price walls, large transfers, bot activity, open interest, stablecoin flows, bitcoin mempool). That enumeration makes it unmistakable against siblings like wall_map, whale_flows, mev_bots, open_interest and btc_mempool_history, which each return only one of these sections.

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?

"One chain, the whole read in one answer" clearly establishes the aggregation use case, implying this is the overview tool rather than the specialized single-section siblings. It does not explicitly name those alternatives or state when not to use it (e.g. when only one metric is needed), 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 a non-read-only, non-destructive, idempotent mutation, so the bar is lower. The description genuinely adds beyond them — the key is returned exactly once and must be saved, and claimability lags on-chain confirmation by ~30 minutes — but the leading sentence asserting there is "no key to claim" contradicts the tool's own behavior and could cause an agent to skip a valid call.

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 two middle sentences earn their place (purpose plus one-time delivery), but the opening unavailability notice is confusing, appears stale, and is front-loaded where the actual purpose should be. The timing note trails without terminal punctuation and could be attached to the claimability sentence it belongs with.

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 one fully-documented parameter, annotations, and an output schema, the description covers what the agent still needs: the prerequisite order state, the one-shot nature of the returned key, and the confirmation latency. Only the self-defeating opening sentence keeps it from being wholly adequate.

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 single claim_token is 100% documented in the schema, including the 32-hex-character format and an example, so the baseline is 3. The description only says "Takes the claim token," restating the schema rather than adding meaning such as where the token comes from or how to recover a lost one.

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 operative sentence — "Claim the API key for a paid buy_key order" — gives a specific verb, resource and prerequisite, and names the sibling that produces the order (buy_key). But it is preceded by "API keys are not on sale at the moment and buy_key creates no order, so there is no key to claim," which tells the agent the opposite of what the tool is for and buries the real purpose in second position.

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 implies the precondition (a paid buy_key order) and the timing expectation ("claimable within 30 minutes of confirming on chain"), which is useful context for choosing this tool. It never points to key_order_status or state what to do if the order is unpaid, and the opening sentence's claim that nothing is claimable muddies rather than clarifies when to call it.

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

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

Beyond annotations (readOnly=false, idempotent=false) it discloses that the operation costs $2 per call, covers 30 days, renews the signed statement every 24 hours, and that the same payment never double-credits, plus that a ChainHelix API key does not cover this tool. What it does not fully clarify is exactly what the signed statement contains or its lifetime if not renewed, so a 4 rather than 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?

It is front-loaded with the core purpose and pricing, and each sentence (screening, renewal cadence, free reader, extension, no double-credit, wallet-only, price, key exclusion) adds required operational detail. It is somewhat dense across seven clauses, but nothing is clearly 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 a single optional parameter, full schema coverage, an output schema, and annotations, the description supplies the payment, renewal, idempotency, and eligibility constraints an agent needs before calling. It also points to the free sibling for reading the result, so it is complete for this tool's complexity.

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?

Only one parameter (network) exists and the schema already documents it at 100% coverage, including the CAIP-2 format, 40-character limit, and default eip155:56. The description adds no extra meaning about the network parameter beyond the schema, so the baseline 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: it places a standing sanctions clearance on file for the buyer's wallet after screening against the OFAC SDN list and on-chain oracle. It explicitly distinguishes itself from the free sibling buyer_clearance, so an agent can tell the paid action apart from the free lookup without opening a 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 concrete conditions: call this to buy/extend a clearance, call buyer_clearance (free) to read the current statement, and call again to extend the 30-day period. It also states the exclusion that a key id cannot be cleared and that the paying wallet is the one screened, leaving little 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful cost context with "Price: 2 cents per call," but does not disclose update cadence, rate limits, or other behavioral details beyond the annotation.

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

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

The description is short and front-loaded: it states the data returned, then appends the price. Every sentence earns its place, and there is no redundant restatement of the tool name.

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, read-only annotations, and an output schema present, the description is largely complete. It clearly identifies the returned metrics and cost, though it could mention freshness or source cadence for fuller operational context.

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 has zero parameters, so there is no parameter semantics burden. The description correctly focuses on what the tool measures rather than inventing input details.

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 and metric: Bitcoin queue depth now versus the past 30 days, plus the current fastest fee. It is clear what the tool returns, though it does not explicitly distinguish itself from related siblings such as btc_mempool_history or gas_state.

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 gives no explicit guidance on when to use this tool versus alternatives. Usage is only implied by the metric description, and the pricing note does not help an agent decide between this and related data tools.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful behavioral context by disclosing the per-call price and the nine-chain scope, but it does not cover payment/auth requirements or return behavior details.

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, front-loaded with the purpose and followed by the key parameter and cost. Nothing is wasted, and the pricing note earns its place for a paid tool.

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, and the input schema covers the lone parameter, so return-value and parameter detail need not be repeated. The description adds scope and price, which are important for a paid read tool; only the payment/auth mechanism is left implicit.

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 single window parameter is already fully documented in the schema. The description repeats the default and maximum but adds no syntax or meaning beyond the schema, and it even omits the schema's minimum of 2; 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?

The description states a specific computation and data scope: pairwise correlation of hourly returns across nine chains. This is clear enough to distinguish it from price, candle, and market-state siblings, though it does not explicitly name or contrast any alternative tool.

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 supplies a default window and maximum but gives no guidance on when to use this tool versus alternatives, nor any when-not conditions. The purpose implies correlation analysis, but usage is not explicitly framed.

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?

With readOnlyHint=true already indicating a safe read operation, the description adds useful behavioral context: the result is one daily hash, it covers specific record classes, and it is tied to storage on BNB Greenfield with a root sealed on opBNB. It does not cover auth, rate limits, or behavior when a date has no digest.

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 two front-loaded sentences with no filler. The core artifact and date behavior are both stated efficiently.

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 and annotations already establish read-only behavior, so the description need not explain return structure. It provides the key content and provenance context, though it leaves edge cases such as missing days or inaccessible records 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 description coverage is 100%, and the schema already documents the date format, default behavior, and an example. The description repeats the optional YYYY-MM-DD date and latest-day default without adding materially new parameter semantics.

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

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

The description identifies a specific artifact: a daily Merkle digest covering reveals, hire deliverables, and verification records stored on BNB Greenfield, with its root sealed on opBNB. That makes the resource clear, but it does not explicitly distinguish this tool from siblings such as list_reveals, verified_delivery, data_changelog, or freshness.

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 only usage cue is that the date parameter defaults to the latest day. The description does not say when to choose daily_digest over alternative tools, nor when not to use it.

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

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

The readOnlyHint annotation already tells the agent this is a safe, non-mutating read, so the bar is lower. The description does add value by naming what each entry carries (date, tools affected, count) and the categories of change, but it says nothing about ordering, volume, or how far back the log goes.

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 single front-loaded sentence that identifies the resource first, then enumerates contents, then parameters. The mid-sentence list of change types runs slightly long but every element is informative.

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, full parameter documentation, and readOnlyHint already in structured fields, the description only needs to convey what the log is and how to narrow it, which it does. Nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters are already fully documented in the schema. The description's 'optional tool name to filter, and limit' merely restates them without adding format or behavioral detail, 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 dated changelog of data changes sold by this server) and enumerates the kinds of entries it contains, so an agent knows exactly what it retrieves. It does not name or contrast any sibling tool, which is the only thing keeping it from 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 only implied: an agent can infer it should call this to audit historical data changes, and the description notes an optional tool filter. There is no explicit statement of when to use it versus related tools (e.g. freshness or daily_digest), nor any exclusion 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 readOnlyHint=true, so safety is covered and the bar is lower. The description still adds real value: it discloses per-call cost (25 cents) and that responses include on-chain verification links, plus the aggregate nature of the output. It says nothing about latency, snapshot vs live refresh, or size of the payload — notable for an 'everything in one call' aggregate.

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?

Single sentence, front-loaded with 'the complete nine chain research brief in one call', with the cost caveat placed last where a decision factor belongs. The content enumeration is long but every item is a distinct payload component, so it earns its space, though the list could be trimmed slightly.

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-required-param read-only aggregate with an output schema and full schema coverage, the description covers contents, cost and verifiability, which is enough to call it correctly. The remaining gap is how this differs operationally from the other report-type siblings (chain_brief, situation_report, daily_digest) in scope and cost.

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 chain parameter has a documented enum and example, so the schema does the work. The description's only nod to the parameter is 'nine chain', which hints the scope is chain-wide but adds no format or behavior detail beyond the schema. 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 concrete composite resource — a full research brief covering market report, signal stream, correlations, options volatility, session stats and proof counters — and positions itself as 'the most complete single answer this server produces', which implicitly distinguishes it from lighter siblings like chain_brief or situation_report. It never names those siblings explicitly, so the differentiation is inferential rather than stated.

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

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

Usage is only implied: the tool is the 'most complete single answer' and costs '25 cents per call', which hints it is the expensive exhaustive option, but there is no explicit 'use this when you need everything; use chain_brief for a scoped subset' routing. The price disclosure is a useful decision signal but the agent must infer the alternative from sibling names.

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

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

readOnlyHint=true already tells the agent this is a safe read, and the description correctly reads as reference material with no side effects, so nothing is contradicted. It adds content scope (canonical form, hash, calldata, step-by-step checks) but no operational detail such as whether the returned steps are chain-specific or versioned.

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 that leads with the agent's goal ('verify a sealed delivery claim yourself') and then lists the sections covered. It is dense but every clause names real content, with only mild run-on compression.

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 documentation tool with an output schema, the description covers what the document contains, so an agent knows roughly what it will get back. What is missing is positioning within the cluster of sibling spec and status tools, which matters here because several near-identical names exist.

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 the description needs to disambiguate; baseline 4 applies. The description correctly implies a parameterless lookup rather than a filtered 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?

The description enumerates the content (canonical form, hash, opBNB calldata layout, check semantics, repeatable steps), which tells an agent this is a verification reference document. But it never says outright that the tool returns a spec, and it does not distinguish itself from the many sibling spec tools (proof_spec, receipt_spec, attest_spec, mev_flow_spec).

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

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

There is no 'use this when...' guidance, no exclusions, and no pointer to the alternatives an agent should consider instead. The phrase 'verify a sealed delivery claim yourself' implies a context, but the relationship to delivery_status or verified_delivery is left to inference.

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

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

Goes beyond readOnlyHint=true by disclosing the return payload (claim, its hash, the opBNB transaction once sealed), the pre-charge refusal on missing claims, and the cost of 1 cent per call. Pricing and failure behavior are exactly the kind of context 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?

Three short sentences, front-loaded with what the tool returns before the identifier options. 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?

An output schema exists so return shape needn't be spelled out, and the description still covers cost and refusal behavior. A note on precedence when multiple keys are supplied would close the remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the meaningful 'or' semantics — any one of the three optional keys identifies the claim — which the all-optional schema does not resolve on its own.

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 resource (sealed delivery claim for a hire) and the retrieval keys, plus what is returned. It does not differentiate itself from nearby siblings such as verified_delivery or delivery_spec, so an agent must infer which one to call.

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?

Explains how to invoke it (any of job id, seq, or claim hash) and an edge case (no claim on record is refused before any charge), but gives no guidance on when to prefer this over delivery_spec or verified_delivery. Usage is implied rather than directed.

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

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

Annotations only declare readOnlyHint=true; the description adds real behavioral context beyond that: ordering (newest first), exact-match semantics for signalTs, default/max page size, and an explicit pricing model of 1 cent per call. That cost and ordering information is valuable and not in the structured fields.

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-block that front-loads the purpose and field list before the filtering and cost notes. Nearly every clause carries information, though it is somewhat long and could separate the pricing note for scannability.

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 readOnly annotations and an output schema present, the safety and return-shape burden is covered. The description still adds the pricing and ordering context an agent needs to choose this tool and size its call 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 the schema already documents all three parameters including types, examples, and the enum. The description echoes limit default (50) and max (500) and the absent-means-every-instrument default, adding only marginal detail 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?

Specific verb (exchange fill receipts) plus resource (instrument lane) and ordering (newest first). It enumerates the returned fields, making the purpose unambiguous, though it doesn't explicitly contrast with nearby siblings like verify_fill or receipt_spec.

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?

States the optional filters (instrument, signalTs) and pagination bounds, implying how to narrow results, but never says when to use this versus receipt_spec or verify_fill. Usage is inferred rather than directed.

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

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

Beyond readOnlyHint=true, it discloses the free/no-cost behavior and explains how tools needing arguments are represented (requiresArguments) and where a hash lives for paid answers (meta.contentHash). This is meaningful context an agent would not get from annotations alone.

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-loads the core pitch ('Free check before you pay') and each subsequent sentence adds a distinct piece of information. Slightly dense but no wasted sentences.

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 values needn't be spelled out, and the description covers the key edge cases (requiresArguments, per-answer contentHash). It gives an agent enough to call correctly, though it could note it covers 'all chains' scope more explicitly relative to filtered siblings.

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 schema already documents 'omit for all,' so the description's 'Optional name for one tool' adds little. It does clarify the omit-for-all semantics implicitly, keeping it at baseline rather than below.

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 (check) and resource (freshness/content hash + validUntil of default results), and frames the value proposition ('free check before you pay'). It clearly differs from paid data siblings, though it never names a specific sibling tool it substitutes for.

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 a strong when-to-use rule: check this before buying, and if the hash matches, 'there is nothing to buy.' It also explains the requiresArguments edge case for tools without default results. It stops short of explicitly naming a sibling alternative.

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

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

readOnlyHint=true already establishes the safety profile, and the description adds genuinely non-obvious context: a per-call cost of 2 cents and the fact that values are reported against a 24-hour average (so figures are comparative, not absolute). It stops short of disclosing refresh cadence or whether the cost applies to the all-chains call.

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

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

Three short sentences, front-loaded with the resource and metrics, then the scoping rule, then cost. No filler. Slightly dense in the metric enumeration but every element is load-bearing.

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 format need not be explained, and the single optional enum parameter is fully covered by schema plus the 'omit for all nine' note. Cost and the comparative 24h framing are supplied. Only marginal gaps remain, such as update cadence and whether the 2-cent cost is per chain or per 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?

Schema coverage is 100% and the enum already lists all nine chains with an example, so the schema does the heavy lifting. The description's 'omit chain for all nine' reinforces the optional default but adds no format or semantic detail beyond what is already structured. 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?

Names a specific resource (network load / gas state per chain) and enumerates the exact metrics returned: transaction count, MEV count and rate, average gas, large transaction count, plus the 24h baseline comparison. An agent knows what data comes back, though nothing distinguishes it from near-neighbours like market_state, congestion, mev_pressure, or freshness.

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?

'Omit chain for all nine' explicitly documents the no-argument behavior, which is real usage guidance for the only parameter. However, there is no statement of when to prefer this over siblings such as congestion or mev_pressure, and no exclusions or prerequisites beyond the price note.

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

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

Annotations declare readOnlyHint=true, and the description adds important context: each proposal is counted once at latest state, recording occurs on state/vote/score change and at least every 6 hours, and price is 2 cents per call. It stops short of describing auth or rate limits beyond price.

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 dense but front-loaded with the core data scope; each sentence adds information about states, ordering, recording cadence, or price. It could be slightly tighter but no sentence is wasted.

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 an output schema and full parameter schema, the description covers the data semantics, freshness, and pricing needed to call the tool. The main gap is not explaining limit's role in returning multiple spaces.

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 repeats space and window examples already in the schema and does not mention the limit parameter, which controls the number of spaces returned.

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 specifies the exact resource (Snapshot DAO proposals per space), the window, and the breakdown by state and vote count, leaving no ambiguity about what the tool returns. It is a precise data query even without a sibling to contrast.

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 provides clear context—per-space governance activity within a window—but does not explicitly state when to use it versus alternatives or when not to use it. With no direct sibling tools, this is adequate but not maximally directive.

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

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

Annotations declare readOnlyHint=true, and the description is consistent and additive: 'Deterministic arithmetic, no custody, no execution' explains why the call is read-only, while disclosing the downstream flow (wallet-signed quote, escrow funding, createJob calldata to sign from the caller's wallet) and the cost boundary. That is exactly the extra context annotations cannot carry for a planning tool that fronts an on-chain hire.

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 capability and output shape, then layering the caveats and the hire flow in a sensible order. It is dense and runs long for a single description, but nearly every sentence carries non-redundant information (scope, exclusions, cost, calldata handoff), with only minor repetition around the free/paid distinction.

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 9-parameter tool with nested objects and a single readOnlyHint annotation, the description supplies what the structured fields cannot: the computational model, what is deliberately not computed, the settlement flow, and the caller's responsibility to sign from their own wallet. An output schema exists, yet the description still usefully sketches the return (live quote plus createJob calldata), leaving nothing an agent needs to call it correctly 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 description coverage is 100% and every property already documents defaults, ranges, aliases and the spanPct-vs-lower/upper interaction, so the structured data does the heavy lifting. The description adds only a framing note ('The parameters here are exactly what the agent accepts') and points to the example rather than restating field semantics, which matches the baseline-3 case for high-coverage schemas.

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 ('Plan a hire of the ChainHelix gridtrader agent') and immediately pins down the output shape: a symmetric buy/sell grid with buy levels below and sell levels above the mark price, equal USD size per level. Naming the agent identity (ERC-8004 #269224, Grid trading ladder) distinguishes it from the sibling hire_plan_healthmon/rebalancer/yieldopt tools without the agent needing to open their schemas.

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?

Clearly frames the use case and explicitly excludes adjacent intent with 'Not a bounded-loss or profit-target strategy: fees, slippage, gas and PnL are not computed,' which keeps the agent from hiring this planner for risk-managed strategies. It also sets the free-vs-paid expectation ('This call is free; the job is not'). It stops short of naming the sibling planners as alternatives for those excluded cases, so routing is implied rather than explicit.

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=true, but the description adds substantial behavior: deterministic arithmetic, no custody, no execution, a live wallet-signed quote, the createJob calldata to sign from your own wallet, and that this call is free while the job costs money. These are exactly the facts an agent needs to understand what the call does and does not do.

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 front-loaded with the two modes and the core economics, and most sentences earn their place. It is somewhat dense and mildly repetitive (mode rules echoed in schema, two phrasings of 'one question per job'), but not padded.

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 complex, nested, two-branch tool with a funding/escrow flow, the description covers the modes, the one-question rule, the free-vs-paid distinction, and the post-call signing steps, and it defers the example to the schema description. An output schema exists, yet the description still usefully explains what comes back (quote + calldata). Nothing an agent needs to call it correctly appears to be 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 schema already documents both the anyOf branches, aliases, defaults, and nested shapes. The description restates the either/or (collateral+debt+prices vs position) and points to the example in the schema, but adds no parameter syntax or format detail beyond what the schema carries. 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?

The description names a specific verb and resource — 'Plan a hire of the ChainHelix healthmon agent (ERC-8004 #269228, Position health report)' — and immediately pins down the two modes it computes: lending health and LP range health. The agent name plus the 'health report' framing distinguishes it from the sibling hire_plan_gridtrader/rebalancer/yieldopt tools without needing their schemas.

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 per-mode conditions ('given collateral rows...' vs 'send `position` {price, lowerPrice, upperPrice} instead of collateral and debt') and a hard constraint, 'One question per job.' It also clarifies the free-call vs paid-job economics. It stops short of naming when to prefer this over the other hire_plan_* siblings, so it is clear context but not a full alternative-routing guide.

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?

Adds substantial context beyond readOnlyHint: true — deterministic arithmetic, no custody, no execution, a free quote call versus a paid on-chain escrow job, and the fact that signing happens from the caller's own wallet. These details are consistent with the read-only annotation because the call itself only returns a quote and calldata.

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?

Purpose is front-loaded in the first clause and the cost/workflow warnings earn their place. The middle sentence enumerating return fields overlaps with the existing output schema and the closing pointer to the schema example is largely redundant, so it is informative but not maximally tight.

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, a full-coverage schema with example, and an output schema, the description covers everything else an agent needs: cost model, non-custody guarantees, the two-phase hire workflow, and what will come back in the response.

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

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

Schema description coverage is 100% and the schema already carries aliases, defaults, vocab mappings and a worked example. The description's only addition is the meta-statement that these are exactly the parameters the agent accepts, which adds little meaning beyond the structured field.

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 — plan a hire of the ChainHelix rebalancer agent for a portfolio rebalancing job — and previews the exact deliverable (current vs target weights, drift, ordered trade list). It is clearly distinguishable in substance from siblings like hire_plan_gridtrader or hire_plan_yieldopt, but never names or contrasts those alternatives 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?

Gives clear operating context: send job parameters, receive a wallet-signed quote plus createJob calldata, then fund and notify the agent, and warns that 'this call is free; the job is not.' What is missing is when a caller should pick this tool over hire_plan_gridtrader/hire_plan_yieldopt or hire_quote, and any preconditions (e.g., that targets must sum to 1 is left to the schema).

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?

Goes far beyond readOnlyHint=true by stating 'Deterministic arithmetic, no custody, no execution' and clarifying the money flow: the call is free but funding pays the job price into on-chain escrow, signed from the caller's own wallet. It also discloses determinism and the existence of follow-up steps, which the annotations cannot convey.

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

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

Front-loads the purpose and the distinguishing domain in the first clause, then moves to inputs, outputs, and cost model. It is dense but nearly every sentence carries information; the closing note about parameters matching the agent's accepted schema and the example pointer is mildly redundant with the schema itself.

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 inputs, output shape (allocation per pool, blended APY, unallocated capital), cost, and the funding handoff, all for a tool that also has an output schema. Remaining ambiguity is mainly verb-level operational detail (how/where to sign and fund), which it defers to 'steps in the answer'.

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 defaults and aliases documented per property, so the baseline is 3. The description adds real semantics by grouping the inputs into candidate pools (APY, optional TVL, risk score) and the capital to place, and by tying caps (concentration and TVL-share) to their effect on output, though it does not restate units or bounds itself.

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

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

States a specific verb+resource ('Plan a hire of the ChainHelix yieldopt agent'), names the agent by ERC-8004 id, and defines its domain ('Yield allocation across pools'). That implicitly separates it from sibling planners (gridtrader, rebalancer, healthmon) without naming any of them explicitly, so differentiation is inferred rather than spelled out.

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?

Lays out the workflow clearly: send parameters, receive a live signed quote plus createJob calldata, then fund from your own wallet and notify the agent ('steps in the answer'). Adds a useful cost cue ('This call is free; the job is not'). It never contrasts with hire_quote or the other hire_plan_* planners, so no explicit 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?

readOnlyHint=true already tells the agent this is a non-mutating call, and the description reinforces that by framing the output as 'steps to fund the job' rather than funding it. It adds genuinely new behavioral data the annotations don't carry: a cost of 2 cents per call and the eligibility constraint that the agent must be listed as hireable. It does not say what happens when the id is not hireable or when terms are omitted.

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 sentences, front-loaded with what the tool returns, then the eligibility constraint, then the price. No sentence is redundant and the most decision-relevant facts (it's a quote, it's restricted to hireable agents, it costs money) come first.

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

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

An output schema exists so return values needn't be described, and all three params are documented. The description supplies the safety/eligibility context and pricing an agent needs before calling. The one remaining gap is discoverability: it says agents must be hireable without pointing to the tool that yields a hireable id.

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

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

Schema coverage is 100%, so every parameter is already documented with types, examples and defaults (including the default terms object). The description only restates 'task description and terms' without adding format or constraint 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 and resource: obtain a live signed ERC-8183 quote from a hireable agent on BNB Smart Chain, including the offer envelope and funding steps. The purpose is unmistakable, but it never names the obvious siblings (search_agents, verified_agents, hire_plan_*) so the agent must infer its niche from the surrounding tool list.

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 through the flow 'send your task description and terms, receive the signed offer envelope,' and it gives one precondition: 'Only agents the live map lists as hireable.' However it never says how to discover a hireable agent id (presumably search_agents/verified_agents) nor when to prefer hire_plan_gridtrader and friends over this generic quote.

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

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

readOnlyHint=true is consistent with a static reference list, and the description adds genuine context: it is the canonical source of 'the label every answer uses' and clarifies these are derivatives on the venue, not equity shares. It does not say whether the list changes over time, whether it requires authentication, or how it relates to the live-state sibling — modest but real added value over the annotation.

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

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

Front-loaded with the resource and kept to two sentences plus a short clarifying fragment — appropriately sized for a parameterless catalog tool. The phrase 'the label every answer uses' is slightly cryptic and the final sentence is telegraphic, but neither adds bloat.

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 an output schema present, the description needn't explain return values, and it does convey the domain (SpaceX/Circle perpetuals on Aster, BNB Chain). What is missing is the relationship to instrument_spec and instrument_state — the single question an agent will actually have when four instrument-prefixed siblings are listed.

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; baseline 4 applies. The prose field list (venue, contract, chain, fees, funding cycle, session policy) loosely maps to what the response carries, though the output schema already covers that.

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 resource (the instrument list for the ChainHelix instrument lane) and enumerates the fields returned: venue, contract, chain, fees, funding cycle, session policy. It does not, however, distinguish itself from near-identical siblings such as instrument_spec, instrument_state, or instrument_signals, so an agent must guess which of the four to call.

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

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

No when-to-use guidance and no named alternatives despite four closely related sibling tools (instrument_spec, instrument_state, instrument_signals, verify_instrument_signal). The description never says whether this is the reference catalog to consult first, or how it relates to the live-state or per-instrument lookups.

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

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

Annotations only declare readOnlyHint; the description adds real behavioral context: results come newest first, an entry lacking a seq predates the stream or is uncommitted, and each call costs 2 cents. The pricing disclosure is especially valuable and cannot be inferred from structured fields. It stops short of describing pagination or the attestation stream's failure modes.

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-loads the resource and ordering, then packs scoping, edge-case semantics, and price into a few dense sentences. Slightly cluttered by the parenthetical about the venue and by restating schema defaults, but nothing is wasted.

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 shapes needn't be spelled out; the description covers ordering, the null-seq edge case, and cost. What remains thin is how it relates to sibling signal tools, which is the only real gap for an agent deciding whether to call it.

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

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

Schema description coverage is 100%, so both parameters are already fully documented with types, bounds and examples. The description's mention of 'optional instrument id and limit (default 50, max 500)' repeats the schema rather than adding format or semantic 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 ('instrument lane signals'), plus the venue (paper book, BNB Chain) and that each entry carries its commit status in the CHXI attestation stream. It doesn't explicitly differentiate itself from the nearby 'latest_signals' sibling, which keeps it from a 5.

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

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

The only guidance is 'Optional instrument id and limit (default 50, max 500)', which merely restates the schema. There is no statement of when to use this instead of 'latest_signals', 'instrument_state', or 'verify_instrument_signal', nor when not to use it.

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

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

The readOnlyHint annotation covers the safety profile, and the description adds context about the spec's contents (canonical forms, hashes, etc.). However, it does not describe the format of the output or whether it is static documentation, leaving some behavioral aspects unaddressed.

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 a single sentence that front-loads the core purpose and enumerates key topics without any filler. Every phrase contributes to understanding what the spec covers.

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 low complexity (no parameters), the presence of an output schema, and the read-only annotation, the description provides enough context about the spec's scope. It could be improved by explicitly stating that this is a reference document and clarifying its relationship to sibling verification tools.

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 has zero parameters, so there is no parameter semantics to document. The description appropriately does not mention parameters, and the schema is complete with additionalProperties false.

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 the tool's purpose as providing information on how to verify an instrument signal commit and a fill receipt, listing specific topics (canonical forms, hashes, calldata layouts, reveal rule). It is clear but does not explicitly distinguish itself from sibling spec tools like receipt_spec or proof_spec.

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

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

There is no explicit guidance on when to use this tool versus alternatives, such as verify_instrument_signal or verify_fill. The phrase 'yourself' hints at manual verification, but the description does not state prerequisites or conditions for use.

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=true, so the description adds real behavioral value: it discloses cost ('1 cent per call'), the presence of contentHash/validUntil meta enabling staleness detection, and that feed health and age are part of the payload (i.e., data may be stale). It does not cover auth/paid-access mechanics or error behavior, keeping it short of 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?

It is front-loaded with the returned fields, which is the right ordering, and every clause conveys substance. But it is delivered as one dense run-on with nested colons that is hard to parse, and the heavy field enumeration partially duplicates the output schema.

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?

Since an output schema exists, the long field inventory is somewhat redundant, while things an agent genuinely needs—how this differs from instruments/market_state/prices, and the payment/auth path implied by '1 cent per call'—are absent. Cost and freshness-meta disclosure are good additions, so it is adequate but with clear gaps.

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

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

Schema description coverage is 100% and the single parameter carries an enum and an 'absent = every instrument' explanation in the schema, so the baseline of 3 applies. The description's 'Optional instrument id' merely restates the schema without adding syntax, defaults, or examples.

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 resource (per-instrument state) and enumerates exactly what it contains: mark, index, basis in bps, funding rate and next funding time, spread, 24h volume, feed health/age, plus reference spot pricing and US equity session. An agent can tell this is a live snapshot tool rather than a historical or signal tool. However it never names or contrasts the near-duplicate siblings (market_state, prices, instruments, instrument_signals), so differentiation is left to inference.

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: 'Optional instrument id' signals you may scope to one instrument or fetch all, and the note that it 'carries meta (contentHash, validUntil) so freshness can tell you when nothing changed' hints at a poll/conditional-refresh workflow with the freshness tool. There is no explicit when-to-use vs. market_state/prices/instruments guidance and no exclusions or prerequisites.

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

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

readOnlyHint=true already covers the safety profile, but the description adds a genuinely useful non-schema behavior: a price of 2 cents per call, which tells the agent this is a paid endpoint. It does not disclose refresh cadence, latency, or whether the week-ago comparison is fixed or rolling, so it is adequate rather than rich.

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, metric and scope first, cost second. Nothing is wasted and the key information is front-loaded.

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 need not be explained, and the zero-parameter schema means there is nothing else to document. The only real gap is operational context — update frequency and whether the cost applies per call or per session — so it is nearly but not fully complete.

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; baseline 4 applies. The description correctly implies the asset scope (BTC and ETH) and timeframe rather than leaving the agent to guess what a parameterless call returns.

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 resource and metric: near-term option implied volatility for BTC and ETH, with a now-vs-one-week-ago comparison. That is a clear verb-less but concrete read tool. It does not distinguish itself from the adjacent sibling options_skew, so it stops short of a 5.

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

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

There is no statement of when to call this instead of options_skew, instrument_signals, or market_state, and no prerequisites or exclusions. The agent must infer usage purely from the metric name.

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

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

readOnlyHint=true is consistent with 'check' and 'reports'. The description adds real behavioral detail beyond annotations: the two status facts returned (payment seen, key ready to claim). It does not cover error behavior for an unknown/expired token, so it does not earn a 4.

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 front-loaded sentence is self-defeating: it announces there is no order to check and then instructs the agent to check an order. Three sentences for one parameter, with internal redundancy and no clear lead statement of what the tool does.

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 values need not be spelled out, and the description does sketch the two reported facts. What is missing is the token lifecycle context: what a claim token represents, and what an agent should do if the check fails.

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 claim_token parameter is fully documented (32 hex characters, example). The description only restates 'takes the claim token' with no added semantics, 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 second sentence gives a specific verb and resource: check a key order created with buy_key, reporting payment-seen and claim-readiness. However, the opening sentence ('keys are not on sale... there is no order to check') directly muddles that purpose, leaving the agent unsure whether the tool is usable at all.

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 names buy_key as the creating tool and states a when-not condition (no orders currently exist), which is genuinely useful routing context. But the two statements conflict, and it never tells the agent what to do instead when an order is absent.

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 readOnlyHint annotation: it explains that signals are sealed on opBNB before outcomes exist, typically within 5 minutes and at most about 30 minutes, and cannot be edited afterward. It also clarifies sealedAt versus committedAt and discloses the 6-cent-per-call price, giving the agent unusually rich operational context.

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 packs useful detail into a single paragraph without obvious filler. It is slightly dense and mixes several concerns (fields, sealing provenance, timestamp semantics, verification, parameters, pricing), but every sentence contributes.

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 that the output schema exists and annotations only cover read-only behavior, the description fills the important gaps: sealing provenance, timing window, timestamp meanings, verification pathway, pricing, and parameter constraints. An agent has enough context to call and interpret the 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 description coverage is 100%, so both the chain enum and limit range (1–50, default 12) are already fully documented in the schema. The description adds only 'Optional chain, and limit up to 50,' which does not add meaning beyond the structured fields.

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: 'The live ChainHelix signal stream, newest first.' It also previews the payload (chain, direction, entry price, conviction score). However, it does not explicitly distinguish this tool from signal-related siblings such as instrument_signals.

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 live ChainHelix signal stream, newest first' and the pointer to verify with 'free proof tools.' But there is no explicit when-to-use guidance versus alternatives like instrument_signals or verify_instrument_signal. The optional chain and limit notes are parameter details rather than usage 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?

With only readOnlyHint=true in annotations, the description supplies the traits that matter: results are ordered newest-first, checks run once per closed hour per chain, each alert is anchored to a CHXL attestation on opBNB (seq, hash, tx) making timing provable, and a per-call price. The `checkedThrough` explanation disambiguates an empty result, which is exactly the kind of behavior an agent cannot infer from the 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?

Front-loads what the tool returns and the read taxonomy, then moves to parameters and finally price. It is dense and jargon-heavy (ATR, MACD histogram, CHXL, opBNB) but every clause carries operational information; the parenthetical read definitions are the only portion that slows scanning.

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 shape needn't be spelled out, yet the description still tells the agent the alert payload fields and the `checkedThrough` sentinel. Coverage constraints, cost, and the negative-result semantics together leave nothing an agent needs in order 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% and both enum parameters are documented with examples, so the baseline is 3. The description restates the same defaults, ranges, and optionality without adding format or interaction detail 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 resource (lead alerts across nine chains, newest first) and enumerates the three read types it covers, each with a one-line behavioral definition. An agent can distinguish this listing tool from lead_alert_spec and verify_lead_alert without opening any 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 call context: optional filters, defaults (24h, 100), caps (168h, 500), cost of 6 cents per call, and the key interpretive rule that `checkedThrough` makes an empty list a real negative rather than missing data. It stops short of naming when to prefer a sibling such as verify_lead_alert or lead_alert_spec.

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

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

readOnlyHint=true already covers the safety profile, and the description adds real context beyond annotations by scoping exactly what the returned material addresses, including that commitment verification happens in the CHXL stream on opBNB without trusting the provider. It does not disclose whether the content is static or versioned, but for a documentation endpoint 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?

A single front-loaded sentence lists the covered topics in a scannable order, with no repetition. The closing phrase 'without trusting us' is somewhat promotional rather than informative, a small deduction from an otherwise tight definition.

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 parameters and an output schema present, the description need not explain return values, and it does cover the substantive scope of the content. The only missing piece an agent would want is a pointer that this is reference material to consult before calling lead_alerts or verify_lead_alert.

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 and there is nothing for the description to compensate for. The schema's x-lexicon block is unrelated to input meaning and requires no elaboration.

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 makes clear this is an explainer of the lead-alert subsystem, enumerating its coverage: the three reads, alert write conditions, alert fields, the webhook event, and CHXL verification on opBNB. The purpose (returning documentation) is clear, but it never differentiates itself from adjacent tools like lead_alerts or verify_lead_alert, leaving the agent to infer the spec/read-me boundary.

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: an agent can guess you call this before consuming lead_alerts to understand the data model, but the description never states that sequencing or names the operational sibling to use instead. There are no exclusions or prerequisites, so the choice between this and lead_alerts/verify_lead_alert is left to inference.

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

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

Annotations already cover the safety profile (readOnlyHint=true), yet the description adds material context: pricing at 50 cents per call, the fact that an API key does not cover it, and what each result contains (entry fields or candidate lists). That is genuine behavioral value beyond the structured fields.

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 dense sentences with no filler, front-loading the batch resolution purpose and following with result shape, then pricing. Slightly compressed phrasing but every clause carries information.

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

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

Return values are already covered by an output schema, and the description additionally explains entries vs. candidates plus the pricing/auth caveat. Given only one simple parameter, this is nearly complete; the only omission is explicit routing guidance against lexicon_resolve.

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 parameter is documented in the schema, so the schema carries the load. The description restates the item shape (string or name/namespace/venue) without adding format or validation detail beyond the schema, making 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?

Specific verb (resolved) plus resource (ChainHelix Agentic Lexicon) plus explicit batching scope ('up to 25 argument names ... in one call'). It also distinguishes itself from lexicon_resolve by referencing the same item hints, so an agent can tell the batch variant apart from the single-name sibling.

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

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

The batch cap of 25 and the per-item shape establish clear usage context, and linking the item format to lexicon_resolve implies the relationship to that sibling. It stops short of explicitly saying 'use lexicon_resolve for a single name' or stating when not to use this tool, so it lands at 4 rather than 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?

Goes well beyond the annotations by disclosing cost ($19 per call), that the API key does not cover the tool, that links expire in 7 days, that downloads are capped at 50, and that only patches of the current version are included. These are exactly the commercial and rate-limit facts an agent needs before invoking a non-idempotent, non-free call.

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-loads what the bundle contains before the commercial terms, and each clause carries distinct information (contents, link expiry, download cap, patch scope, price, key exclusion). It runs long as one dense sentence-plus block and could be broken up, but no sentence 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 zero parameters and an output schema present, the description supplies everything else an agent would need: contents, delivery format, link lifetime, download quota, price, and auth caveat. Nothing material is left to guesswork.

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 of 4 applies; there is no argument surface for the description to explain. The description does not need to compensate for any schema gap here.

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 resource and delivery mode: the full ChainHelix Agentic Lexicon for the current version, delivered as a download, with an enumerated contents list (entries, licence texts, attribution table, change log, sha256 per file). It is clear what you get, but it never differentiates itself from the near-named sibling lexicon_bulk or from lexicon_resolve, leaving the agent to infer which lexicon tool to pick.

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 constraints are implied rather than stated: 'patches of this version are included, a new version is a new purchase' suggests buying once per version, and the per-call price implies this is for full-corpus acquisition. There is no explicit when-to-use-this-vs-lexicon_bulk/lexicon_resolve guidance, which is a real gap given the confusingly similar sibling names.

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=true; the description adds genuinely useful non-schema context: cost (5 cents per call) and the fact that a ChainHelix API key does not cover this tool, plus the ambiguity fallback behavior. Missing only error/not-found handling detail.

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 resolution result, then pricing/licensing at the end. Dense but every clause carries information; the first sentence is long but not padded.

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-shape exposition is optional, and the description still summarizes it. Read-only safety is covered by annotations, and the cost/auth caveat closes the practical gap an agent would otherwise hit.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description largely restates the enum and argument examples. It does add one thing beyond the schema: venue field names resolve through ccxt's mapping, which clarifies what a 'venue' value actually means.

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 (resolve) and resource (one argument name against the ChainHelix Agentic Lexicon) and describes the possible outcomes (entry with id/meaning/representation/unit/example, or candidate list). The emphasis on 'One argument name' implicitly separates it from bulk/spec siblings, but no sibling is named explicitly.

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

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

It explains how to steer resolution via optional namespace and venue (including ccxt mapping for venue field names) and that ambiguity yields candidates. It never says when to choose this over lexicon_bulk, lexicon_bundle, or lexicon_spec, so the routing decision is left to inference.

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

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

With readOnlyHint already declaring a safe read operation, the description adds useful behavioral context beyond annotations: it documents the entry rule and the refusal convention, including that unknown names are refused before payment and returned with accepted names. It does not state whether lexicon_spec itself is free or paid, but the refusal behavior is a meaningful disclosure.

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 one dense sentence with semicolons and nested parentheticals, packing many concepts without clear visual structure. It is front-loaded with the lexicon identity and contains no irrelevant filler, but the run-on structure makes it harder to scan than a few shorter, purpose-built sentences would be.

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 zero parameters, an output schema, and readOnlyHint annotations, the description supplies the key content overview, the paid alternatives, the entry rule, and the refusal behavior. It does not mention the sibling lexicon_statement or state whether this spec call is free, but those are minor gaps relative to the otherwise complete coverage.

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 accepts zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to clarify. Baseline 4 applies because the schema is effectively complete and the description needs no additional parameter detail.

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 and enumerates its contents: accepted argument names, their representation and unit, version, bundle hash, namespaces, counts, entry rule, and refusal convention. It also explicitly distinguishes the free spec from the paid meaning-bearing siblings (lexicon_resolve, lexicon_bulk, lexicon_bundle), so an agent can tell what this tool does versus those alternatives.

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 makes clear that meanings belong to the paid lexicon_resolve, lexicon_bulk, and lexicon_bundle tools, implying that lexicon_spec is for names, units, and metadata rather than semantic resolution. It does not explicitly say when to choose lexicon_spec over lexicon_statement or give a formal when-not rule, but the primary alternative is named and the context is clear.

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