ChainHelix for Machines

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

With no annotations, the description carries the full burden and does comparatively well: it discloses cost (5 cents per call), freshness semantics (probedAt, ageSeconds, a 2-3 minute sweep of the live set on a rolling registry pass), and data provenance (onchain registration, Greenfield evidence records). It omits auth/payment mechanics and any explicit statement of read-only behavior, keeping it out of 5 territory.

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

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

The entire definition is one run-on sentence with nested parentheses, mixing return-value inventory, provenance, sweep cadence, and pricing. It is front-loaded with the subject but otherwise hard to parse; the sweep-cadence parenthetical is arguably excessive for a selection decision.

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?

The tool has an output schema, so the long enumeration of returned fields is largely redundant with structured data and could have been spent on id semantics and usage routing instead. It does cover the essentials an agent needs (what it is, what it costs, how fresh the data is), but leaves the key parameter and sibling choice unexplained.

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

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

Schema description coverage is 0% for the single required 'id' parameter, so the description should compensate but does not – it never explains what id means, its numeric type, or how to obtain it (e.g. via search_agents). Only vague context ('its own onchain registration') hints at what the identifier selects.

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 operation: a full report on one BNB Smart Chain agent, enumerated as onchain registration, probe history, test hires, and evidence records. An agent can tell it is the detailed per-agent report. It does not, however, name or distinguish itself from near-siblings like deep_report, situation_report, or agent_standing, so it falls 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 explicit when-to-use or when-not guidance, no prerequisite (e.g. get the id from search_agents first), and no alternative named. The reader must infer that this is the 'drill into one agent' tool from the content list alone.

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?

No annotations, so the description carries the full burden and does so well: EIP-191 signing with a published signer, 24-hour validity, a 2-cent per-call price, and the free unsigned fallback. It also discloses a non-obvious special case (ChainHelix agents return first_party with evidence only, no verdict or signature) and a data-quality caveat (feedback rows come from a rating farm on BSC).

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, evidence sources, signing and pricing are front-loaded, and nearly every clause carries information an agent needs (auth, cost, special-casing). It is a dense run-on sentence with stacked clauses, which hurts scannability, but little of the content is filler.

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

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

An output schema exists, so return values need no explanation. The description still covers provenance of each count, the signature/auth model, validity window, pricing, and the first_party edge case — everything needed to decide and invoke 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?

One parameter at 100% schema coverage, so the baseline is 3. The description's 'ERC-8004 agent' framing corroborates the schema's 'ERC-8004 token id on BNB Smart Chain' but adds no format, range or lookup semantics beyond it.

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 standing of one ERC-8004 agent on BNB Smart Chain') and immediately scopes it as evidence-based rather than self-declared. The singular 'one agent' plus the named evidence sources (ERC-8183 hires, opBNB delivery checks, newest probe, registry feedback rows) distinguish it cleanly from siblings like standing_bulk, standing_watch and verified_agents.

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?

Makes the single-agent scope explicit and offers the unsigned free alternative path (agents.chainhelix.io/standing/<id>), so an agent knows when this paid signed call is warranted. It does not explicitly name the bulk sibling as the alternative for many-id lookups, so a small routing gap remains.

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 no annotations, the description carries the full burden and does so well: it discloses cost (5 cents/call), an auth exclusion (API key does not cover this tool), on-chain mechanics on opBNB, automatic publication of claim text and salt at reveal, and the crucial semantic that it attests WHEN not WHETHER true. That is exactly the behavioral context an agent needs before paying for and committing an on-chain record.

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?

Dense and front-loaded: the core mechanism and the payload/revealDelayHours usage come first, then semantics, verification pointer, and pricing. Five sentences is on the longer side, but each carries non-redundant information, so little waste remains.

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 explained. Given zero schema description coverage and no annotations, the description still covers input meaning, cost, auth, chain, reveal timing, and where to verify — nothing essential to a correct invocation is missing.

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

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

Schema coverage is 0%, so the description must compensate, and it does: payload is characterized as the claim text sent as a string, and revealDelayHours is given a valid range (1 to 720) and a default (72) that the bare schema lacks. Both parameters gain real meaning beyond the type declarations.

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 precise verb and resource: sealing a claim on chain now for later reveal, with the immutability promise ('nobody can backdate'). This clearly distinguishes it from siblings like attest_status, list_attestations, and attest_spec, which are about tracking and verification rather than committing.

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 strong context: identity is the paying wallet or key id, price is 5 cents per call, and an API key does NOT cover this tool. It routes verification work to attest_spec. However, it never states when to use this over attest_status or list_reveals, so the alternative-selection guidance is incomplete.

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?

No annotations are provided, so the description carries the full burden. 'Live counts' implies a non-cached, read-only snapshot, which is useful, but nothing is said about freshness guarantees, latency, auth requirements, or rate limits for what is clearly a polling-style endpoint.

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 clause, front-loaded with the resource and immediately followed by the four metric categories. No filler and nothing buried.

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

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

With an output schema present, return values need no explanation, and the zero-parameter signature means input documentation is moot. The only real gap is the absent usage guidance and freshness/auth behaviour, minor for a simple read-only stat tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. The enumerated metric names are output concepts, not inputs, and are covered by the output 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 names a specific resource (attestation stream) and a specific output shape (live counts of committed, anchored, revealed, gaps), so an agent knows exactly what it returns. It does not, however, differentiate itself from near-neighbours like attest_status, list_attestations, list_reveals, or session_stats, which also touch attestation 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?

There is no when-to-use guidance, no statement of prerequisites, and no routing to an alternative. The agent is left to infer that this is the right tool for a live tally rather than attest_status or list_attestations.

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?

No annotations are provided, so the description carries the behavioral burden. It portrays a static specification document rather than an action, but does not explicitly state read-only behavior, side effects, auth needs, or return format. Some context is added, but key behavioral traits remain implicit.

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. It is appropriately sized for a resource-description 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, so return values do not need explanation. The description identifies what the spec covers, though it could better position the tool against related attestation and spec 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?

The input schema has zero parameters, and the rubric baseline for 0 params is 4. The description adds no parameter semantics because none 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?

States a specific resource, the machine verification spec for the attestation service, and summarizes its scope. Lacks an explicit action verb and does not distinguish it from sibling spec tools such as proof_spec or receipt_spec, so it is clear but not fully sibling-differentiating.

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 when-to-use guidance, prerequisites, or alternatives. It does not tell the agent whether to call this before or instead of attest, attest_status, or other attestation-related 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?

With no annotations, the description carries the full burden and does meaningful work: it discloses the temporal reveal behavior (only the receipt before reveal time, claim text and salt after) and the conditional return contents for nonce mode (sha256 of answer bytes, sequence number, opBNB batch tx, Merkle path). It omits auth requirements, error conditions, and rate limits, but the temporal/conditional disclosure is substantive.

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 the core purpose, then the two mode-specific behaviors. Dense and mostly waste-free, though the final sentence is a long run-on listing return fields.

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 and no annotations are present, the description covers the important ground: identification inputs, the reveal-time conditional, and the nonce-mode return. It stops short of error handling and the interaction between the required tenant and the optional seq/hash/nonce parameters.

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

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

Schema coverage is 0%, so the description must compensate. It does clarify roles: tenant plus seq or hash identifies the claim, and nonce switches to the paid-answer receipt mode. It leaves gaps though, e.g., whether seq/hash are mutually exclusive or which is required when neither is supplied, and it gives no format hints for nonce or hash.

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 ('Check one sealed claim by tenant plus seq or hash'), scoping to a single claim, which sets it apart from the plural siblings like list_attestations. The dual-mode behavior (receipt of paid answer when a nonce is supplied) slightly muddies the single-sentence purpose but is clearly described.

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 input conditions: seq/hash selects the sealed-claim mode, nonce selects the paid-answer receipt mode. However, it never states when to prefer this tool over attest, list_attestations, or verify_reveal, and gives no prerequisites or exclusions.

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

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

