intel

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

With no annotations, the description carries the disclosure burden. It clearly names bearer-token auth or pay-per-call costs, spells out freshness behavior (re-probes every minute, rolling registry), and identifies data sources such as onchain registration and BNB Greenfield. This is substantial operational transparency, though it never explicitly promises no side effects.

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 long, run-on, ungramatical passage that front-loads billing details before stating the subject. The core content is buried in one massive sentence with parentheticals. It packs useful facts but lacks clear organization and conciseness.

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 covering many operational details—auth, payment, freshness, and data types—the description never gives an explicit high-level purpose or clarifies the 'id' parameter. An output schema exists and adds return-structure context, but these gaps make the description only partially complete for reliable agent invocation.

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

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

Schema description coverage is 0% and the description never mentions the 'id' parameter or explains what value it expects. 'One agent' implies id selects an agent, but the description does not state that id is the agent identifier, how to obtain valid ids, or what constraints apply beyond the schema's number 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?

The description lists the resource ('One agent on BNB Smart Chain') and the data included (newest probe, probe history, test hires, evidence records, registration link), but it never states a clear verb such as 'returns' or 'reports'. The ungramatical fragment 'One agent ... read from its own onchain registration' makes the purpose inferable but not crisply 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?

No guidance is given on when to use this tool versus siblings like search_agents or verified_agents. The description only covers authentication and payment prerequisites, not selection criteria or alternative 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 provided, the description carries the full burden and delivers thoroughly: it discloses authentication (API key bearer token), cost and payment rails (5 cents, Binance b402/x402, accepted tokens and networks), on-chain behavior (exact time sealed on opBNB, automatic publish of claim text and salt at reveal time), identity model (paying wallet or key id), and the semantic scope (WHEN, not WHETHER). This is exceptionally transparent for a tool with zero annotation coverage.

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?

Every sentence carries information, but the structure is suboptimal: payment and cost details are front-loaded before the tool's purpose, so the single most important sentence ('Seal any claim on chain now...') appears second. There is also mild redundancy between 'nobody can backdate' and 'seals the exact time of your commitment.' The 160+ word wall of text could be reordered to lead with purpose and keep payment details at the end without losing anything.

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 2-parameter tool with an output schema, this description is complete: it covers auth, cost, payment networks, parameter semantics, on-chain behavior, reveal mechanics, identity, and the tool's philosophical limit, and it points to attest_spec for the verification contract. Nothing an agent needs to call it correctly or interpret its result is 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?

With 0% schema description coverage, the description compensates meaningfully: it explains payload as 'the claim' string and expands revealDelayHours beyond the bare schema type by giving a valid range (1 to 720) and default (72). It could go further by noting payload length limits or units, but the added value over the type-only schema is substantial, covering both parameters.

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 core purpose is stated with a specific verb and resource: 'Seal any claim on chain now, reveal it later, a track record nobody can backdate,' and clarified by 'This attests WHEN you said it, never whether it is true.' This distinguishes the sealing/creating action from siblings like attest_spec, attest_status, list_attestations, and verify_reveal. However, the purpose statement is buried under the payment/auth paragraph, so an agent skimming the first sentence might not immediately know what the tool does.

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 usable guidance: send a claim as payload, optionally set revealDelayHours, and it explicitly routes verification needs elsewhere ('Verification spec: the free attest_spec tool'). It also states a key semantic boundary — 'attests WHEN you said it, never whether it is true' — which tells the agent this is for timestamp commitments, not truth verification. It lacks an explicit when-not-to-use or comparison against list_reveals/verify_reveal, but the included limitation and sibling pointer provide solid context.

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 provided, the description carries the full burden. It implies a read-only query via 'live counts', but does not explicitly state that the tool is side-effect-free, what 'live' means (e.g., real-time polling vs. snapshot), or whether any special access is required. The description gives basic behavioral context but lacks richer detail.

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

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

The description is a single, front-loaded sentence that says 'Live counts' first, then expands with a colon-delimited list of specific metrics. Every word contributes value, and the structure is highly scannable. It is an model of conciseness for a simple 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?

Given the tool has no inputs, an output schema explains return fields, and the tool is a straightforward read-only stats endpoint, the description adequately explains what data is provided. It lacks timing or usage context (e.g., relationship to session_stats), but for its simplicity, it is reasonably complete. The absence of usage guidelines is a minor gap.

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

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

The tool has zero parameters and the input schema is empty, so the description correctly adds no parameter specifics. According to the rubric, the baseline for 0-param tools is 4, and the description introduces no confusion about inputs. It is inconsequential that no parameter details are provided.

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 provides 'Live counts of the attestation stream' and enumerates specific categories (committed, anchored, revealed, gaps), making its function unmistakable. It also distinguishes itself from sibling tools like whale_flows or congestion by focusing on attestation-specific metrics. Though not using a leading verb like 'get', 'counts' effectively conveys the action.

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 offers no guidance on when to use this tool versus alternatives. It does not mention any specific use cases, prerequisites, or exclusions relative to sibling tools. Without a when-to-use section, an agent has little basis for selecting this over other stats 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 must carry the full burden of behavioral disclosure. It does not state whether calling this tool is read-only, what it returns, or how it behaves. The term 'spec' implies an informational resource, but this is not explicit. No information on side effects, permissions, or output format.

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

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

The description is a single sentence that packs in the subject and content. It is not front-loaded with an action verb, making it slightly less effective, but it is compact with no redundant 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?

The description gives the subject matter of the spec but does not state what the tool returns (though an output schema exists), how to obtain it, or how it relates to similar specs like proof_spec. For a simple zero-param resource tool, this is partially complete but lacks usage context.

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

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

The tool has no parameters and the input schema is empty. The description does not need to explain parameter meanings. Baseline of 4 applies due to zero parameters.

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

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

The description identifies the tool as a specification for the attestation service and explains its content (hashing, chaining, verification), but it lacks an explicit verb indicating what the tool does (e.g., returns, provides). This creates ambiguity about the tool's action, though the topic is clear. It does not explicitly distinguish from sibling tools like proof_spec.

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

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

No information is given about when to use this tool versus alternatives like attest or proof_spec. There is no mention of use cases, 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 provided, the description carries the full behavioral burden and does well: it discloses time-dependent reveal behavior, the nonce-specific return semantics, and the eventual inclusion of the opBNB batch transaction and Merkle path. It does not mention auth requirements or error behavior, but for a read-style status tool these are comparatively 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 description is dense but efficient, front-loading the core operation before detailing temporal and nonce-specific behavior. It is one long sentence, which slightly hurts readability, but every clause contributes meaningful information.

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

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

The description covers the main behavioral modes well and even previews output contents, which is helpful given an output schema exists. It is incomplete on input-combination rules, forbidden parameter combinations, and what happens for unknown or unrevealed entries, so an agent may still be uncertain in edge cases.

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 each parameter to a role: tenant plus seq or hash identifies a claim, and nonce selects the paid-answer receipt path. However, it creates ambiguity by suggesting seq or hash are needed alongside tenant while the schema marks only tenant as required, and it does not clarify mutual exclusivity or whether tenant is still needed in nonce mode.

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 uses a specific verb ('Check') and resource ('one sealed claim'), and clarifies the main lookup path by tenant plus seq or hash as well as the nonce-based paid-answer variant. It is clearly about single-attestation status rather than listing, though it does not explicitly name a sibling tool to differentiate from.

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 useful internal mode guidance: before reveal time only the receipt shows, after reveal the claim text and salt appear, and a nonce switches to paid-answer receipts. However, it never states when to prefer this tool over related siblings like list_attestations, verify_reveal, or list_reveals, so tool-selection 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 zero annotations, the description carries the full disclosure burden and delivers substantive operational context: the ChainHelix bearer-token requirement, per-call payment alternatives via b402/x402 with specific tokens and networks, and window bounds. It does not address error behavior or data freshness, but the output schema covers return shape, so the disclosed auth/payment/defaults add real value beyond 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 three sentences are information-dense and every clause carries operational meaning, but the first sentence is a long wall of payment specifics (tokens, networks, b402/x402) that delays the actual purpose statement until the middle. This is not purpose-front-loaded, which reduces scannability for an agent scanning many tool definitions.

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

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

For a simple 2-parameter tool with an existing output schema, the description is nearly complete: auth, payment, network scope, metrics, window defaults, and l2 omission behavior are all covered. Minor gaps such as defining 'proven and finalized' withdrawals or expected latency exist, but nothing blocks a correct invocation.

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

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