With no annotations, the description carries the behavioral burden well: it discloses the 2-cent cost, the 90-minute publication delay per hour, value-field availability quirks such as valueEth null on withdrawals and count-only data for arbitrum and opbnb withdrawals. It does not cover authentication or rate limits, but the key operational traits are present.

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 and most clauses carry useful detail, but the description is a single dense, semicolon-heavy sentence that is difficult to parse. It would benefit from paragraph breaks or bullet structure for the per-L2 behavior.

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 high complexity, no annotations, and an output schema, the description covers the essential usage context: per-L2 data semantics, window rules, cost, and timing. It is largely complete for calling the tool correctly, with minor gaps around auth or rate limits that may not be necessary for a paid read endpoint.

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

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

Schema description coverage is 0%, yet the description fully compensates: window is defined in hours with default 24 and max 720, publication timing is explained, l2 omission selects all five, and each enum value is semantically described in terms of the underlying bridge data it 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 clearly states the tool reports bridge activity over a time window, then enumerates the Ethereum-side and BNB Chain-side L2 bridge data it covers. This distinguishes it from generic flow tools, though it does not explicitly contrast itself with siblings like 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?

It explains parameter defaults and that omitting l2 selects all five L2s, but gives no guidance on when to use this tool instead of alternative flow or market tools. There are no prerequisites or exclusions beyond the parameter behavior.

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 no annotations, the description carries the full behavioral burden. It does disclose cost (2 cents per call) and window constraints (default 24, max 168), which is useful, but it omits permissions/auth needs, rate limits, data freshness, and explicit confirmation that this is a read-only historical 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?

Three short sentences, front-loaded with purpose, then parameter details, then price. No filler; every sentence adds a distinct, useful fact an agent needs.

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

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

An output schema exists, so return values need not be detailed, yet the description still summarizes them. Parameter semantics and cost are covered. The main gap is usage relative to sibling tools, but for a simple single-optional-parameter query, the definition is nearly self-sufficient.

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

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

Schema coverage is 0% and the single parameter has no description in the schema. The description compensates by supplying unit (hours), default (24), and maximum (168), which is exactly the missing semantic context. Only a minimum bound is absent, so a 4 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?

States the resource (Bitcoin mempool) and the exact data returned: fastest fee, transaction count and size as a sampled series with high/low/latest. A specific verb is absent, and it does not explicitly differentiate itself from siblings like congestion or gas_state, so it falls 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?

No when-to-use or when-not-to-use guidance is given, and no alternative sibling is named. It only supplies parameter defaults/max and cost, so an agent cannot tell from the description when to prefer this over congestion, market_state, or other mempool-adjacent 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?

With no annotations, the description carries the full burden, and it does disclose the per-call price (2 cents) and the window default/max, which are genuinely useful operational facts. It omits auth requirements, rate limits, and whether the underlying data is cached or live.

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

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

Two sentences, front-loaded with the primary payload description, followed by the parameter semantics and cost. Every clause earns its place with no filler.

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

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

An output schema exists, so return structure need not be explained. For a single-parameter tool the description covers scope, units, defaults, bounds, and cost, leaving only minor gaps such as the unit of 'value' and how results are ordered.

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

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

Schema coverage is 0% and the schema only says `window: number` with no description. The description fully compensates by specifying the unit (hours), the default (24), and the maximum (720), which is exactly what the schema fails to provide.

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 (Ethereum block builder market) and states exactly what is returned: blocks delivered and value per relay plus top builders by blocks. It is clearly distinguishable from the MEV siblings, though it does not explicitly name any of them for 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?

There is no when-to-use guidance and no alternatives named. The only hints are the window bounds, which are parameter constraints rather than usage context. An agent gets no help deciding between this and mev_bots, mev_intel, or mev_pressure.

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?

No annotations, so the description carries the full burden. It discloses the shape of what comes back (existence flag, paid period, signed statement, renewal history) and that it is a read lookup, which is useful. However it says nothing about authorization, rate limits, error behavior when no record exists, or freshness of the signed statement.

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

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

Two sentences, front-loaded with the resource being fetched and followed by the usage note. Dense but every clause maps to a distinct returned field or the caller's intent; only the long first sentence risks overload.

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 single-address read whose output schema exists, the description supplies enough context: what a caller gets and why they would call it. Nothing essential is missing, though auth/error semantics remain unaddressed.

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 'address' parameter has 0% schema description coverage, so the schema contributes nothing. The description compensates by stating "Send an EVM address," which constrains the expected format and chain domain beyond the bare string type.

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 standing clearance on file for a wallet) and enumerates what it conveys: cleared-buyer existence, paid period, signed sanctions statement, renewal count and next renewal. This is far more than a restatement of the name. It stops short of 5 because it never distinguishes itself from the similar-sounding sibling 'cleared_buyer'.

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?

"A seller reads this before taking a job instead of paying for a screen" gives a concrete use context and implicitly positions it against paid screening. There is no explicit when-not or named alternative tool, so it is clear context without 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?

No annotations provided, so description carries full burden. It discloses that currently every plan answers 'This plan is not on sale.' and no order is created, which is crucial behavioral context. However, it doesn't specify what happens on error or success beyond the future return values, nor does it mention authentication needs (the 'email' parameter is unexplained) or rate limits. With output schema present, return format needn't be detailed, but current failure behavior is well-covered.

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

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

Two sentences, front-loaded with current unavailability, then future behavior. Efficient and to the point, though the second sentence is somewhat long and could be split for clarity. No wasted words.

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

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

Given complexity (3 params, no annotations, output schema exists, 0% schema description coverage), description is somewhat complete: it explains current unavailability and future returns, but misses parameter explanations (especially email) and doesn't guide on alternatives or error handling. Enough to know the tool currently won't work, but not enough to confidently use it when it becomes available or understand parameters.

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

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

Schema description coverage is 0%, so description must compensate. It mentions 'chosen plan and payment chain' implying plan and chain parameters, but doesn't explain the 'email' parameter at all, nor does it clarify allowed values (enums provided in schema). The description adds minimal meaning beyond what the schema enumerates; it doesn't explain what 'plan' means (standard, pro, alerts) or the significance of 'chain' options.

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

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

States a specific verb+resource ('buy_key') and clarifies current behavior: no keys on sale, every plan returns 'This plan is not on sale.' and no order is created. The future behavior (returns payment address, amount, claim token) clarifies the ultimate purpose, though it's currently non-functional. Distinguished from sibling 'claim_key' by the buying vs claiming distinction, though this isn't explicitly 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?

Implied usage: call this to buy an API key, but currently it always fails. Doesn't explicitly say when to use this vs alternatives like 'claim_key' or 'key_order_status'. The description says 'API keys are not on sale at the moment', which might discourage use, but doesn't provide guidance on what to do instead (e.g., check key_order_status or wait).

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 no annotations, the description carries full behavioral burden. It usefully discloses cost (2 cents per call) and ordering (newest last), but omits default limit behavior, rate limits, and authentication requirements.

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

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

The description is a single, front-loaded sentence with no wasted words. It packs purpose, parameters, and cost efficiently, though it is slightly dense.

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, missing annotations, and sparse schema descriptions, the description provides a solid overview: data fields, timeframe range, limit cap, ordering, and cost. It leaves minor gaps like default limit and rate limits, but is sufficient for an agent to invoke 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 0%, so the description must compensate. It maps all three parameters in prose: 'one chain', 'fourteen timeframes from one minute to one week', and 'up to 500 candles' (limit). However, it does not specify the default limit or other constraints beyond the maximum.

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

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

The description clearly states the resource (OHLCV price history per candle) and scope (one chain, fourteen timeframes, up to 500 candles). It does not explicitly differentiate from sibling tools like 'prices', so it falls 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?

No guidance is given on when to use this tool versus alternatives such as 'prices' or 'market_state'. The description only states what data is returned, not the conditions or exclusions for its 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?

With no annotations, the description carries the full burden, and it does disclose two genuine behavioral traits: partial failures are reported in an 'unavailable' field rather than silently dropped, and the call costs 5 cents. It omits auth requirements, rate limits, or latency expectations, which keeps it short of the top score.

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 scope claim is front-loaded, followed by the section list, then the failure and cost notes. The enumeration is long but each item earns its place by telling the agent what the payload contains; nothing is wasted, though the sentence is dense.

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 aggregator with an output schema available, the description covers what the response contains, how partial failures surface, and the cost. Auth and latency remain undisclosed, but nothing essential for selecting or calling 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 0%, so the enum of 9 chains is the only documentation of the sole parameter. The description's 'One chain' phrase and the bitcoin-specific mempool note loosely ground the parameter but add no format or constraint detail beyond the schema's enum.

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 purpose: an aggregate per-chain read, and enumerates the exact sections bundled (market state, price walls, transfers, bot activity, open interest, stablecoin flows, mempool). This implicitly distinguishes it from the single-section siblings (market_state, wall_map, whale_flows, open_interest, btc_mempool_history) without naming them, so an agent can tell what it is but must infer the 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?

'The whole read in one answer' implies this is a bundle to use instead of several individual calls, and the bitcoin/mempool clause hints at a conditional inclusion. But there is no explicit when-to-use, when-not-to-use, or named alternative, so guidance is only implied.

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 no annotations, the description carries the full behavioral burden. It usefully discloses that the key is returned exactly once and must be saved, plus typical claimability timing. It omits other important traits such as permissions, failure handling, idempotency, or what happens if the token is invalid.

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 mostly on topic, but the first sentence is a confusing status message that is not front-loaded toward the tool's action. The key behavioral warning ('returned exactly once, save it') is present but buried after the contradictory opening.

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-param claim tool with an output schema, the description covers the core action, timing, and one-time key return. It still leaves gaps around prerequisites, token source, authentication, and failure modes, and the contradictory first sentence reduces trust in the guidance.

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

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

Schema description coverage is 0% for the single required parameter. The description only says 'Takes the claim token,' which names the parameter but does not explain where the token comes from, its format, or how to obtain it after a buy_key order.

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 states a clear verb and resource: 'Claim the API key for a paid buy_key order.' It distinguishes the tool from buy_key and key_order_status by tying it to a paid order. However, the opening sentence ('API keys are not on sale... so there is no key to claim') directly contradicts that purpose and leaves the agent uncertain whether the tool is currently usable.

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 timing guidance ('Payments usually become claimable within 30 minutes of confirming on chain') and indicates the tool applies after a paid buy_key order. But the same opening sentence says there is currently no key to claim, creating a confusing when-not signal without a clean alternative path.

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 no annotations, the description carries the full behavioral burden and meets it: $2 per 30-day call, the exact screening sources, a signed statement kept on file and renewed every 24 hours, the no-double-credit payment rule, and the payment-identity requirement. This is unusually complete disclosure for a paid mutation tool.

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

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

The description is dense but front-loaded with the core offer (price/period) before mechanics. The final two sentences about paying with the wallet and the API key partially overlap the earlier 'a key id cannot be cleared' clause, costing a little tightness.

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 explained, and the behavioral gaps (price, renewal, screening, payment identity) are covered. The only real omission is any mention of the network parameter, which the description ignores while the schema leaves it undocumented.

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 optional parameter, network, with 0% schema description coverage, and the description says nothing about it — no accepted values or how it interacts with the payment. The schema's x-vocab reference to payment.network offers only a hint. A baseline 3 is appropriate for a single low-complexity string that the description leaves entirely to the schema.

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

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

The description states a specific verb and resource — it issues a standing sanctions clearance for the paying wallet, screened against the OFAC SDN list and an on-chain oracle. It also distinguishes itself from the sibling buyer_clearance by naming that tool's role (free retrieval of the current statement).

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 when-to-use context (to become clearable), how to extend (call again for another 30 days), and hard constraints (pay with the wallet to be cleared; a key id cannot be cleared; a ChainHelix API key does not cover this tool). It also routes readers to the free buyer_clearance 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?

With no annotations, the description carries the full disclosure burden, and it does surface one genuinely useful trait: the price of 2 cents per call, which lets an agent budget invocations. It omits auth requirements, rate limits, and freshness/latency characteristics, which matter somewhat for a live mempool metric.

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 compact sentences, front-loaded with the content and ending with the cost caveat. Every clause earns its place with no filler.

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

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

Zero parameters and an output schema already covering return shape mean the description only needs to convey scope and cost, which it does. The missing piece is sibling differentiation from btc_mempool_history, a minor gap given the low 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a parameterless, no-argument snapshot 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?

States a specific resource and content clearly: Bitcoin queue depth now versus the past 30 days, plus the current fastest fee. An agent knows exactly what data comes back, though it does not explicitly contrast itself with the close sibling btc_mempool_history.

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 when-to-use guidance or mention of alternatives, despite btc_mempool_history being an obvious overlapping sibling. The only selection signal is the cost note, which hints this is a lightweight snapshot rather than a history pull, but this is inferential rather than stated.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits beyond the schema: the cost ('2 cents per call') and the window constraints (default 7, max 30). However, it says nothing about permissions, rate limits, or computational characteristics of a pairwise matrix over nine chains.

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 terse sentences, zero filler, with the core purpose front-loaded before constraints and cost. Every sentence earns its place.

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

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

An output schema exists, so return values need not be described, and the single parameter plus cost are covered. For a one-parameter read tool this is nearly sufficient, though the absence of annotations leaves the safety/permission profile entirely 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 0%, so the description must compensate, and it does: it defines the unit (days), the default (7), and the maximum (30) for the single 'window' parameter. This meaningfully exceeds the bare 'number' type in the schema, though it does not explain what happens at boundaries.

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 operation and resource: 'Pairwise correlation of hourly returns across the nine chains.' An agent can tell exactly what is computed. It does not name or distinguish itself from any sibling, but no obvious correlation sibling exists, so the lack of differentiation is minor.

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 a default and a maximum for the window but no guidance on when to reach for this tool versus alternatives, nor any prerequisites or exclusions. Usage must be inferred from the purpose statement alone.

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 no annotations, the description carries the full behavioral burden. It earns credit for disclosing data provenance (BNB Greenfield storage) and the sealing mechanism (opBNB root), which is real context beyond structure. It does not cover whether the digest changes over time, behavior on days with no activity, auth requirements, or rate limits.

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 compact passage that front-loads what the digest is and follows with the parameter contract. No filler sentences, nothing repeated from 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?

An output schema exists, so return-value shape need not be restated. For a single-parameter read tool with no annotations, the description covers purpose, provenance, parameter format, and default, leaving only minor gaps such as empty-day behavior.

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

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

Schema description coverage is 0% — the schema only declares date as a string. The description compensates by giving the accepted format (YYYY-MM-DD), noting the parameter is optional, and specifying the default (the latest day), which is meaningful guidance beyond the raw 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 artifact — a daily Merkle digest over reveals, hire deliverables, and verification records, with the root sealed on opBNB — which is semantically distinct from siblings like list_reveals or attestation_stats. It is highly specific about the resource, though it is phrased as a noun clause rather than a verb+resource action, so an agent must infer the retrieval 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?

There is no statement of when to use this tool versus alternatives (e.g., list_reveals, verified_delivery, attestation_stats, chain_brief). The only operational hint is the default-date behavior, which is parameter semantics rather than usage 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?

With no annotations, the description carries the full behavioral burden. It discloses the record's shape (entries carry a date, affected tools, and a count), which is genuinely useful, but it never states that this is a read-only operation, whether results are paginated or ordered, or what happens with an unknown tool name filter.

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?