Schema description coverage is 0%, so the description must fully compensate, and it does. It explains window units, default, and maximum ('window in hours, default 24, max 720') and l2 semantics including the enumeration of arbitrum, base, optimism and the omission behavior ('Omit l2 for all three'). Both parameters receive complete semantic coverage in prose.

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

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

The description states the tool reports 'Layer two bridge activity for arbitrum, base and optimism' with enumerated metrics (deposits, withdrawals proven and finalized, message counts, value in ETH), giving a specific resource and scope. It is distinguishable from flow-related siblings like stablecoin_flows and whale_flows by its L2-bridge focus, though the purpose is buried behind the payment sentence rather than front-loaded.

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

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

The description provides parameter-level usage guidance ('window in hours, default 24, max 720', 'Omit l2 for all three') that clarifies how to invoke the tool correctly. However, it never states when to choose this tool over alternatives such as stablecoin_flows or whale_flows, offering no explicit when/when-not or sibling 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 reveal important traits: the data is a sampled series with high/low/latest values, and calls require an API key or paid credit. It does not mention rate limits or side effects, but the read-only nature is strongly implied by 'history' and the absence of mutation language. This is solid but 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?

The description is two sentences, but the first is a long, dense list of payment options and token/channel details, which buries the core purpose until the second sentence. The purpose statement itself is efficient, yet the payment preamble is heavier than necessary.

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-optional-parameter tool with an output schema, the description covers the essential invocation context: auth/payment, the data returned, and the window constraint. No return-value detail is needed since an output schema exists, and the description leaves no obvious gap for a correct 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?

The schema provides only 'window' as a number with no description, leaving 0% coverage. The description compensates fully by giving the unit (hours), the default (24), and the maximum (168), which is exactly the semantic content an agent needs.

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

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

The description states the tool provides Bitcoin mempool data over a window, listing specific metrics (fastest fee, transaction count, size) and window high/low/latest summaries. This distinguishes it from general congestion or market-state siblings, though the operative verb is implicit rather than explicit.

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 prerequisites (API key as bearer token, or per-call payment via Binance b402/x402) and parameter constraints (window in hours, default 24, max 168), which are necessary for calling. It does not, however, explain when to choose this over sibling tools like congestion or gas_state, so usage context 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 transparency burden. It discloses authentication requirements and a per-call payment alternative, and it reveals the window parameter's default and maximum. It does not describe rate limits or data freshness, but the output schema exists to cover return shape.

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

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

The description contains useful information in both sentences, but the long and detailed payment/auth sentence is front-loaded ahead of the core functional purpose. The structure would be improved by stating what the tool does first, then adding access requirements.

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-parameter read-oriented data tool, the description covers the purpose, the parameter semantics, and access constraints. An output schema is present, so the description does not need to detail return values. It lacks comparative usage guidance, but that is captured in the usage dimension.

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

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

The schema provides only a bare 'number' for window with 0% description coverage, so the description must compensate. It fully does: 'window in hours, default 24, max 720' gives the unit, optional behavior, and bounded range, making the parameter actionable.

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 identifies the resource: 'Ethereum block builder market over a window' and lists the specific metrics delivered: 'blocks delivered and value per relay, and the top builders by blocks.' It lacks an explicit verb like 'list' or 'get', but the intent is unambiguous and distinct from the sibling tools.

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

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

The description gives no guidance on when to choose this tool over alternatives or what use case it serves relative to siblings like mev_intel or mev_bots. It states prerequisites and parameters, but not selection criteria 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 provided, the description carries the full burden and does so thoroughly. It discloses multi-step behavior: the call returns a payment address, amount, and claim token rather than the key itself; orders expire under specific time windows; and email is conditionally required for the alerts plan. This is rich, non-obvious behavioral information.

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 every sentence contributes necessary operational information: purpose, plan details, payment chain, return values, next step, expiration policy, and email requirements. It is front-loaded with the core purpose and contains 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 payment-flow tool, the description covers the full invocation context: what is returned, what the agent must do next, how long orders remain valid, and when email is required. The output schema is listed as present, so the description's lack of detailed return-value formatting is acceptable.

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%, but the description fully compensates by explaining all three parameters: plan options with pricing and rate limits, chain options with the full enum, and email with conditional requirements. It adds meaning well 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 opens with a specific verb and resource: 'Buy a ChainHelix API key without a browser or account.' It clearly distinguishes the tool's purchase role from the sibling claim_key tool by explaining that this tool returns a claim token and payment details, and that claim_key must be called afterward.

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

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

The description gives clear context for when to use the tool: to buy an API key programmatically. It also provides workflow guidance by stating 'Send the exact amount, then call claim_key,' which routes the agent to the next tool. It does not explicitly name alternatives or exclusion conditions, but the workflow is strongly 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?

No annotations are provided, so the description carries the full burden. It discloses the authentication/payment model (API key bearer token or 2 cents via b402/x402), the data fields, the maximum 500-candle limit, and the newest-last ordering. It does not mention rate limits or error behavior, but the read-only nature is implied by 'Price history'.

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 dense paragraph that mixes payment details with data specifications, making it less scannable. It is not excessively long, but the payment information is front-loaded ahead of the core purpose, and all details are packed into one long sentence.

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 are covered. The description covers authentication/cost, data scope, limit, and ordering, leaving only minor gaps such as default values and error behavior. This is adequate for a straightforward data-fetch tool, especially given the output schema.

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 explain parameters, and it does: 'one chain' maps to chain, 'any of fourteen timeframes from one minute to one week' maps to timeframe, and 'up to 500 candles' maps to limit. It adds meaningful constraints beyond the raw schema, though it does not address defaults or optionality beyond the schema's required field.

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

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

The description clearly states that the tool returns price history (OHLCV plus trade count) per candle for one chain, with timeframe and limit constraints. It is specific enough to be distinguished from sibling tools like 'prices' or 'market_state', though it does not explicitly name an alternative.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'prices' or 'market_state'. It states operational constraints (single chain, up to 500 candles, newest last) but lacks any selection criteria, exclusions, or context for choosing it over siblings.

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

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

With no annotations provided, the description carries the behavioral disclosure burden and does a solid job: it explains authentication requirements, the pay-per-call option, the aggregated nature of the read, and that failed sections are reported under 'unavailable'. It also implicitly signals read-only behavior through the word 'read'. It could add more about rate limits or response format, but the output schema helps close that gap.

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

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

The description is a moderate length and each sentence carries substantive information, but the payment and authentication details dominate the front-loaded first sentence, delaying the core purpose. The middle sentence is a long list without clear separators. It is structured well enough to parse, but not as crisp and scannable as it could be.

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

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

For a tool with a single required parameter, an output schema, and no annotations, the description is fairly complete. It covers authentication, cost, the main data sections, Bitcoin-specific scope, and failure reporting. The main missing piece is explicit guidance on when to prefer this tool over the sibling single-metric tools, but that gap is already accounted for in the usage guidelines dimension.

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%, and the description does not enumerate or explain the 'chain' parameter values beyond 'One chain' and the Bitcoin mempool special case. However, the parameter name and enum in the schema already provide the allowed values, and the description adds meaningful nuance by noting the Bitcoin-specific behavior. This is adequate for a single self-explanatory enum parameter, but it does not fully compensate for the lack of schema descriptions.

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 communicates that this tool produces a comprehensive single-chain read, listing concrete data sections such as market state, price walls, large transfers, bot activity, open interest, stablecoin flows, and Bitcoin mempool. It distinguishes itself from narrower sibling tools by emphasizing 'the whole read in one answer'. However, it lacks an explicit verb like 'get' or 'generate', so it is slightly less direct than ideal.

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 'One chain, the whole read in one answer' implies using this tool when a complete multi-metric overview of a single chain is desired, as opposed to calling individual metric tools. It does not explicitly name alternatives or state when not to use it. The usage context is present but left to inference.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the critical one-time-only return behavior ('returned exactly once' and 'save it'), and the typical claimable delay. For a redeem/claim operation this is important non-obvious 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?

Three sentences, about 33 words, with the core action stated first and each following sentence adding essential context. No filler or repetition — efficient and front-loaded.

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

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

For a single-parameter tool with an output schema, the description covers the essential logic: the action, the prerequisite timing, and the one-time return behavior. It could be more complete with a pointer to checking order status first, but overall it equips an agent to call it correctly.

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

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