Content is front-loaded: the record and its fields come first, with parameter notes trailing. The closing fragment 'Optional tool name to filter, and limit' is clipped and slightly awkward, but the whole definition stays within two sentences with no filler.

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

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

An output schema exists, so return-value documentation is not required, and the description already characterizes entries well. Both optional parameters are at least named, leaving only the limit's bounds as an unstated detail, which is a minor gap for a two-parameter 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 description coverage is 0%, so the description is the only source of parameter meaning, and it does identify both parameters: 'tool' filters by tool name and 'limit' bounds results. However, it omits the limit's default, maximum, and behavior, and gives no example or matching semantics for the tool filter.

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 (a dated changelog of data changes) and enumerates its contents (rule flips, label fixes, duplicate removals, band versions, sample notices), so an agent immediately knows what it returns. No sibling tool covers this ground, so sibling differentiation is moot, but there is no crisp leading verb (it reads as a noun phrase, not 'returns the changelog of...').

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 reach for this tool versus alternatives, no prerequisites, and no indication of who would want a change history. The only quasi-usage content is 'Optional tool name to filter, and limit', which is parameter mechanics rather than 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?

With no annotations, the description carries the full burden, and it does disclose one meaningful behavioral trait the structured fields do not: a cost of '25 cents per call'. It also characterizes the breadth of the payload. It does not state that this is a read-only research call, whether authentication or a funded key is required, whether the charge applies on failure, or whether the call is slow/heavy — real gaps for an un-annotated tool.

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

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

The core identity is front-loaded in the first clause, and the pricing sentence is short and earns its place. The middle section is a long comma-chained inventory of payload contents that verges on run-on, though every listed item does describe actual output.

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

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

An output schema exists, so the description need not document return values — yet it spends most of its length doing exactly that while omitting the one thing the schema cannot convey: the semantics of the optional 'chain' parameter. For a high-cost aggregate tool with no annotations, the billing/auth/scope story is only partially told.

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, 'chain', with 0% schema description coverage, so the description must compensate and largely does not. The phrase 'nine chain' loosely echoes the nine-value enum, but the description never explains that the parameter selects a chain, that it is optional, or what happens if it is omitted (all chains vs a default). An agent cannot resolve the parameter's behavior from the text.

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 deliverable — a 'complete nine chain research brief in one call' — and enumerates its constituent sections (market report with price walls/large transfers/bot activity, live signal stream with conviction scores and ranking tiers, correlations, options volatility, session stats, proof counters). That is enough for an agent to know this is a bundled aggregate report. It stops short of naming the sibling it supersedes (e.g. chain_brief, situation_report), so differentiation is inferred from the component list 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?

The claim 'The most complete single answer this server produces' implies this is the go-to when an agent wants everything at once, which is an implicit usage cue. However there is no explicit when-to-use vs when-not-to-use guidance, no mention of cheaper siblings for narrower needs (latest_signals, correlation_matrix, options_skew), and no note on when a per-call cost is worth paying.

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 no annotations, the description carries the full burden. It usefully discloses what content the spec contains (canonical form, hash, calldata layout, per-check meaning, repeatable steps), but says nothing about read-only nature, static vs. live content, or auth requirements beyond the implied reference-doc role.

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 sentence, front-loaded with the core purpose ('How to verify a sealed delivery claim yourself'). It is efficient, though the trailing comma-list reads slightly run-on.

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

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

An output schema exists, so return values need not be described, and the description adequately conveys the spec's content scope for a static 0-param reference tool. What is missing is differentiation from other spec tools, not internal completeness.

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

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

The tool takes no parameters, so there is no parameter surface for the description to clarify; this matches the 0-param baseline of 4. Schema coverage is trivially 100%.

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

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

The description clearly states the tool delivers guidance on verifying a sealed delivery claim, enumerating the artifacts it exposes (canonical form, hash, calldata layout on opBNB, checks, steps). However, it does not distinguish itself from the many sibling '*_spec' tools (proof_spec, attest_spec, receipt_spec) that likely serve analogous reference roles.

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 phrase 'verify a sealed delivery claim yourself' hints at a use case, but there is no explicit when-to-use, when-not-to-use, or pointer to overlapping siblings like delivery_status or verified_delivery. An agent gets no 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?

With no annotations, the description carries the full behavioral burden and does well: it discloses the return contents, the 'once sealed' precondition, the refusal path ('refused before any charge') for a hire with no claim, and the per-call price. It omits any permission/auth or rate-limit context, keeping it from 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?

Four short sentences, front-loaded with the purpose, then invocation, then return, then the refusal/price caveat. Every sentence carries information; 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 values need not be spelled out (though they are), and the description still covers the missing behavioral and parameter context (cost, refusal, identifier modes). A status-check tool with 3 optional params is adequately specified, with only edge-case behavior (multiple identifiers supplied, invalid job) left open.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: 'job id, or the sequence number, or the claim hash' maps the job/seq/hash properties to meaning and the 'or' signals only one identifier is needed (consistent with zero required params). It adds no format details for the hash, so it is not a full 5.

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

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

States a specific resource ('the sealed delivery claim for a hire') and what it returns, which is clear enough to distinguish it from most siblings. It does not explicitly name or contrast with near neighbors like verified_delivery or delivery_spec, so it falls 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 implies the calling context (checking whether a delivery claim has been sealed) and explains the three alternative identifiers for invoking it, but never states when to use this tool versus alternatives such as verified_delivery or delivery_spec. This is implied rather than explicit 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?

With no annotations, the description carries the full burden and does disclose several traits beyond the schema: newest-first ordering, the default and maximum page size, the sealed/unsealed state of records, and a per-call price of 1 cent. It stops short of stating authentication requirements, pagination mechanics beyond limit, or error behavior, which keeps it out of the top band.

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 and ordering constraint are front-loaded, and the limits and cost are packed efficiently into a second paragraph. The long comma-separated field list is dense and partly duplicates the existing output schema, but the overall length stays proportionate to a paid, filterable read 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, so the field enumeration is somewhat redundant and the description needn't have carried it. More relevant gaps remain: with zero annotations, the description never states authentication or payment prerequisites for a costed call, nor how to page past the 500 cap. Adequate, but not complete for a metered read endpoint.

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

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

Schema description coverage is 0%, so the schema alone gives only types, yet the description compensates by labeling all three parameters (instrument, signalTs, limit), qualifying them as optional, and supplying the limit default of 50 and cap of 500 — values absent from the schema. It does not clarify the semantics of signalTs as a filter or explain the instrument enum values, which the schema does supply.

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 — retrieving fill receipts for the instrument lane, ordered newest first — and enumerates the returned fields, so the agent knows exactly what it gets back. It does not, however, differentiate itself from nearby siblings such as verify_fill or instrument_signals, so an agent has to infer the boundary from the resource name alone.

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 when-to-use statement and no named alternative; the description only says the three filters are optional. Nothing tells the agent when this read tool should be chosen over verify_fill, instrument_signals, or receipt_spec, leaving routing entirely 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 no annotations, the description carries the full burden and does well: it discloses the tool is free, enumerates all chains, explains the requiresArguments marker for tools without a default result, and points at meta.contentHash in paid answers. It omits auth requirements and rate limits, but for a free read-only check those are minor gaps.

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 value proposition is front-loaded in the first clause ('Free check before you pay'), and every following sentence adds a distinct fact — match semantics, the requiresArguments case, the paid-answer hash. It is dense and slightly run-on, but nothing is filler.

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

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

An output schema exists, so return values need no explanation, and the description covers the one real gotcha an agent would hit (argument-requiring tools appearing with requiresArguments). For a one-optional-parameter read tool this is nearly complete; only auth/cost-limit details are absent.

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

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

Schema description coverage is 100% and the single optional 'name' parameter is fully documented in the schema (including the 'tool' alias). The description's 'Optional name for one tool' only restates that, so the baseline of 3 applies; the requiresArguments discussion adds related behavioral context but not 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 states a specific resource and return payload: the content hash and validUntil of each data tool's current default result, framed as a free pre-purchase check. The opaque name 'freshness' is rescued by the prose, and the tool is clearly distinct from siblings like data_changelog or instrument_state, though no sibling is named explicitly.

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

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

It gives a clear when-to-use rule — 'free check before you pay' — plus the decision logic ('if the hash matches what you already hold, nothing changed and there is nothing to buy'). It also explains how to interpret entries for tools that need arguments. No alternative tool is named, which keeps it short of a 5.

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

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

With no annotations, the description carries the full behavioral burden: it usefully discloses the comparison baseline (24h average) and the cost (2 cents per call), which is real context an agent needs before calling. It says nothing about auth requirements, rate limits, or data freshness beyond the word 'latest'. Output schema exists, so return-shape detail is not required here.

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

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

Two tight sentences with the resource front-loaded, followed by the metric list, the default behavior, and price. The metric enumeration is dense but every clause conveys something operational; nothing is filler.

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

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

For a single optional-parameter read query with an output schema, the description covers what is returned, the comparison semantics, the no-chain default, and cost. The only gap is the absence of any routing hint among the many overlapping chain/MEV 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 0%, so the description must compensate, and it does: 'Omit chain for all nine' explains both that chain is optional and what the omitted behavior yields (aggregate across nine chains). The enum already supplies valid values, so no further parameter detail is needed.

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 the specific resource (network load per chain) and enumerates the exact metrics returned: transaction count, MEV count/rate, average gas, large transaction count, each compared to a 24h average. That is far more precise than the bare name 'gas_state', which undersells the scope. It does not, however, distinguish itself from sibling load/MEV tools like congestion or mev_pressure.

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' gives one concrete usage rule for the optional parameter, and the price note implies a per-call cost tradeoff that matters when omitting chain. But there is no guidance on when to pick this over congestion, mev_pressure, chain_brief, or market_state, all of which overlap in subject matter.

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 no annotations, the description carries the full burden and does so well: it discloses the counting rule (each proposal counted once at its latest recorded state), the recording cadence (on state/vote/score change, at least every 6 hours), and the cost (2 cents per call). It omits auth/prerequisite information and any rate limits 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?

The purpose is front-loaded, which is good, but the first sentence is a long run-on carrying counting semantics, state breakdown, and sort order in one breath. Most of the remaining content is dense detail, but a tabular clause flags pricing and recording cadence more prominently than they need.

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?

Because an output schema exists, the description needn't explain return shape, and it sensibly focuses on timing, counting semantics, cost, and parameter defaults. The missing pieces are the limit parameter's meaning and any access/prerequisite context, so it is strong but not fully complete for a 3-parameter paid analytics 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 description coverage is 0%, so the description must compensate. It documents space (Snapshot space id with a concrete example, aavedao.eth) and window (in hours, default 168, max 1440) with units and constraints the bare schema lacks. The third parameter, limit, is only vaguely gestured at by 'its most recent ones' and never named or bounded, which is the one real gap.

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 concrete verb+resource: Snapshot DAO governance proposals for a given space, with the exact aggregation (counts per state, latest vote count and score, sorted most-voted first). An agent can immediately tell this is a per-space governance activity feed rather than a general market or registry tool, though it never explicitly contrasts itself with any 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?

Usage is implied rather than stated: the per-space scoping, the window default/max, and the description of what is returned make the intended context clear. However, there is no explicit 'use this when / don't use this when' and no alternative tool is named, so the agent must infer the 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?

No annotations, so the description carries full burden. It discloses important traits: deterministic arithmetic, no custody, no execution, free call but paid job, escrow funding, and that you get a wallet-signed quote and calldata to sign. This is strong behavioral context. Minor gap: doesn't detail rate limits or escrow refund mechanics.

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 purpose and return shape, then terse caveats and workflow. It's information-dense and mostly earns its place, though the final sentence about parameters is somewhat redundant given the schema. Slightly long but well-structured.

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 output schema exists and schema coverage is 100%, the description adds the key non-obvious context: cost model (free call, paid job), signing/auth flow, what is and isn't computed, and the funding sequence. An agent has everything needed to call and follow up 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% with rich per-parameter descriptions, examples, aliases, and vocabulary mappings. The description defers to the schema ('The parameters here are exactly what the agent accepts; an example is in the input schema description'), adding little parameter detail itself, 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?