With 0% schema description coverage, the description must compensate, but 'Takes the claim token' only restates the parameter name. It does not clarify the token's format, origin, where to obtain it, or how a user connects it to a prior buy_key order — leaving the only parameter under-specified.

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 a specific verb ('Claim') and a specific resource ('API key for a paid buy_key order'), distinguishing it from sibling tools like buy_key and key_order_status. It immediately conveys the action and the object acted upon.

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

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

The description gives clear prerequisites and timing context — payments become claimable within 30 minutes of confirming on chain — which tells an agent when this tool becomes applicable. It doesn't explicitly name alternatives or when-not-to-use conditions, but the timing guidance effectively implies do-not-use-before-payment-settlement.

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 of disclosure. It does reveal an important access behavior: a ChainHelix bearer token or pay-per-call payment is required. However, it does not state read-only-ness, failure modes, or any side effects, leaving the behavioral profile mostly 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?

The description is short and contains no purely redundant sentences, but the payment requirement is front-loaded ahead of the tool's actual purpose. The core data description would be better placed first for quick agent comprehension.

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

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

For a zero-parameter tool with an output schema, the description is largely complete: it states what data is returned and the access/payment prerequisites. It omits comparison with sibling tools, but that is not essential for making the 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?

The tool takes zero parameters, so there is no parameter documentation burden. The schema coverage is trivially complete, and the description does not need to clarify any 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 clearly specifies the resource: Bitcoin queue depth now versus the past 30 days, plus the current fastest fee. This is a concrete, identifiable function, though it lacks an explicit verb like 'gets' or 'returns' and does not name a sibling tool for differentiation.

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 about when to use this tool versus alternatives such as btc_mempool_history. The description states access and payment requirements but not the selection context 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 provided, the description carries the full behavioral burden. It discloses authentication and payment requirements, the window unit, default, and maximum. It does not explicitly state read-only behavior or output format, but the operation is clearly analytical and the output schema exists.

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

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

The description is compact and contains no filler, but payment details are front-loaded ahead of the actual purpose, which slightly hurts scanability. Each sentence adds necessary information: authentication/payment, the computation, and window constraints.

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 one parameter is fully described with units and bounds, the output schema covers return shape, and the core computation is clear. The main gaps are that the 'nine chains' are not enumerated and no usage context against sibling tools is given, but the definition is largely 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%, so the description must compensate for the single 'window' parameter. It does: it explains that window is measured in days, defaults to 7, and has a maximum of 30. This is meaningful semantic information beyond the bare number type in the schema.

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

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

The description states the tool computes pairwise correlation of hourly returns across nine chains, which clearly identifies the data product. It lacks an explicit verb like 'compute' or 'return', and does not explicitly distinguish it from related data tools like prices or candles, but the resource and calculation are specific enough.

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

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

The description provides prerequisites (API key or payment) but gives no guidance on when to use correlation_matrix versus alternatives such as prices, candles, or market_state. No exclusions, use cases, or decision criteria are provided.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It usefully states that the tool returns one hash per day and that the digest covers records stored that day, but it does not explicitly describe read-only behavior, edge cases, or what happens when no data exists for a requested date.

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 compact sentence with no filler. It front-loads the core result concept, then the data origins, the platform, and the parameter behavior. It is dense but efficient.

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

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

For a simple, one-optional-parameter read tool, the description provides enough behavior about the returned digest and the default date. Context signals indicate an output schema exists, so the description does not need to explain return format in detail. It is complete for basic invocation but does not cover timezone or missing-data 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?

The schema only defines 'date' as a string, so the description adds the critical format, optionality, and default behavior: 'YYYY-MM-DD' and default to the latest. This compensates well for the schema's near-zero parameter documentation, though it leaves out timezone 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 clearly identifies the resource as a single daily Merkle digest covering reveals, hire deliverables, and verification records stored on BNB Greenfield, with the root sealed on opBNB. It lacks an explicit verb like 'get' or "retrieve', but its meaning is unmistakable. The Merkle-digest framing also helps distinguish it from sibling reporting tools.

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

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

The description provides no guidance on when to use this tool instead of alternatives such as list_reveals, agent_report, or attestation_stats. It only explains the optional date parameter and its default, which is parameter guidance rather than tool-selection guidance.

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

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

No annotations are provided, so the description must carry behavioral context. It does disclose the return contents (date, tools affected, count) and the optional filtering/limit behavior. However, it omits ordering, default limit behavior, and whether the operation is strictly read-only, leaving some behavioral ambiguity.

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 efficiently packed sentence with no filler. It front-loads the core purpose, lists concrete content examples, and then gives parameter hints at the end. Every clause adds useful information.

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

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

For a simple two-parameter tool with an output schema, the description covers the core functionality, return-field concepts, and optional parameters. It is slightly incomplete regarding ordering or what happens when no limit is provided, but these are minor given the simple interface and existing output schema.

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 0% description coverage, so the description must compensate. It does: 'tool' is explained as an optional name filter and 'limit' is identified as a limit on results. It does not spell out the exact semantics of limit (e.g., maximum number of records), but the meaning is reasonably inferrable.

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 identifies the tool as a dated record of every data change sold by the server, with concrete examples (rule flips, label fixes, duplicate removals, band versions, sample notices). This is specific enough to distinguish it from all sibling tools, none of which is described as a changelog. The resource and scope are unambiguous.

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

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

The description explains that an optional tool name can filter and a limit can be supplied, but it gives no guidance on when to choose this tool over alternatives such as freshness, latest_signals, or situation_report. There are no explicit when-to-use or when-not-to-use 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 provided, the description carries the behavioral burden. It usefully discloses the payment/auth model and the presence of on-chain verification links. However, it does not disclose rate limits, latency, failure behavior, side effects, or what happens when payment is not provided. This is partial but meaningful transparency.

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 reasonably compact and the second sentence efficiently enumerates the report components. However, it opens with payment details rather than the tool's purpose, and closes with a marketing claim. Its structure is serviceable but not front-loaded for quick understanding.

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 aggregate report tool with one optional enum parameter and many sibling tools, the description lacks parameter semantics and decision guidance. It also leaves unclear what 'nine chain' means in relation to the chain parameter. The output schema exists, but the description still misses key operational context needed to invoke it correctly.

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

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

Schema description coverage is 0%, and the description never mentions the only parameter, chain. The enum values make the parameter self-explanatory at a basic level, but there is no guidance on whether omitting chain means all nine chains or whether chain filters the report. The description fails to compensate for the schema's lack of description.

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 what the tool produces: a 'complete nine chain research brief' containing market report, signal stream, correlations, options volatility, session stats, and proof counters. It names concrete content areas, though it lacks an explicit verb like 'get' and does not sharply distinguish itself from closely related report tools beyond calling itself 'the most complete.'

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

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

There is no guidance on when to use deep_report versus sibling tools such as chain_brief, situation_report, or latest_signals. The description only claims it is the most complete answer, which is not actionable routing guidance. Payment requirements are stated, but selection criteria and exclusions are absent.

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

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

No annotations exist, so the description carries disclosure about it being free, returning a hash and expiry, and checking the current default result. This reasonably indicates a non-destructive query even though it does not discuss rate limits, errors, or indicators of mutation beyond 'check'.

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 three sentences with no filler. It front-loads the core value, then gives the condition (hash match) and the optional parameter. Each sentence adds unique information.

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

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

With an output schema present, the return value does not need description-level detail. The description sufficiently covers how the name parameter adjusts behavior (all vs. one tool), and it provides the check-before-pay use case. Nothing essential for 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 provides zero field descriptions, so the description must cover parameter meaning; it does by explaining the optional 'name' selects one tool, while omitting it covers every data tool. This gives the cardinality and optionality of the parameter, even if it does not enumerate accepted name values.

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

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

The description clearly states an action ('free check'), a target resource ('content hash and validUntil of ... default result'), and an all-chains scope. It is immediately differentiable from the buy/attest sibling tools because it positions itself as the pre-purchase freshness check.

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?