States a specific verb and resource ('Plan a hire of the ChainHelix gridtrader agent'), identifies the agent by ERC-8004 id and strategy type, and specifies exactly what it returns (symmetric buy/sell grid). It is clearly distinguishable from siblings like hire_plan_rebalancer and hire_plan_yieldopt.

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 delineates what it does and does not do: 'Not a bounded-loss or profit-target strategy: fees, slippage, gas and PnL are not computed,' which sets expectations for when this is/isn't the right tool. It also mentions the workflow (send params, get quote, fund, tell agent). It doesn't explicitly contrast with the sibling hire_plan_* tools, but the scope is clearly implied.

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 no annotations, the description carries the full burden and mostly delivers: 'Deterministic arithmetic, no custody, no execution' clarifies safety profile, 'This call is free; the job is not' warns about the on-chain payment, and it explains that the returned quote is wallet-signed and that the createJob calldata must be signed from the caller's own wallet. It omits auth/rate-limit behavior and whether the quote expires, so it is not exhaustive.

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 purpose and the mode split before the workflow mechanics, and it avoids filler. It is a single dense paragraph that mixes returned values, payment terms, and signing steps, so it is readable but not optimally partitioned.

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, yet the description still summarizes the returns (health factor, status bands, per-asset liquidation prices with drop distances), which is redundant but harmless. Given 8 parameters, nested objects, and no annotations, it supplies enough to call the tool correctly, though it says nothing about failures, quote validity windows, or required wallet setup.

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 itself carries per-property descriptions, aliases, vocabulary tags, and a worked example, so the baseline is 3. The description's only added semantic is the either/or constraint ('send position instead of collateral and debt') and the assurance that 'the parameters here are exactly what the agent accepts,' which the schema's anyOf already encodes.

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 healthmon agent (ERC-8004 #269228, Position health report)' — and enumerates the two computational modes (lending health factor, LP range health) with their outputs. An agent can distinguish this from the sibling hire_plan_gridtrader/rebalancer/yieldopt tools by the named agent and the health/liquidation-price output.

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

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

Explicitly directs the agent to send `position` {price, lowerPrice, upperPrice} instead of collateral/debt for LP range health, and states 'One question per job,' which scopes each invocation. It also outlines the full sequence (get quote -> sign createJob calldata -> fund -> tell the agent). It stops short of naming when to prefer a sibling (e.g. hire_quote) or any exclusion conditions.

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 no annotations, the description carries the full burden and does real work: it discloses deterministic arithmetic, no custody, no execution, that the quote call is free while the job is paid, that payment goes into escrow on chain, and that the createJob calldata must be signed from the caller's own wallet. Missing are failure modes, idempotency, and rate limits, but the core behavioral profile is well covered.

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 and output are front-loaded in the first sentence, and sentences like 'This call is free; the job is not.' carry real signal. It is dense and slightly run-on (the residual-cash clause is convoluted), but virtually no sentence is filler.

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

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

For a 6-parameter tool with nested objects and an output schema, the definition covers the essential context an agent needs: what the plan computes, that it is non-executing, and the quote/fund handshake. Return values need not be restated given the output schema, and the remaining gap (sibling routing, edge cases) is modest.

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. The description only adds that 'the parameters here are exactly what the agent accepts' and points to the schema example; it contributes no semantics beyond what the schema's own descriptions and x-aliases already provide.

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: plans a hire of the ChainHelix rebalancer agent and enumerates exactly what the plan returns (current vs target weights, per-asset drift, ordered trade list, residual cash). The name and 'Portfolio rebalancing plan' framing make it distinguishable from siblings like hire_plan_gridtrader, though it never explicitly contrasts itself with them.

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

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

The description gives a clear how-to flow (send params, receive wallet-signed quote plus createJob calldata, fund, notify the agent), which is useful usage context. It never states when to choose this tool over hire_plan_gridtrader/hire_plan_healthmon/hire_plan_yieldopt or the generic hire_quote, so alternative-selection guidance is only implied by the 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?

With no annotations the description carries the full burden and does well: it discloses deterministic arithmetic, no custody, no execution, a free quote vs a paid escrow job, and that the response contains a wallet-signed quote plus createJob calldata to sign from the caller's own wallet. Minor gaps remain on rate limits or idempotency.

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 and the allocation semantics are front-loaded, and each sentence carries distinct information (inputs, caps, unallocated leftover, pricing model, output artifacts). It runs long and is somewhat dense, but nothing is clearly 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?

For a complex tool with nested objects and an output schema, the description covers the essential workflow, the cap-driven allocation behavior, and the payment/escrow model, so an agent can act correctly. The existence of an output schema means return-format detail is reasonably omitted.

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 aliases, defaults and value ranges, so the baseline is 3. The description restates the main inputs (pools with APY/TVL/risk, capital) but adds no syntax or constraint detail beyond what the schema and its example provide.

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') and clarifies the agent's function ('Yield allocation across pools'). The 'yieldopt' framing implicitly separates it from the sibling hire_plan_gridtrader/rebalancer/healthmon planners, though it never names them 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?

Describes the calling workflow (send params, get quote, fund, tell the agent) and flags that 'This call is free; the job is not.' However, it never states when to choose this planner over the sibling hire_plan_* variants, leaving the selection to inference from the 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?

With no annotations, the description carries the full burden and does well: it discloses settlement chain (BNB Smart Chain), that the offer is signed, the exact cost (2 cents per call), the eligibility gate, and what comes back (signed envelope and funding steps). It does not cover auth requirements or whether the call itself commits anything on-chain, so it falls short of 5.

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

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

Front-loaded with the payload and response, followed by the eligibility constraint and the price. Nearly every clause earns its place, though the ERC-8183 / ChainHelix name-dropping adds some opacity for an agent unfamiliar with those terms.

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, and the cost and eligibility are covered. The gap is on the input side: with three parameters at 0% schema coverage, the meaning and sourcing of the required 'id' and the structure of the 'terms' object remain undefined, which is meaningful for a 3-parameter nested 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 0%, so the description must compensate. It accounts for task_description and terms ('send your task description and terms'), but the required 'id' is only implied by 'hireable agent' — no format, source, or how to obtain it is given, and the open-ended nested 'terms' object is not characterized.

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+resource: obtain a live signed ERC-8183 quote from a hireable agent on BNB Smart Chain via ChainHelix, returning a signed offer envelope plus funding steps. It is distinguishable from nearby siblings like search_agents and hire_plan_* by its signature/quote framing, though it never names an alternative explicitly.

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

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

It gives an eligibility precondition ('Only agents the live map lists as hireable') and implies the goal (fund a job), which is implied usage guidance. It never says when to prefer this over search_agents, verified_agents, or the hire_plan_* tools, and no exclusions are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the content shape (venue, contract, chain, fees, funding cycle, session policy, label) and adds a useful scoping note that these are derivatives on the venue, never the share. However it says nothing about permissions, freshness, or read semantics.

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

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

Two sentences, front-loaded with the resource, with no filler. The second sentence about derivatives-not-shares earns its place as a scoping clarification, though the jargon-heavy phrasing is slightly dense.

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

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

A zero-parameter listing tool with an output schema and no annotations. The description covers what the list contains and the nature of the instruments, and the output schema carries return-value detail, so little is missing 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?

The tool takes zero parameters (empty schema, additionalProperties false), so there are no parameter semantics to document. Baseline 4 applies; nothing in the description contradicts the schema.

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

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

The description states a specific resource (the ChainHelix instrument lane) and enumerates exactly what it covers: SpaceX and Circle perpetuals on Aster (BNB Chain). An agent can tell it is a listing tool, distinct from siblings like instrument_signals or instrument_state, though those siblings are never 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?

There is no when-to-use, when-not-to-use, or alternative routing guidance. Given a dense cluster of instrument_* siblings (signals, spec, state), the description should say when to reach for the list versus those, but it leaves that entirely 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 no annotations, the description carries the full burden and does reasonably well: it discloses ordering (newest first), the meaning of a missing seq (pre-stream or uncommitted), the fields carried per signal, and the per-call price. It omits auth/permission requirements and any notion of mutation safety, which keeps 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?

Front-loaded with purpose, then output semantics, then parameters, then cost. No filler sentences and every clause carries information. Slightly dense but appropriate for the amount of behavioral detail conveyed.

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

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

An output schema exists, so return values need not be re-explained; the description instead supplies the interpretation guidance (seq absence, newest-first ordering) an agent actually needs. Combined with the default/max limit note and pricing, it is complete enough to 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 0%, so the description must compensate, and it adds two genuinely useful facts the schema lacks: limit defaults to 50 and caps at 500, and both params are optional. It does not explain the instrument identifier beyond 'instrument id', leaving the enum values (spcx, crcl) to the schema alone.

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 behavior: the instrument lane signals (paper book, BNB Chain venue) returned newest first with commit status. That is a clear verb+resource. It does not, however, distinguish itself from near-siblings like latest_signals or instrument_state, so an agent cannot tell which lane/scope this covers without opening the 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?

Usage is only implied: the description frames this as the instrument-lane signal feed with optional filters, which suggests when it applies. It never states when to prefer it over latest_signals, list_attestations, or verify_instrument_signal, and offers no exclusions, so the agent must infer 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 no annotations, the description must carry the behavioral burden, and it does disclose the content areas the spec covers. However, it never states that this returns static reference documentation (read-only, no side effects), nor whether it is versioned or how it relates to live chain state, which are the behaviors that matter for a zero-parameter spec tool.

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

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

A single front-loaded sentence that opens with the purpose ("How to verify...") and then lists the covered topics. The trailing colon-list is dense but every item earns its place; nothing is wasted or repeated.

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

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

An output schema exists, so return-value explanation is unnecessary, and zero parameters keep the calling surface trivial. What is missing is disambiguation from the automatic verification siblings and any note on whether the spec is a static artifact or tied to a specific lexicon/CHXI version, which an agent calling it would want to know.

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

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

The tool takes zero parameters, so there are no input semantics to explain and the baseline of 4 applies. The description enumerates the topics the spec addresses, which is the closest analogue to parameter meaning 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?

The description states a specific resource (instrument signal commits and fill receipts) and a specific function (how to verify them manually, including canonical forms, hashes, calldata layouts, and the reveal rule). It is clear what the spec covers, but it never names or contrasts itself with the obvious siblings it could be confused with — verify_instrument_signal, receipt_spec, delivery_spec, or instrument_signals — so sibling differentiation is left to the agent.

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 phrase "verify ... yourself" implies this is the reference to consult when performing verification independently rather than calling an automated verify tool, which is implied usage rather than an explicit rule. There is no statement of when to prefer this over receipt_spec or verify_instrument_signal, and no prerequisites or exclusions are given.

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 no annotations, the description carries the full burden and does well: it discloses the cost model ('1 cent per call'), the freshness mechanism (meta with contentHash/validUntil so you can detect no-change), and data-quality signals (feed health and age). It omits auth/permission requirements and error modes, 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?

A single dense run-on sentence; the reference clause ('the spot token of the same name on BNB Chain ... priced from its PancakeSwap v3 USDT pool ...') is difficult to parse on first read. Critically, most of the length re-enumerates fields that the output schema already exposes, so much of the text does not earn its place for an agent that can read 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?

An output schema exists, so the exhaustive field list is largely redundant and the description should instead spend its budget on behavior and routing. It does cover cost and freshness meta, but leaves permission requirements, error behavior, and sibling routing unstated. Adequate, with visible 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 0%, so the description must compensate. It does clarify that the instrument id is optional (implying omission returns all instruments), which the schema does not say in text, and the enum values spcx/crcl are loosely linked to the CRCLB/SPCXB reference tokens. It adds no accepted-format or case guidance, so compensation is only partial.

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 (live state of each instrument) and enumerates exactly which fields are returned (mark, index, basis bps, funding, spread, volume, feed health, reference, session). This is far more specific than a tautology. It does not name or distinguish itself from near-siblings such as instrument_signals, instrument_spec, or market_state, so an agent must infer the boundary itself.

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

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

No when-to-use, when-not-to-use, or alternative tool is mentioned. The only routing hint is the implicit 'omit the id to get all instruments' behavior, which is parameter semantics rather than usage guidance. An agent cannot tell from the text whether to prefer this over instrument_signals or market_state.

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 no annotations, the description carries the full disclosure burden, and it does add one concrete behavioral trait: cost ('2 cents per call'). However, it omits any auth requirements, rate limits, or freshness/latency details that matter for a priced market-data 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?

Two tight sentences: the data scope is front-loaded and the pricing note follows. No filler, every clause earns its place.

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

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

An output schema exists, so return values needn't be explained, and with zero params the input surface is trivial. The description covers what is returned and the cost, though it stops short of routing guidance relative to 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify about inputs, 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 names a specific resource (near-term option implied volatility) and scope (Bitcoin and Ethereum, now vs one week ago), so an agent knows exactly what data it returns. It does not differentiate itself from the related sibling options_skew, which also covers options volatility data, leaving ambiguity about which 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?

There is no when-to-use guidance, no exclusions, and no mention of the related options_skew sibling as an alternative. The agent is left to infer usage purely from the data description.

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 no annotations, the description carries full burden. It does disclose meaningful behavior beyond the schema: what the response conveys (whether payment was seen, whether the key is ready to claim) and an operational constraint (keys currently not on sale). It omits auth requirements, error behavior, and how long a payment takes to be observed, and its constraint statement conflicts with its own instruction.

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 with no padding, so length is fine. But the structure is front-loaded with a self-contradictory caveat that muddies the actual instruction, which should have led.

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 specified. For a single-parameter status tool the description is nearly adequate, but the internal contradiction about whether orders can exist leaves the agent without a reliable picture of when the tool is actionable.

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

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

Schema description coverage is 0% for the single required claim_token, so the description must compensate. It only says 'Takes the claim token' and implies its origin is a buy_key purchase — useful but minimal; no format, length, or source-lookup guidance is given beyond 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?

The description does state a specific verb and resource ('Check a key order created with buy_key') and what it reports. However, the leading sentence ('API keys are not on sale at the moment and buy_key creates no order, so there is no order to check') directly undercuts that purpose and leaves the agent unsure whether the tool can return anything meaningful 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 ties the tool to buy_key ('created with buy_key'), which nominally identifies the prerequisite. But the same sentence says buy_key creates no order, so the guidance is self-cancelling: the agent is told to check orders that the description says cannot exist. No alternative or fallback is offered.

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 no annotations, the description carries the full burden and does so well: it discloses immutability ('sealed on the opBNB chain before its outcome exists... cannot be edited afterward'), latency semantics (typically within 5 minutes, at most ~30), the meaning of sealedAt vs committedAt, and a per-call cost of 6 cents. These are exactly the behavioral traits an agent needs and none are available in 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?

The core purpose is front-loaded in the first sentence and no sentence is wasted, but the single dense block packs immutability, timing, field semantics, verification, params and pricing into one paragraph. Slightly more structure would aid scanning without adding length.

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 explained, and the description still helpfully clarifies the two timestamp fields. For a read/stream tool with on-chain sealing and a cost model, it covers purpose, immutability, timing, params, price and verification, leaving only explicit sibling routing 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 0%, so the description must compensate, and it does for both params: 'chain' is flagged optional (a filter) and 'limit' is bounded to 50, a constraint not present in the schema. It adds the cap and optionality but no per-value guidance on chain, which the enum already supplies structurally.

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 live ChainHelix signal stream) and its ordering (newest first), and enumerates the payload fields (chain, direction, entry price, conviction score + tier). It is clear what the tool returns, but it never explicitly differentiates itself from close siblings like instrument_signals or the verify_* tools.

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

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

Usage is implied rather than stated: optional filtering by chain and limit signals when a caller would narrow results, and 'Verify any of them with the free proof tools' hints at the follow-on verification workflow. However, there is no explicit 'use this when X, use sibling Y when Z' guidance for choosing among the many signal/attestation 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?

With no annotations, the description carries the full behavioral burden and does so richly: it discloses the hourly check cadence, chain scope, attestation commits (seq/hash/transaction) on opBNB that make alert timing provable, the meaning of checkedThrough, that an empty list is a genuine negative, and even the per-call price of 6 cents.

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 purpose and ordering, then flows into read definitions, provenance, parameters, and cost. The single dense paragraph is long but nearly every clause carries distinct information; only slight tightening would help readability.

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 spelled out, yet the description still maps the alert payload and attestation fields, covers all four parameters' defaults, and explains the empty-result semantics. Only auth/prerequisite context is absent, which is minor for a paid 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 0%, so the description must compensate, and it does: it gives hours back (default 24, max 168) and limit (default 100, max 500), plus a semantic definition of each read type. It only lightly covers 'chain' (says nine chains but the enum values live in the schema), so it is strong but not exhaustive.

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 ('Lead alerts on nine chains, newest first') and enumerates the exact three read types it serves, which distinguishes it from siblings like lead_alert_spec (spec) and verify_lead_alert (verification). An agent can tell what this tool 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?

Usage is implied: it is the query tool for lead alerts and explains the filter knobs, so an agent can infer when to call it. However, it never names alternatives (lead_alert_spec, verify_lead_alert) or states when NOT to use it, leaving routing to inference.

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

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

No annotations are provided, so the description carries the burden. It discloses the topical content and hints at a trust model ('verify an alert commit in the CHXL stream on opBNB without trusting us'), which adds context beyond the schema. However, it never states that this is a read-only, side-effect-free documentation lookup, nor anything about format or cost.

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

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

It is a single, front-loaded sentence that leads with the subject and then lists the covered topics, with no filler. The dense colon-list is appropriate for a spec tool, though it is slightly run-on.

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

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

With an output schema present and no parameters, the return-value burden is largely removed, and the description enumerates the spec's sections. An agent knows what it will get. It could be more complete by stating when to consult the spec versus calling lead_alerts directly.

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 (empty properties, additionalProperties false), so there is nothing to document and the baseline of 4 applies. The description correctly does not invent parameter guidance.

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

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

The description opens with 'The lead alerts explained' and enumerates the exact contents (three reads, when alerts are written, alert fields, webhook event, trustless verification). This makes clear it is the explanatory spec/documentation companion rather than the data tool, implicitly distinguishing it from siblings lead_alerts and verify_lead_alert. It does not name those siblings explicitly, so it falls 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: an agent can infer it should read this before calling lead_alerts or verify_lead_alert, but there is no explicit 'use this when...' or 'do not use for...' statement. No alternative is named and no preconditions are given.

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 no annotations, the description carries the full behavioral burden and does so well: batch cap, per-call pricing, an authentication restriction, and the ambiguity/unknown-name failure mode that returns candidates instead of an entry. Return payload fields are also enumerated.

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 action, then output shape, then pricing and auth caveats — every clause earns its place. Slightly dense phrasing in the second sentence, but no filler.

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

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