'Free check before you pay' tells the agent when to invoke this tool, and the hash-equality explanation shows when no purchase is needed. It stops short of explicitly naming alternatives, but the timing and decision context are clear enough.

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 significant behavioral traits: the ChainHelix bearer-token requirement, the 2-cents-per-call cost, and the specific payment rails (Binance b402, x402) and token types accepted. It stops there, though — rate limits, latency, response behavior, and whether the call is a pure read are not addressed, leaving the disclosure partial.

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 run-on sentence that front-loads a heavy payment clause (b402/x402, four token types, two networks) before stating what the tool does. The core purpose arrives mid-sentence, which forces an agent to wade through billing details to find the function — poor scanning structure.

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 tool with an output schema present, the description covers the essentials: auth requirement, cost model, and the all-nine-chain default. However, it gives no tool-selection context to differentiate it from more than 50 siblings and reads poorly, so it is adequate but not fully complete for confident agent routing.

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%, and the description adds the one genuinely non-obvious semantic: 'Omit chain for all nine,' which explains the default behavior of the optional chain parameter. For a single enum parameter whose values are self-explanatory chain names, this is the only real meaning needed beyond the schema, so it compensates adequately.

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

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

The description states the deliverable specifically: 'Network load per chain: latest transaction count, MEV count and rate, average gas and large transaction count, against the 24 hour average of each.' This is concrete enough to distinguish it from data-focused siblings like market_state or congestion. However, it lacks an explicit verb and buries the functional statement behind a long payment clause, so it is clear but not crisp.

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

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

There is no guidance on when to choose gas_state versus siblings such as congestion, chain_brief, or mev_intel, and no mention of exclusions or alternatives. The only usage note, 'Omit chain for all nine,' addresses parameter behavior rather than tool selection, so an agent gets no help deciding if this is the right tool for the task.

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 burden and does disclose authentication and payment requirements, the window default/maximum, and 'most active first' ordering. It does not discuss errors or limit semantics, but the output schema covers return shape, so the main behavioral caveats are addressed.

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 and every sentence carries information, but it is not front-loaded: the long API-key/payment sentence precedes the actual purpose of the tool. The purpose could be stated first for easier agent scanning.

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

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

For a read-oriented data tool with an output schema, the description covers authentication/payment, parameter defaults, valid range, and ordering. It is missing only limit semantics and a clarification of behavior when space is omitted; otherwise it is sufficiently complete.

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

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

The description adds valuable meaning for space (with a concrete example id) and window (units, default, max), but it never explains the limit parameter. Since schema descriptions are 0%, leaving one of three parameters undocumented is a 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 identifies the resource (Snapshot DAO governance) and the returned data (proposals, votes, scores per space), including a sort order. It lacks an explicit verb like 'get' or 'list', but the subject matter is specific enough to distinguish it from the broad report/intel 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?

It gives clear context—Snapshot space, time window, and ordering—so an agent can infer when to call it. However, it never states when NOT to use it nor names alternative tools for similar governance/DAO queries, leaving selection guidance implicit.

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

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

With no annotations, the description carries the full behavioral disclosure burden, and it does so thoroughly: deterministic arithmetic, no custody, no execution, no fee/PnL computation, wallet-signed quote, escrow payment, and the distinction between the free call and the paid job. It also points to the agent card for the authoritative 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 long but dense, front-loading the core purpose and output before financial caveats and workflow details. Every sentence carries useful information, such as the example, the free-vs-paid distinction, and the agent-card link. It could be tightened, but nothing here 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?

The description is complete for a complex tool with 9 parameters, nested objects, and an output schema. It explains the input contract, output shape, behavioral limits, payment flow, and example payload. The existence of an output schema means return values need not be re-described, and nothing essential for invoking the tool correctly is missing.

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

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

Schema description coverage is 100%, and each property already has a detailed description with defaults, ranges, and accepted aliases. The tool description adds an example and states that price and budgetUsd are required, but does not materially elaborate on parameter meanings beyond the schema.

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

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

The description names a specific verb and resource ('Plan a hire of the ChainHelix gridtrader agent') and then states exactly what the tool computes: a symmetric buy/sell grid from a mark price and budget. It also distinguishes itself from other hire_plan_* siblings by specifying the gridtrader agent and the behavior (equal USD size per level, wall annotations).

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

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

The description gives clear usage context: it is a free planning call that returns a quote and calldata, while the actual job is paid. It also explicitly warns this is not a bounded-loss or profit-target strategy and that fees/slippage/gas/PnL are not computed. However, it does not name any alternative sibling tool for cases where those features are needed, so it stops short of explicit alternative routing.

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

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

No annotations are provided, so the description fully carries the transparency burden. It discloses that arithmetic is deterministic, there is no custody and no execution, the call is free while the job is not, the returned quote is wallet-signed, and the caller must sign createJob calldata, fund, and notify the agent. This is a very complete behavioral profile for a tool that plans an on-chain job.

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 not bloated for a two-mode tool with 8 parameters. It front-loads the purpose and then explains modes, cost, and workflow. It loses the top score because the final sentence packs signing, funding, escrow, and agent notification into one overloaded sentence, and the agent-card URL plus example partially duplicate schema content.

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

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

Given the tool's complexity, an output schema exists, and no annotations are provided, the description still covers all critical operational knowledge: mode selection, returned health data, free versus paid workflow, wallet-signing requirement, funding and agent notification, plus a link to the full agent card. An agent has enough context to select and invoke the tool correctly.

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

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

The schema already has 100% description coverage, including aliases, defaults, and required groupings, so the baseline is 3. The description adds meaningful semantic framing by explaining the lending-vs-LP mode choice, giving a concrete JSON example, and noting 'one question per job.' That pushes it above the baseline, but the schema itself is already doing most of the parameter documentation.

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 sentence states a specific verb ('Plan a hire') and a concrete resource ('the ChainHelix healthmon agent') with its domain ('Position health report'). It then clearly distinguishes the two supported modes, lending health and LP range health, so an agent can tell exactly what this tool does even alongside sibling hire_plan_* tools.

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

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

The description gives explicit guidance on when to send collateral/debt/prices versus position: 'LP range health: send position {price, lowerPrice, upperPrice} instead of collateral and debt.' It also clarifies the free-call/paid-job split. However, it does not explicitly name sibling tools like hire_plan_gridtrader or hire_plan_rebalancer as alternatives, so selection among the hire_plan_* family relies mostly on the name and inferred domain.

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 thoroughly: it discloses deterministic arithmetic, no custody, no execution, a free call versus a paid job, escrow payment, and a wallet-signed quote. It also warns that the job itself is not free, which is critical financial context.

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

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

The description is long but dense: it front-loads purpose and outputs, then explains process, pricing, and the authoritative schema location. Each sentence carries information relevant to correct invocation, and the length is justified by the complex hire/escrow flow.

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, an output schema, and a blockchain funding flow, the description covers behavior, outputs, cost, required next steps, and schema location. It tells an agent everything needed to invoke it correctly and interpret the response, with the output schema carrying return-value details.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including aliases, defaults, and required inputs. The description only adds a high-level example and notes that the parameters match the agent card, which does not materially deepen parameter understanding beyond the schema.

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

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

States a specific action and resource: 'Plan a hire of the ChainHelix rebalancer agent' (ERC-8004 #269223), and enumerates concrete outputs (current vs target weights, drift, ordered trade list, residual cash). This clearly distinguishes it from sibling planning tools such as hire_plan_gridtrader or hire_quote.

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 conveys the intended flow: send job parameters, receive a quote and createJob calldata, then fund. However, it never explicitly says when to choose this over hire_plan_gridrader, hire_plan_healthmon, hire_plan_yieldopt, or hire_quote, so usage context is implied rather than explicitly directional.

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 provided, the description carries the full behavioral disclosure burden and does so thoroughly. It explicitly states 'Deterministic arithmetic, no custody, no execution', clarifies that 'This call is free; the job is not', and explains the escrow payment and wallet-signing flow. This gives an agent a clear mental model of side effects, costs, and what will happen after invocation.

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 long but each sentence serves a purpose: scope, inputs, outputs, behavioral guarantees, cost, workflow, schema pointer, and example. It is front-loaded with the core purpose and only then adds operational details. Slightly verbose, but not padded; the inclusion of a concrete JSON example earns the structure a strong score.

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 hire-planning tool with nested objects, no annotations, and an output schema, this description is remarkably complete. It covers input expectations, constraints, output shape, the wallet-signed quote, escrow funding, and next steps. It even points to the official agent card schema. With an output schema present, return-value details do not need repetition, and nothing essential for correct invocation is missing.

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

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

The input schema already describes every parameter, including aliases, defaults, and constraints, so schema coverage is 100%. The description adds a clarifying example and notes that the parameters exactly match the agent's own card, but it does not substantially extend the parameter semantics already present in the schema. 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 opens with a specific verb and resource: 'Plan a hire of the ChainHelix yieldopt agent'. It further distinguishes this tool from sibling hire_plan_* tools by naming the exact agent, its ERC-8004 identifier, and the yield-allocation problem it solves. The expected outputs are also stated: per-pool allocation, blended APY, and unallocated capital.

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 clearly establishes when to use the tool: to plan a hire of the yieldopt agent and receive a quote plus createJob calldata. It gives strong context about the workflow and that the planning call is free. However, it does not explicitly compare against sibling hire_plan_* tools or state when not to use it, so it falls just 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 provided, the description carries the full burden of disclosure. It reveals required authentication, payment mechanisms, the process of sending task details and receiving a signed offer envelope, and the constraint that only agents on the live map are hireable. This is substantially more transparent than typical tool descriptions.

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 not overly long. However, it opens with payment and authentication details before stating the core purpose, which hurts front-loading. The second sentence packs multiple ideas into a long run-on, making it harder to parse.

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 description covers payment, auth, and the general flow, and an output schema exists, so return values do not need explanation. Still, the meaning of the required 'id' parameter is missing, and 'terms' is only vaguely implied. For correct invocation, the agent needs more clarity on how to identify the hireable agent.

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%, and the description only maps 'task_description' and 'terms' semantically. The required 'id' parameter is never explained, leaving the agent unsure what identifier should be supplied. This is a significant gap given the schema provides no descriptions.

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's function: asking a hireable agent on BNB Smart Chain for a live signed ERC-8183 quote via ChainHelix. This is specific enough to distinguish it from the related hire_plan_* siblings, though it does not explicitly name alternatives.

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

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

The description provides important usage context: the caller needs a ChainHelix API key or payment, the target agent must be hireable per the live map, and the user must send a task description and terms. However, it does not explicitly state when to prefer this tool over alternatives like hire_plan_* or search_agents.

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 discloses important operational behavior: authentication requires a ChainHelix API key as bearer token, or payment of 2 cents per call via specified Binance/x402 payment rails. This is valuable transparency about cost and credentials. It does not describe response shape, but an output schema exists and this is a read-only data lookup.

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 contains no redundant sentences, but it front-loads a long payment prerequisite before stating the actual purpose. For an agent selecting a tool, the 'what it does' information should come first. The purpose sentence itself is clear and compact.

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

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

For a zero-parameter query tool with an output schema, the description covers the essential context: what data is returned and the unusual auth/payment requirements. It does not explicitly contrast with options_skew, but the core invocation details are sufficiently complete.

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

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

The tool has zero parameters and the schema is fully covered, so there are no parameter semantics to document. The baseline for a no-parameter tool is 4, and the description appropriately adds no irrelevant parameter detail.

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

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

The description states the tool returns near-term option implied volatility for Bitcoin and Ethereum, comparing now versus one week ago. This identifies a specific data resource and metric, though it is phrased as a noun phrase rather than an explicit verb like 'get' or 'retrieve', and it does not differentiate from the similar-sounding options_skew 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?

There is no guidance about when to use this tool versus alternatives such as options_skew or other market data tools. The description implies usage through the data content but does not provide selection criteria, exclusions, or context for choosing this tool.

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?

There are no annotations, so the description carries the full burden. It correctly frames the tool as non-mutating ('check', 'reports') and discloses the two behavioral facts that matter: whether payment has been seen and whether the key is ready to claim. This is enough for an agent to know the operation does not claim or alter the order itself.

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

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

The description is two tight sentences, with the main purpose stated first and the return semantics following immediately. There is no filler, redundant phrasing, or repetition of schema 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?

For a simple read-only status tool with a single parameter and an output schema, the description covers the essential context: the ordering relationship with buy_key, the claim token input, and the two status dimensions the agent needs. It is complete enough for an agent to decide to call it and interpret what it means.

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

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

The schema has 0% description coverage and only one parameter, claim_token. The description does mention that the tool 'takes the claim token', which gives the parameter meaning beyond its type, but it does not specify where the token comes from or its format. For a single opaque token, this is acceptable but not richly informative.

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 operation ('Check a key order'), identifies the originating action ('created with buy_key'), and tells the agent exactly what the tool reports (whether payment was seen and whether the key is ready to claim). It clearly positions itself as the status counterpart to buy_key and claim_key, which is enough to differentiate it from its 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?

The description clearly signals when to use the tool: after creating a key order with buy_key, to check payment status and claim readiness. It does not explicitly state when not to use it or name alternatives like claim_key, but the context is strong enough that an agent can infer the ordering.

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 discloses authentication via a ChainHelix API key bearer token or payment options (6 cents via Binance or x402), making access and cost behavior transparent. It also discloses that each signal is sealed on-chain immediately and cannot be edited afterward, an important integrity guarantee. This goes beyond minimal descriptions.

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

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

The description is concise but opens with a long payment sentence before stating the core purpose in the second sentence. While every sentence carries needed operational detail, the structure buries the primary function behind payment specifics. A more front-loaded structure would improve scannability.

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

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

Given the output schema exists, the description need not explain return values. It covers auth/payment, ordering, data integrity, parameter constraints, and verification path. The only notable omission is the explicit meaning of the chain parameter, but overall the description is sufficiently complete for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It states 'Optional chain, and limit up to 50,' clarifying that chain is optional and limit has a maximum not visible in the schema. However, it does not explain the semantic meaning of chain as a filter or the default/ordering behavior of limit, leaving some ambiguity.

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

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

The description states 'The live ChainHelix signal stream, newest first,' which identifies a specific resource and ordering. It also enumerates the signal fields (chain, direction, entry price, win probability, conviction score, ranking tier), making the tool's function concrete. It does not explicitly differentiate from siblings, but the name and stream concept make its role clear.

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 suggests that verification should be done through the separate free proof tools, implicitly distinguishing between fetching signals and verifying them. Payment/auth requirements are stated up font, which clarifies prerequisites for use. It lacks explicit when-not-to-use alternatives, but the live-stream context and mention of verification tools provide reasonable 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 provided, the description carries the full behavioral disclosure burden. It transparently covers authentication requirements, per-call payment methods and costs, window bounds, and the behavior of omitting the chain parameter. It does not explicitly state read-only semantics, but the nature of the data suggests a safe query operation.

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 efficient, covering billing, data scope, metrics, and parameter semantics in four sentences. The billing detail is front-loaded rather than the purpose, which slightly hurts scannability, but every sentence contributes necessary information.

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

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

Given the 2-parameter schema, absent annotations, and presence of an output schema, the description is largely complete: it addresses auth, cost, aggregation dimensions, parameter ranges, and chain coverage. Minor gaps include not clarifying whether 'protocol' and 'direction' are filterable parameters or output dimensions, and no mention of pagination or rate limits.

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 fully explain the parameters. It does: 'window' is described with units, default, and maximum, while 'chain' is described with the full enum list and the behavior when omitted. Both parameters receive complete semantic coverage beyond the bare input 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 clearly identifies the resource as lending liquidation data aggregated per chain, protocol, and direction, including specific metrics like event count, borrowers, liquidators, debt covered, and collateral liquidated. It lacks an explicit verb such as 'returns' or 'retrieves', and does not directly differentiate from siblings, but the tool's purpose is unmistakable.

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 when to use the tool—whenever lending liquidation metrics are needed—and provides concrete usage constraints such as window defaults, maximum window, and chain omission behavior. However, it offers no explicit comparison to alternative tools or when-not-to-use 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 burden and adds useful behavioral details: newest-first ordering, matured claims include text and salt, and optional limit up to 200. It does not disclose pagination or error behavior, but the core behavior is transparent enough for a read-only list operation.

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

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

The description is two sentences, front-loaded with the core purpose, and every word adds value. It covers scope, ordering, content, and limit constraints without fluff.

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

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

For a simple two-parameter list tool with an output schema, the description is complete: it defines the tenant scope, ordering, special case for matured claims, and limit. The output schema presumably covers return fields, so no further return documentation is needed.

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%, but the description explains both parameters: 'tenant' is the scope (tenant's stream) and 'limit' is optional with a max of 200. This compensates for the empty schema descriptions, though it doesn't specify tenant format or limit type beyond 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 clearly states the tool lists a tenant's full sealed-claim stream, sorted newest first. It distinguishes from sibling tools like list_reveals by specifying 'sealed-claim' and mentions matured claims include text and salt, making the resource and scope explicit.

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 usage for retrieving a tenant's claims but does not explicitly state when to use this versus alternatives like list_reveals or attestation_stats. No exclusions or alternative tool references are given, so guidance is only implicit.

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

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

Because no annotations are provided, the description must carry the behavioral disclosure burden, but it only adds 'Matured' and 'with Merkle paths.' It does not disclose that this is a read-only operation, how filtering or ordering behaves, what the default limit is, or any consequences of the optional parameters.

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 economical, placing the most useful facts about the resource, Merkle paths, and optional filters into two short clauses. It earns a high score for brevity and front-loading, even though it could have used additional sentences for critical guidance.

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

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

For a simple optional-parameter list with an output schema, this is enough to make an initial invocation plausible, but it lacks a stored context: no read-only annotation, no definition of 'matured,' and no clarification on limits or filter scope. An agent could still call it correctly, but with some ambiguity.

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%, but the description adds some value by specifying the YYYY-MM format for the month parameter and confirming that month and limit are optional. However, it does not explain the meaning of limit, its range, or whether month filters by reveal creation, maturity, or something else.

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 that this tool returns 'matured signal reveals' with Merkle paths, identifying a specific resource and a notable qualifier. It is not a mere tautology and hints at differentiation from sibling tools like latest_signals and verify_reveal, though the meaning of 'matured' is not fully explained.

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 guidance about when to use this tool versus alternatives such as latest_signals or verify_reveal. It implies filtering via optional month and limit, but it never states conditions, exclusions, or scenarios where a sibling would be more appropriate.

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 provided, the description carries the full behavioral burden. It usefully discloses that a ChainHelix API key bearer token is required, or a 2-cent per-call payment via specific payment rails. It does not mention rate limits, latency, or freshness, but the data-query nature is clear from the listed indicators.

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 and contains no filler; it packs requirements, cost, output indicators, and parameter default behavior into one paragraph. It could be more readable with better separation between payment details and core functionality, but 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?

The description gives enough context for a one-optional-parameter data tool: what data is returned, which timeframes and indicators are covered, and what happens when chain is omitted. The output schema presumably covers the return structure, so missing details about exact output formatting are acceptable.

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 optional chain parameter has no schema description, but the description compensates by stating that metrics are per chain and that omitting chain returns all nine chains. It clearly explains the default behavior, while the schema already provides the valid enum values.

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

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

The description clearly states what the tool returns: regime, range age, volatility state, and momentum per chain, with concrete indicators like RSI 14, MACD 12/26/9, and 4h EMA trend. It is not a tautology, but it lacks an explicit verb such as 'fetches' or 'returns' and does not differentiate itself from sibling tools like chain_brief or situation_report.

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

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

The description provides no when-to-use guidance or alternatives. It explains authentication and payment requirements and the 'omit chain for all nine' behavior, but an agent is given no explicit help choosing this tool over the many related sibling 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 provided, the description carries the full behavioral disclosure burden and does so well: it states the bearer-token requirement, the alternative per-call payment method, the ordering by detections, and the defaults/max for active_hours and limit. It does not explicitly proclaim read-only behavior or rate limits, but nothing suggests side effects or mutation. This is strong supplementary context beyond 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 a dense run-on block that opens with billing/payment details before stating the tool's core purpose, burying the most important information. Payment, return fields, ordering, defaults, and chain coverage are all mashed into one flowing passage with minimal separation. It is not concise in an effective way; it is under-structured and hard to scan.

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 does not need to detail the return structure, and it supplies most invocation-critical context: required chain, optional parameter bounds, supported chains, and ordering. It covers the unusual authentication/payment mechanism thoroughly. Minor gaps like pagination or empty-result behavior remain, but an agent has sufficient information to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does: chain values are explicitly listed, and limits/active_hours receive default and maximum values. However, it does not explain what active_hours semantically means (e.g., lookback window) or what limit caps (number of returned records). The defaults add useful bounds but not full parameter 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?

The description clearly identifies the resource: active MEV bot addresses on a chain, and enumerates the returned fields (detections, strategy types, first/last seen, high confidence flag). The scope is a per-chain query, and the supported chains are listed. It does not use an explicit verb like 'list' or 'get', and it does not differentiate from the similar sibling mev_intel, but the purpose is unambiguous enough.

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

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

The description provides implied usage context by listing the supported chains and explaining the API key/payment preconditions that must be met before calling the tool. It does not compare against siblings such as mev_intel, and there is no explicit statement of when to use this tool instead of another. An agent can infer when it applies, but routing guidance is absent.

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

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

With no annotations present, the description carries the full behavioral burden and does so well. It discloses the API-key or pay-per-call requirement, the trailing-weekly baseline, the overlap between backrun and arbitrage rows with a warning not to sum types, and the ERC-721-only NFT coverage limitation.

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 and every sentence carries operational value: auth/payment, metric definition, window bounds, type-overlap warning, NFT coverage, and supported chains. The core function appears after the auth/payment sentence, so it is not perfectly front-loaded, but the details are concise and not padded.

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

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

Given the output schema exists, the description does not need to explain return shape. It covers parameters, chains, behavioral caveats, and access requirements well. The main missing piece is guidance on when to choose this tool versus related sibling tools like mev_bots, and the payment/auth complexity is described but not simplified into a clear call-decision.

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 the bare parameter names. It does this by explaining that window is in hours with a default of 24 and max of 168, and by listing the covered chains. It does not clarify whether chain is optional or how multiple chains are handled, but it adds substantial meaning beyond the schema.

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

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

The description clearly states the tool provides MEV event rates per chain and type, compared to the trailing weekly pace. It is distinct from the sibling mev_bots tool, which likely focuses on bot behavior rather than rate metrics, though the description does not explicitly name or contrast the sibling.

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

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

The description gives parameter usage details (window hours, defaults, max) and auth/payment requirements, but provides no explicit guidance on when to use this tool versus alternatives such as mev_bots or other market-state tools. No conditional routing or exclusion statements are included.

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 must carry the behavioral disclosure burden. It does so well by exposing the authentication/payment requirement, the window semantics (hours, default 24, max 720), and the composition of the returned data. It does not explicitly state that the operation is read-only, but the data-oriented framing makes that reasonably clear.

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 relatively compact but poorly front-loaded: it opens with billing details before stating the tool's actual function. The payment information is detailed and useful but occupies a large share of the description, pushing the core purpose into the middle. It is not overly verbose, but the structure could better serve quick agent comprehension.

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 data-fetching tool with an output schema, the description covers chain selection, window constraints, output fields, and access requirements. Minor gaps remain, such as what exactly 'sampled series' means and behavior on invalid inputs, but nothing essential blocks a correct 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%, and the description compensates strongly: it explains that window is measured in hours, sets a default of 24 and maximum of 720, and clarifies that omitting chain returns all nine chains. The chain enum values are already present in the schema, so the description does not need to repeat them.

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

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

The description states the tool returns open interest per chain and enumerates the specific computed values (latest, start-of-window, percent change, high/low, sampled series), which makes the purpose clear. It reads as a noun phrase rather than an explicit verb like 'get' or 'list', but it is unambiguous and distinct from sibling tools such as prices or market_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 guidance on when to choose this tool instead of a sibling or when it should not be used. The only usage-related instruction is parameter-level ('Omit chain for all nine', window limits), which does not help an agent decide between open_interest and alternatives.

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

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

With no annotations provided, the description carries the burden and does disclose important behavioral context: it requires a ChainHelix bearer token or per-call payment via specified channels, and it describes the latest-hour versus 24-hours-earlier comparison. It does not mention rate limits or explicitly state read-only behavior, but for a clearly query-like tool the access and data-comparison 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?

The first sentence spends roughly 40 words on payment mechanics before stating the actual purpose of the tool, which is not front-loaded for easy agent scanning. The second sentence is a dense run-on cramming many metrics and the time comparison together. The information is useful, but the structure and conciseness are 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?

Output schema exists, so the description does not need to explain return values. It covers the source, assets, horizons, metrics, and access/payment requirements, but it leaves significant terms undefined—bandVersion and the real-world meaning of horizon buckets—and gives no default behavior guidance for the optional parameters. It is workable but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does map horizon to front/short/mid/long and currency to Bitcoin/Ether, and it mentions bandVersion, but it does not define what the horizon buckets mean in expiry terms or what happens if parameters are omitted. This is a partial but shallow compensation for the lack of parameter descriptions.

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 identifies the resource: Bitcoin and Ether options volatility surfaces from Deribit, organized by horizon and populated with specific skew/volatility metrics. It is specific enough for an agent to distinguish it from siblings like iv_summary, though it lacks an explicit leading verb and never names alternatives.

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

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

The description only provides access and payment prerequisites; it gives no guidance about when to use this tool versus iv_summary, open_interest, or other option-related siblings. No exclusions, preferred contexts, or alternative routing are mentioned, so this dimension is effectively absent.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the authentication model (API key bearer token), the alternative 1-cent payment mechanism across specific networks and tokens, and the default behavior of returning all nine chains when no chain is provided. This is meaningful behavioral context beyond what the schema shows, though it does not mention failure modes 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?

The description is compact and every detail relates to using the tool, but it front-loads the dense payment/auth sentence before stating the core purpose. Placing 'Live price for every chain in one call' first would make it more immediately scannable. Still, it avoids redundancy and is not overly long.

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-parameter tool with an output schema, the description covers the essential call requirements: authentication options, cost, scope behavior, and the omission rule. It does not explain the output structure, but the output schema handles that. Minor gaps like explicit single-chain behavior are inferable and not critical.

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 for parameter meaning. It adds the key semantic that omitting the chain parameter returns all nine chains, which the enum alone does not convey. However, it does not explicitly state the behavior when a chain is provided, leaving the single-chain case to inference from the enum values.

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

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

The description states this tool provides 'Live price for every chain in one call' and refers to it as 'the one cent market check.' It clearly identifies the resource and the price-related purpose, though it lacks an explicit verb like 'get' or 'return.' The sibling list confirms it stands apart from broader market-state tools, but the description does not explicitly differentiate it from 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 concrete usage instruction: 'Omit chain for all nine' and implies passing a specific chain for a single-chain price. It also explains the payment and authentication requirements. However, it does not indicate when this tool should be used over alternatives like candles, market_state, or chain_brief, so the when-to-use guidance is only partial.

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 provided, the description itself must disclose behavior, but it only says what the spec is, not what the tool does (e.g., returns, validates, or generates it). It does not mention read-only status, return format, or any side effects, leaving the agent without critical behavioral information.

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, tightly worded sentence with no redundancy. It effectively front-loads the core subject and includes the key context of ChainHelix attestation stream, making it concise and free of 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?

Despite the tool's simplicity (0 params, output schema exists), the description still fails to explicitly state that invoking it returns the specification. It does not clarify the operation, safety, or any limitations. An explicit verb like 'Returns' would make it complete for this minimal 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 input schema has zero parameters, so schema coverage is trivially 100%. The baseline for 0 parameters is 4, and the description does not need to explain inputs. It adds no parameter-related meaning, but none is necessary.

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

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

The description identifies a resource ('machine verification spec') and specifies a domain ('ChainHelix attestation stream'), but it lacks an explicit action verb. The tool name suggests it might return or define the spec, but the purpose remains ambiguous because it does not state what the tool does with the spec.

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

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

There is no guidance on when to use this tool or how it relates to sibling tools such as verify_reveal or iv_summary. The description provides no context for selecting it over alternatives, offering only a static noun phrase.

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 takes on the full transparency burden. It discloses the required API key or per-call payment, payment rails and networks, the joined live-status behavior, the verified/unverified distinction, probe age, the free check link, and limit defaults. This is significantly more behavioral context than the structured schema provides.

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 information-dense but runs as one long, comma-heavy run-on sentence. The payment details are placed before the core purpose, which makes it harder to scan. Every piece is relevant, but the structure could be much clearer.

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 output schema exists and no annotations are provided, the description is remarkably complete. It covers auth, cost, query semantics, live-status behavior, and pagination limits. Nothing essential for invoking this tool correctly appears to be missing.

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

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

Schema coverage is 0%, so the description must explain the parameters. It does: query searches by name and description, and limit has a default of 20 and a maximum of 50. This fully compensates for the bare input 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 clearly states the action ('Search'), the exact resource (the ERC-8004 registry on BNB Smart Chain), and the search fields (name and description). It also distinguishes what the result includes via the ChainHelix live status join, which separates it from sibling tools like verified_agents or agent_report.

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

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

The description provides clear context for when to use the tool: when you need to search the ERC-8004 registry by name/description and see live status. It also makes the authentication and payment prerequisites explicit. However, it does not explicitly name alternatives or state when not to use it, such as pointing to verified_agents for a curated list.

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 of behavioral disclosure. It does add meaningful context about authentication/payment requirements and the exact session definition (Asia, London, New York as UTC thirds), which goes beyond the schema. However, it does not explain what happens without payment, whether the call is read-only, or inherent output assumptions.

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

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

The description is compact and each sentence carries useful information, but the long payment sentence is front-loaded before the core purpose statement. This makes the description less scannable than it should be for an agent comparing many tools.

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 description covers billing, the 7-day lookback, an the session definitions, and the schema covers chain choices. But it leaves the chain parameter semantically unexplain and provides no decision guidance against sibling tools, so it is only minimally complete for a simple one-parameter tool with an output schema.

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%, and the description does not mention the chain parameter at all. The enum in the schema provides allowed values, but the description adds no meaning about how to choose a chain or what the parameter represents.

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 (share of price movement per trading session over 7 days) and defines the session windows, which makes the tool's purpose reasonably clear. It lacks an explicit verb like 'get' or 'return', but the meaning is inferable and distinct from sibling tools such as candles or prices.

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

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

There is no guidance on when to use session_stats instead of related tools like candles, prices, or market_state. The billing sentence is a prerequisite, not a selection criterion, so an agent gets no help choosing among siblings.

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

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

With no annotations, the description carries the full transparency burden and does disclose key operational traits: required bearer-token authentication, an optional pay-per-call mechanism, and the aggregated data content. It does not explicitly state that the operation is read-only, but the term 'report' makes that reasonably clear.

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 mostly earns its length: payment/auth details, the report contents, and the parameter default are all operationally relevant. The phrase 'in one call' and 'in a single report' is slightly redundant, and the payment preamble is front-loaded before the purpose statement, but overall it is compact.

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 description is complete for a one-parameter tool with an output schema: it explains authentication, payment options, what data the report contains, and how to request all chains. Since an output schema exists, the absence of a detailed return-value description is not a gap.

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

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

The schema only lists an enum of chain names with no descriptions, so the description's statement to omit chain for all nine adds essential meaning beyond the structured schema. For the single optional parameter, this fully clarifies the default behavior and the effect of providing a chain.

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 defines the tool as a one-call aggregated market report, listing specific components such as RSI/MACD momentum, price walls, large transfers, bot activity, and the Bitcoin queue. This distinguishes it from more focused sibling tools like market_state or wall_map, even though it lacks an explicit action verb.

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 use case: obtain the full market picture across chains in a single call, and it explains the chain-omission behavior for all nine chains. It does not explicitly name alternatives or exclusion cases, but the comprehensive scope strongly implies when this tool should be preferred.

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 provided, the description carries the burden of behavioral disclosure. It reasonably covers this by explaining authentication requirements, payment model, data metrics returned, window constraints, and supported chains. It does not explicitly state whether the tool is read-only or describe pagination/rate limits, but the core behavioral surface is disclosed.

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 information-dense and contains no filler, but it front-loads payment details before explaining what the tool actually returns. That ordering is suboptimal for an agent trying to decide whether to call the tool, though the content is otherwise concise and organized.

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 is present, return values do not need to be explained. The description covers authentication, payment, parameters, defaults, constraints, and chain coverage, which is largely complete for calling the tool. The main gap is the lack of context about when this tool is appropriate relative to similar flow-related tools.

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

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

Schema description coverage is 0%, so the description must compensate. It does so effectively: 'window' is explained with units, default, and maximum, and 'chain' is explained with the full list of enum values and the behavior when omitted. This adds meaning the schema itself does not 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 clearly states the resource and what it reports: stablecoin mints and burns per chain and coin, including counts, total dollars, large events, and net mint-minus-burn values. It does not use an explicit verb like 'get' or 'list', and it does not distinguish itself from sibling tools like bridge_flows or whale_flows, but the resource scope is specific enough to be understood.

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 practical usage details such as default and max window, and notes that omitting chain returns all covered chains. However, it provides no guidance on when to prefer this tool over alternatives like bridge_flows or whale_flows, and it does not state any exclusion conditions or use-case context.

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. It discloses authentication requirements (API key or paid crypto payment), the verification methodology (probing on-chain records), and output characteristics (endpoint, skills, probe age, latency, evidence record on BNB Greenfield). It also clarifies optional filtering by status. This is substantial behavioral context, though it does not describe rate limits, failure modes, or pagination.

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, dense block of text with payment information, definition, and output details all merged. It front-loads the authentication/payment requirement, which is important, but the sentence is long and packs many features together. The structure could be improved by separating payment, purpose, and output, but there is no redundant 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?

Given the tool's simplicity (one optional parameter) and clear output schema, the description covers the essential context: what the tool lists, how it verifies agents, what fields are returned, and how to authenticate. It lacks explicit details on default behavior (e.g., what happens if status is omitted) and possible error conditions, but these are minor for a read-only listing 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. The description explains the optional 'status' filter only indirectly by mentioning 'Optional status hireable or alive', which maps directly to the enum values. It adds meaning by indicating that status is a filter for the listed agents, but does not explain the difference between 'hireable' and 'alive' beyond their names or which is the default. Baseline 3 is appropriate because the parameter is simple and the enum is self-explanatory.

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

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

The description identifies a specific resource (ChainHelix Verified) and a clear function: listing live, hireable agents on BNB Smart Chain with evidence records. It distinguishes itself from sibling search_agents by focusing on verified, running agents rather than general search. However, it does not explicitly name sibling alternatives or contrast its behavior, so it lacks a sharp differentiator.

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 usage context: call this when you need a verified list of running agents with endpoints and evidence. It does not state when not to use it or explicitly name alternatives like search_agents, agent_report, or hire_quote. The payment detail is a prerequisite but not a usage-selection guideline. A clear when-to-use statement is missing.

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 burden. It discloses that the tool returns each check result plus data for independent on-chain verification, implying a read-only verification operation. It does not mention permissions or error cases but gives useful behavioral context beyond the bare action.

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

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

The description is two concise sentences, front-loaded with the action and immediately followed by the return value. No unnecessary words or repetitions, 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?

The description covers purpose and output, and the output schema exists so return details are not required. It conveys the verification workflow well, though it doesn't mention prerequisites (e.g., reveal must exist) or error behavior, which are minor for a read-only verification 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 parameter seq is implied as 'sequence number' in the description, but there is no additional detail beyond the schema (type number, required). Since schema coverage is 0%, the description partially compensates but remains minimal, just naming the identifier 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?

The description clearly states the tool recomputes the hash and Merkle fold for a reveal by sequence number. Uses specific verb 'recompute' with a clear resource and scope, distinguishing it from sibling tools like list_reveals or mev_intel.

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 context is clear: use this tool to verify a specific reveal by sequence number. No explicit alternatives or exclusions, but the focused scope is evident. Sibling tools are mostly stats or flow related, so separation is implicit.

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

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

With no annotations, the description carries the full burden of disclosure. It provides substantial behavioral context: requires a ChainHelix API key as bearer token or per-call payment, operates only on public onchain data, and enumerates the returned risk categories. It does not disclose rate limits, error behavior, or data freshness, but it is far more transparent than a minimal 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 information-dense and waste-free, but the first and longest sentence is devoted to payment and authentication details rather than tool purpose, so the description is not front-loaded effectively. The second sentence bundles a long list of outputs efficiently, but the overall structure could be improved by beginning with the tool's core function.

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

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

For a simple two-parameter read-only tool with an output schema, the description is largely complete: it describes auth prerequisites, payment options, the public-onchain scope, and the nature of the returned risk data. It does not clarify the exact semantics of the optional chain parameter or default behavior, but the output schema covers return values and the invocation path is fairly clear.

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

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

The schema provides 0% description coverage and the description does not explicitly explain the parameters. 'one wallet address' maps to the address field and 'across chains' loosely maps to the optional chain field, but the description does not state that chain is optional, what the default behavior is, or expected address formats for the different chain enums. With low schema coverage, the description should compensate and does not.

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 that the tool provides a risk profile for one wallet address across chains and enumerates the specific risk attributes returned, such as risk score, mixer funding, dormancy, transaction counts and values, protocols, bridge count, flagged status, and recent events. It is clearly distinguishable from aggregate or market-level sibling tools, though it does not explicitly name a sibling alternative.

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 its usage context: it is for assessing onchain risk of a single wallet address, with 'Public onchain behaviour only' serving as a boundary. However, it does not provide explicit guidance on when to choose this tool over siblings or mention any alternatives, and no exclusions beyond the public-onchain scope 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?

With no annotations, the description carries the behavioral transparency burden and does substantial work: it discloses authentication/payment requirements, the per-chain selection behavior, and the 'omit for all nine' behavior. It also adds credibility by noting this is the wall map the ChainHelix engine trades with. It does not mention rate limits, but that is a minor gap for a single-parameter read-style 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 information-dense but not optimally structured: the lengthy payment details come before the tool's actual purpose. The content is relevant and there is no fluff, but the front-loading of billing options makes it harder to scan quickly for what the tool does.

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

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

Given the single optional enum parameter and the presence of an output schema, the description is largely complete. It covers auth/payment, the data produced, market-structure granularity, and the all-chains behavior. It could be slightly more explicit about read-only semantics, but nothing critical is missing for invoking the tool correctly.

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

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

The input schema has only one optional parameter, 'chain,' with an explicit enum of nine chains. The description adds meaning beyond the schema by explaining that omitting 'chain' returns data for all nine, and that the walls are reported per chain. Even though schema description coverage is 0%, the enum plus the description make the parameter semantics clear.

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 identifies the resource: support and resistance price walls per chain with touch counts and hourly-to-weekly market structure. It lacks an explicit verb like 'returns' or 'gets,' but the noun phrase is specific enough for an agent to understand what the tool provides and to distinguish it from generic price or market-state tools.

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

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

The description gives practical usage context: it requires a ChainHelix API key or per-call payment, and it explains that omitting the chain parameter returns all nine chains. It does not explicitly state when to use this tool over alternatives, but the wall-map domain and parameter behavior imply the intended use case.

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

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

With no annotations, the description carries the full disclosure burden and does so well: it states required auth (API key bearer token or prepaid per-call payment), cost, payment networks, the 7-day delivery window, extension-by-recalling, free registration with an active API key, and signed deliveries for verification.

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 information-dense and relevant, but not front-loaded: the first sentence is a wall of payment/auth details and the actual purpose appears only in the second sentence. It earns its place but would be clearer if the webhook-registration purpose 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?

For a paid, authenticated webhook registration with an output schema, the description covers the essential operational context: costs, duration, renewal, event semantics, and delivery verification. It does not mention related lifecycle tools like webhook_status or webhook_unregister, but that is not critical to invoking this tool correctly.

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

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

Schema coverage is 0%, but the description compensates by defining the url as an https endpoint and explaining both events enum values in detail. It does not clarify whether the events parameter is optional or what happens when omitted, though the schema already marks it optional.

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 identifies the operation as registering a destination to receive pushed ChainHelix events, explicitly naming the two event types (signal_sealed and trade_closed) and contrasting with polling. This distinguishes it from polling-style siblings like latest_signals.

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

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

It positions the tool as the push-based alternative to polling ('Get ChainHelix events PUSHED to your https URL instead of polling') and explains renewal behavior for ongoing delivery. It does not name specific sibling tools or give explicit when-not-to-use exclusions, so it falls 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?

Discloses that it only returns the user's own webhooks and never reveals the signing secret, which is important behavioral context. With no annotations, this description provides useful safety and security details, though it doesn't explicitly state read-only behavior beyond 'show'.

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 focused sentences with no redundancy. The first sentence states the main functionality, the second adds safety and scope constraints.

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 output schema and simple parameter set, the description provides enough context for usage. It covers the essential constraints (tenant scope, optional id, secret non-disclosure), making it adequate for an agent to select and invoke the 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 description explains 'tenant' as the paying wallet or key id and 'id' as an optional narrowing filter, partially compensating for zero schema descriptions. It clarifies that omitting id returns all webhooks, but lacks details on id format or pagination.

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 indicates this tool retrieves webhooks registered to the user's tenant, optionally filtered by id. It distinguishes itself from webhook_register/webhook_unregister by focusing on viewing rather than modifying. A slight deduction for lacking an explicit verb like 'list'.

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

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

The description states the tenant requirement and that it only shows one's own webhooks, implying a security context. It does not explicitly recommend using this tool over siblings for status checks, but the sibling names make the distinction evident.

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