For a one-parameter tool with an output schema, the description covers batching, cost, auth restrictions, and return semantics adequately. Missing only edge details like idempotency or rate limits beyond the flat per-call price.

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 schema parameter has 100% description coverage (array of strings or { name, namespace?, venue? }, 1-25 items), so the schema already does the heavy lifting. The description largely restates that item format and defers semantics to 'the same hints as lexicon_resolve', adding only marginal meaning.

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 (resolving up to 25 names against the ChainHelix Agentic Lexicon) and its output shape (entry fields or candidates). The phrase 'in one call' plus the cross-reference to lexicon_resolve makes the bulk-vs-single distinction clear without opening either schema.

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

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

Gives clear context for use: batch up to 25 names, cost of 50 cents per call, and the caveat that a ChainHelix API key does not cover it. It does not explicitly say to prefer lexicon_resolve for a single name, leaving that inference to the agent.

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 no annotations, the description carries the full behavioral burden and does so well: it discloses the cost ($19 per call), that an API key does not authorize it, that each file gets its own download link valid 7 days with a 50-download cap, that patches are included but new versions require a new purchase, and that sha256 hashes accompany every file. These are exactly the side-effect, billing, and expiry facts an agent cannot get 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?

The description is dense but front-loaded: it leads with what the artifact is, then layers contents, delivery mechanics, and price. The semicolon-chained clauses and the fragment 'Price: 19 dollars per call.' are slightly clipped, but every sentence carries information an agent needs.

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

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

Despite an output schema existing (so return values need not be explained), the description usefully specifies the return shape (one download link per file, sha256 per file) and covers contents, licensing, expiry, download limits, and pricing. Nothing an agent needs to decide whether and how to call this tool is missing.

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

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

The tool takes zero parameters (empty properties, additionalProperties false), so per the rubric the baseline is 4. The description adds no parameter information because there is none to add; the x-lexicon metadata block is schema-level context the description correctly does not duplicate.

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 (download) and resource (the whole ChainHelix Agentic Lexicon bundle) and enumerates exactly what the artifact contains: entries, licence texts, attribution table, change log, sha256s. It never names a sibling, so an agent must still infer how this differs from lexicon_bulk or lexicon_resolve.

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 commercial conditions that bear on when to call it ('patches of this version are included, a new version is a new purchase', '$19 per call', 'an API key does not cover this tool'), which is real usage context. However it never explicitly routes the agent to or away from alternatives such as lexicon_bulk or lexicon_resolve, so the when-to-use guidance is implied rather than stated.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses cost (5 cents per call), states that a ChainHelix API key does not cover the tool, and explains the branching return behavior (single entry vs candidates on ambiguity). It omits rate limits and any auth requirements beyond the API-key caveat.

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 paragraph that front-loads the core action before scope, cost, and auth caveats. Every sentence earns its place, though the return-field enumeration and pricing note make it a touch heavy for one block.

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 return shape is already covered, yet the description restates it usefully. It adds the pricing and auth caveats that structured fields do not carry, leaving only minor gaps around rate limits and failure modes.

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 67%, so the description needs to add value, and it does: it explains that venue resolves through ccxt's mapping (e.g. binance) and enumerates namespace options. It slightly undersells the namespace enum by listing 9 of the 11 allowed values (deal and barter are missing).

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: resolving one argument name against the ChainHelix Agentic Lexicon, and spells out what comes back (an entry with id/meaning/representation/unit/example, or candidate names when unknown/ambiguous). It never names a sibling (lexicon_bulk, lexicon_spec, lexicon_bundle) to differentiate itself, 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 implied rather than stated: you call it to resolve a single field name, optionally scoped by namespace or venue. There is no explicit when-to-use versus the sibling lexicon tools (bulk lookup, spec, bundle), and no prerequisites or exclusion conditions are given.

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?

No annotations exist, so the description carries the burden. It does disclose a real behavioral trait: unknown names are refused before payment, with accepted names returned. However, it leaves unclear whether this tool itself is paid, what the output structure looks like beyond a list of names, or rate/access behavior.

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

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

A single dense run-on sentence packing version metadata, bundle hash, namespaces, counts, entry rule, and refusal convention into one breath. Every element has some value, but the structure is hard to parse and front-loading is weak.

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 params and an output schema, the description covers what the tool supplies (names, representation, unit, versioning, provenance rules, refusal behavior). It doesn't restate return shape because an output schema exists, which is appropriate.

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

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

Zero parameters, baseline 4. The description notes an unknown name is refused before payment, but since there are no inputs, little more is needed.

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 specifically what the tool returns: argument names accepted by every tool on the server, with representation and unit, plus version, bundle hash, namespaces and counts. It also clarifies that meanings are not here but in lexicon_resolve/lexicon_bulk/lexicon_bundle, distinguishing it from those siblings.

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

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

Implied usage: it's a discovery/spec lookup, and the note that meanings live in the paid resolve/bulk/bundle tools implies this is the free naming layer. But there's no explicit 'call this first when...' routing statement or when-not guidance.

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

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

No annotations are provided, so the description carries the full burden and does well: it discloses signature scheme (EIP-191), signer, bindings (lexicon version, bundle hash, card hash), refusal behavior for agents with no argument schemas, pricing (3 dollars per call), and that an API key does not cover the tool. It doesn't explain return format, but an output schema exists. Side-effect/refusal behavior is explicit.

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 long, dense sentence with a heavy clause list; the key deliverable is front-loaded, but the middle clause about 'per tool whether canonical names are accepted...' is hard to parse. It is appropriately sized for a complex verification tool, but structure could be clearer with sentence breaks.

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 (conformance checking, signing, payment), the description covers scope, refusals, signature binding, pricing, and auth limitation. An output schema is present, so return values needn't be explained. Only minor gaps (no explicit error behavior for invalid id) remain.

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 fully documented in the schema (type number, ERC-8004 token id on BNB Smart Chain). The description adds no syntax or format beyond what the schema states, 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 deliverable: a signed conformance statement for one ERC-8004 agent, checked against the ChainHelix lexicon. It clearly describes what is evaluated (canonical names, unknown-name refusal, x-vocab coverage, unmapped arguments). It is distinguishable from siblings like lexicon_resolve or lexicon_bundle, though those names aren't explicitly referenced.

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 description (call this to get a conformance statement for an agent), but there is no explicit when-to-use vs. when-not-to-use, nor are alternatives like lexicon_resolve or agent_standing named. The pricing and API-key exclusion are conditional context, not 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 no annotations, the description carries the full burden and does so well above average: it discloses pricing rules for USD valuation, the special handling of Compound v2/Venus seized-token attribution and the protocol-specific change on 2026-10-13, the oracle check semantics (sameTx/prevTx/sameBlock/null) and the data-freshness latency. It does not explicitly state read-only behavior or rate limits, so it stops short of 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?

Content is front-loaded with the purpose, but it is delivered as one very dense run-on paragraph of comma-spliced clauses with no segmentation, making it hard to scan for the window/pricing/oracle rules. Most sentences carry signal, but the lack of structure and the length work against easy 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?

For a two-parameter analytics tool with an output schema already present, the definition supplies everything needed to call it correctly: parameter bounds, chain coverage, valuation methodology, latency, cost, and field-level semantics for the oracle dimension. Nothing critical is missing, though it stops short of explicitly restating safety/read-only characteristics.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It does: 'chain' is documented with the four covered values and the omit-for-all semantics, and 'window' gets units (hours), a default (24) and a maximum (720) that the schema does not express. Minor gap: 'window' type/enum constraints are not fully pinned down beyond these bounds.

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 opening clause states a precise verb+resource+scope ('Lending liquidations per chain, protocol and direction over a window') and then enumerates the exact measures returned (event count, distinct borrowers/liquidators, per-token amounts with USD value). No sibling tool covers liquidations, so the agent can identify it immediately without ambiguity.

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?

Operational guidance is present (window defaults to 24h, max 720h, omit chain for all covered chains, each hour published ~90 minutes after it ends, 2 cents per call), which tells the agent how to call it. However, there is no explicit when-to-use/when-not-to-use framing or reference to any alternative tool for liquidation-adjacent questions, so usage context is only implied.

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