intel

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

Since no annotations are provided, the description carries the full burden for revealing behavioral details. It explicitly discloses the required bearer token or 5-cent payment, payment channels and networks, that a live probe is performed right now, and that results include evidence records on BNB Greenfield. This is valuable transparency beyond the input 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 single dense run-on sentence mixing payment routes, output contents, and on-chain details. It is not front-loaded with the tool's purpose; instead it starts with API-key and payment requirements. The information may be relevant, but its lack of structure makes it harder for an agent to scan and act on.

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

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

With one required parameter and no annotations, the description should clearly explain what id is and how to supply it. It does not. The output schema exists but does not compensate for the missing input-semantics guidance. Cost and output aspects are covered, but the tool cannot be invoked confidently until the id meaning is clarified.

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 documents 'id' as a required number, and the description provides zero coverage of what that id refers to. The phrase 'One agent' hints that a candidate is identified by id, but the description never explicitly states that the id is the agent id, what kind of number is expected, or where the value comes from.

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

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

The description names the resource ('one agent') and lists many report contents, but it never uses an explicit verb phrase like 'returns' or 'fetches'. The tool name and the 'id' parameter make the purpose inferable, yet the description itself remains a dense noun-like fragment about payment and output rather than a clear statement of 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 provides no guidance on when to use agent_report instead of sibling tools such as search_agents, deep_report, verified_agents, or situation_report. It gives no when-to-use or when-not-to-use context, leaving the choice entirely to the agent.

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

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

With no annotations, the description carries the full burden and does so richly. It discloses authentication (bearer token), cost/payment methods, identity mapping, the underlying chain (opBNB), reveal behavior (claim text and salt publish automatically), and a critical semantic limitation (attests when, not whether). This goes well beyond what annotations could provide.

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 earns its place, covering auth, cost, usage, and behavior. It is not front-loaded with the core purpose (payment comes first), but remains compact and structured enough for a detailed 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's complexity (payment options, identity, reveal delay, chain), the description is complete: it covers usage, constraints, costs, the timing semantics, and points to attest_spec for verification. An output schema exists, so return values are not needed in the description.

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

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

Schema coverage is 0%, so the description compensates by fully explaining both parameters: payload is a 'claim string,' and revealDelayHours is optional, ranged 1-720 with default 72. This adds meaning beyond the bare schema property names.

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: 'Seal any claim on chain now, reveal it later' and 'attests WHEN you said it, never whether it is true.' It uses a specific verb ('seal') with a resource ('claim') and differentiates from sibling tools like attest_spec and verify_reveal by explicitly pointing to attest_spec for verification.

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 usage context: 'Send your claim as the payload string with an optional revealDelayHours' and explains payment/authentication requirements. It implies when to use this tool (to make an attestation) and directs to attest_spec for verification, but does not explicitly name alternatives or when-not-to-use scenarios.

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, the description carries the transparency burden. It discloses a key behavioral trait: the response differs depending on reveal time ('Before reveal time only the receipt shows; after it the claim text and salt are included'). This adds valuable 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 two sentences, front-loaded with the main purpose and then the key behavioral nuance. Every word earns its place, with no redundancy or 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 an output schema is present, the description adequately explains the conditional response content (receipt vs claim text and salt). It covers the essential behavior and parameter relationship, though the optionality of seq/hash is slightly underspecified.

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 adds the usage pattern 'tenant plus seq or hash', clarifying that tenant is required and either seq or hash is needed. However, it does not clarify whether both can be provided or what happens if neither is given, 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 clearly specifies the action ('Check') and the resource ('one sealed claim'), with the selection criteria ('by tenant plus seq or hash'). This distinguishes it from list-style siblings like 'list_attestations', 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 implies usage for checking a single claim via tenant and seq/hash, but provides no explicit guidance on when to use this tool versus alternatives like 'verify_reveal' or 'list_attestations'. No exclusions or alternative recommendations are given.

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

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

With no annotations provided, the description carries the behavioral burden itself. It clearly discloses authentication requirements (API key as bearer token), a fallback payment-based access path, the valid chains, default and max window, and the contents of the result. It does not explicitly state rate limits or elaborate on payment mechanics, but it gives enough for an agent to understand cost and scope.

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 packs necessary details into a compact paragraph with no filler. The payment/prerequisite clause is dense and comes first, which is arguably important context but elongates the opening sentence. Everything else is efficiently stated.

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 two optional parameters, an output schema, and no required inputs, the description covers the important execution details: authentication, cost alternative, accepted chains, window semantics, and output content. An agent has enough information to call the tool correctly without inspecting 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%, yet the description fully compensates: it explains the meaning of window, imposes units/default/max boundary, documents that l2 is optional, names every valid enum value, and clarifies the 'all chains' behavior when l2 is omitted. This is valuable semantic context that the schema alone cannot 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 identifies the tool's domain: Layer 2 bridge activity across arbitrum, base, and optimism, with specific output dimensions like deposits, withdrawals, message counts, and value moved in ETH. Although it lacks an explicit verb such as 'get' or 'return', the meaning is clear. It is reasonably differentiated from siblings like stablecoin_flows or whale_flows by focusing on bridge-specific activity.

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 parameter guidance: window is in hours, default is 24, max is 720, and omitting l2 returns all three chains. However, it does not explicitly say when to prefer this tool over alternatives such as stablecoin_flows or whale_flows, so the guidance is context-focused rather than comparison-focused.

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 behavioral transparency burden. It discloses the authentication/payment requirement, the sampled-series output, and the window defaults and limits. It does not mention rate limits or sampling granularity, but it provides more behavioral context than most 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 tool description compresses a lot of required information into a single run-on passage. The payment and API-key details are placed before the explanation of what the tool actually does, which limits front-loading and readability. It is reasonably compact but structurally could better prioritize purpose first.

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

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

For a one-parameter tool with an output schema present, the description is largely complete enough for correct invocation. It covers pricing/authorization conditions, the exact data returned, and the input window semantics. Minor gaps remain around sampling interval and edge-case behavior, but these are not severe 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?

The input schema only defines a numeric field with no description, so the parameter semantics are fully carried by the tool description. The description adds all relevant meaning: units are hours, the default is 24, and the maximum is 168. This is strong compensation for the 0% schema coverage.

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's function: it returns Bitcoin mempool data over a window, including fastest fee, transaction count, and size as a sampled series with high, low, and latest values. It is specific to the mempool and distinct enough from typical sibling tools, though it does not explicitly name or differentiate itself from a 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 implies its usage context: an agent would use it when Bitcoin mempool history or pressure data over a time window is needed. It also provides practical prerequisites such as the API key or per-call payment requirement and window constraints, but it offers no explicit guidance about when to prefer this tool over similar 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?

Annotations are absent, so the description has to carry the full behavioral burden. It does disclose payment/auth requirements and the max/default for `window`, which are genuinely important. But it doesn't explicitly say the operation is read-only, whether usage counts against rate limits, or how the data is aggregated, leaving a partially transparent picture.

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?

There is no wasted prose—every sentence carries information—but the lengthy payment/auth preface is placed before the main purpose, nearly hiding the core use case. Restructuring to state the market-data report first and then the auth/cost note would give better clarity and improve navigability.

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 simple input schema and an existing output schema, the description largely supplies enough to call the tool, especially by doing parameter semantics and auth costs. However, the absence of any guidance on when to select this over a sibling market or MEV tools creates a material completeness gap for an agent's tool-selection 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?

The schema provides only the property name `window` with no description, while the description says it is in hours, defaults to 24, and maxes at 720. That transforms a bare numeric field into a usable parameter, and coverage far beyond what the raw schema alone offers.

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 resource clearly: Ethereum block builder market over a window, including blocks delivered, value per relay, and top builders. It does not rely on a verb but the noun-phrase is descriptive enough to infer an analytic report, and it stands apart from the broader sibling list only by the mention of 'builder relays'.

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 covers authentication and payment requirements, plus valid values for `window`, but never says when to choose this tool over related siblings like `mev_intel` or `mev_bots`. There is no condition such as 'if you need builder-level relay breakdowns' or 'do not use this for mempool data', leaving selection to happen without 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?

There are no annotations, so the description carries the behavioral transparency burden. It adequately discloses the payment flow, supported chains, pricing/rate limits, token types, and claim process. However, the schema includes an 'alerts' plan that is not explained in the description, leaving some behavior ambiguous.

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 but efficient block. Every sentence adds important operational detail: plans, prices, rate limits, chain choices, expected return values, the subsequent claim step, expiration, and email behavior. It could be more structured, but it is 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?

The description gives enough context to invoke the tool correctly and continue the workflow with claim_key. It includes the key edge condition and delivery behavior. Missing details around the 'alerts' plan are the main reason this is not a full 5.

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 explain all parameters. It does explain plan and chain values and notes that email is optional. The major gap is the 'alerts' plan: the description only covers 'standard' and 'pro', so the semantics of the third allowed parameter value are not 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 uses a specific verb and resource: 'Buy a ChainHelix API key'. It clearly distinguishes the tool from siblings like claim_key and key_order_status by framing this as the purchase step, and it explains what makes the tool special: no browser or account is required.

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 explicitly explains when to use the tool and what happens next: after receiving a payment address and amount, the user should send the exact amount and then call claim_key. It also identifies critical constraints like the 24-hour order expiration and optional email delivery.

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 limit of 'up to 500 candles', and ordering 'newest last'. It does not mention error handling or rate limits, but the key restrictions are exposed clearly.

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

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

The description is one dense sentence that buries the main resource description under a long payment/auth clause. It is not overly wordy, but the front-loaded payment text distracts from the primary purpose, while important schema hints are packed into the trailing clause.

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 three-parameter tool with no annotations, the description covers the essential dimensions: diagnosis of required credentials/payment, the exact return content, range restrictions, and output limits. The existence of an output schema further reduces the need to describe return fields, though some details like default values and fail behavior remain unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning: 'one chain', 'fourteen timeframes', and 'up to 500 candles', which maps helpful semantics to chain, timeframe, and limit. Yet no defaults are described, and 'newest last' is an output property rather than a parameter explanation.

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

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

The description specifies a concrete resource: price history with open, high, low, close, volume, and trade count per candle. It does not explicitly say 'retrieve'/'get', instead using the noun phrase 'Price history', but the meaning is clear and distinct from the sibling 'prices' tool by emphasizing candle and OHLCV data.

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 about what the tool returns, so an agent can infer to use it when historical candle data is needed. However, it never states explicit when-to-use guidance, alternative comparisons, or exclusions relative to siblings like 'prices' or 'market_state'.

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

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

Since no annotations are provided, the description carries the full transparency burden. It discloses the required bearer-token API key, pay-per-call alternatives, the inclusion of bitcoin-specific mempool data, and the behavior that failed sections are listed under 'unavailable'.

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 information-dense: credentials and payment, response contents, then failure behavior. However, the detailed auth and payment attention leads the description, delaying the clearer central purpose announcement.

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 enum parameter and an output schema, the description is well covered: it explains auth, cost, the aggregate chain-brief concept, and failure reporting. The main gap is the absence of explicit guidance for when to prefer this over a sibling specialized tool.

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

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

Schema description coverage is 0%, but the description adds a key parameter nuance: for bitcoin, the response includes the mempool, while other chains rely on the general listed sections. The 'one chain' phrasing also clarifies that exactly one chain is processed per call.

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

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

The description states the tool's scope: 'One chain, the whole read in one answer' and lists the specific market analysis sections included. This differentiates it from the many specialized sibling tools, even though it doesn't explicitly name 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?

'One chain, the whole read in one answer' implies the tool should be used when an agent wants a single comprehensive chain report rather than a specific metric. However, there are no explicit conditions, exclusions, or comparisons to the specialized 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 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?

With no annotations provided, the description carries the full burden. It discloses the auth/payment requirement (bearer token or per-call fee) and indicates the data scope (current vs 30-day historical queue depth, current fastest fee). However, it does not mention rate limits, return format, or whether it is a read-only operation, though the output schema covers return structure.

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 short but poorly structured: it leads with a long payment/authentication clause before stating the actual purpose. The purpose is relegated to the end. It is concise but not front-loaded, making it less scannable than 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 simple zero-parameter tool with an output schema, the description is mostly complete. It tells the user about required authentication/payment and what data is returned (Bitcoin queue depth comparison and fastest fee). The output schema compensates for any missing return-format 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?

The tool has zero parameters, so the schema provides no parameter details. Per the baseline for zero-parameter tools, the description need not add parameter meaning. The description focuses on what the tool returns, which 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 clearly identifies the tool's purpose: reporting Bitcoin queue depth now versus the past 30 days and the current fastest fee. Although it lacks an explicit verb like 'get' or 'returns', the resource and scope are specific enough to understand what the tool does and to distinguish it 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?

The description provides no guidance on when to use this tool versus alternatives. It only mentions authentication and payment requirements, which are operational prerequisites, not usage context. There is no statement about suitable scenarios 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?

Without annotations, the description carries the full burden. It discloses significant behavioral aspects: authentication via bearer token, cost per call, payment methods, window default (7 days), maximum (30 days), and the computation basis (hourly returns across nine chains). This goes beyond a basic purpose statement, though it omits details about output format or potential 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 a single run-on sentence that mixes payment/billing information with the functional description. It front-loads payment details rather than the tool's purpose, making it structurally messy. The information could be split into separate sentences for clarity 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?

For a simple tool with one parameter and an output schema, the description covers the essential context: what it does, the data scope, authentication/cost, and parameter constraints. It does not explain the nine chains or use cases, but that might be considered domain knowledge. Overall, it is sufficiently complete for an agent to decide whether to invoke it.

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

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

The input schema only defines 'window' as a number with no description (0% schema coverage). The description adds meaningful semantics: 'window in days default 7 max 30', clarifying units, default, and valid range. For a single-parameter tool, this compensates well for the schema's lack of context.

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 clear: 'Pairwise correlation of hourly returns across the nine chains.' It identifies the specific resource (nine chains) and the analysis performed. However, the description starts with payment/auth details, which obscure the main purpose, and it does not explicitly differentiate from sibling tools like 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?

The description provides authentication/payment requirements but no guidance on when to use this tool versus alternatives. There is no mention of scenarios where correlation analysis is appropriate or how it compares to related tools such as whale_flows or latest_signals.

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?

With no annotations provided, the description carries the full burden. It discloses important operational requirements: authentication via ChainHelix API key or payment through Binance b402/x402, and notes that the output includes on-chain verification links. This adds behavioral context beyond the bare 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 long run-on sentence that buries the core purpose behind payment details and a lengthy list of report components. It is not front-loaded and lacks clear structure or paragraphing, making it harder to parse quickly.

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 output schema likely covers return values, so not explaining them is acceptable. However, the description fails to clarify the chain parameter semantics or how this report relates to sibling tools. Payment and content details are comprehensive, but the input ambiguity and lack of usage context prevent a higher score.

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 one parameter (chain) with an enum of nine chains, but the description does not explain how the parameter relates to the 'nine chain research brief.' It is ambiguous whether the report covers all chains at once or whether the user must select a specific chain. This lack of clarity leaves the agent uncertain about parameter behavior, especially since the parameter is 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 states the tool produces 'the complete nine chain research brief in one call' and enumerates its major components (market report, signal stream, correlations, options volatility, etc.). It distinguishes from siblings by calling itself 'the most complete single answer this server produces,' which sets it apart as a comprehensive aggregation tool.

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

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

The description implies this is the go-to for a comprehensive overview ('most complete single answer'), but it does not explicitly state when to use this tool versus alternatives like situation_report, market_state, or latest_signals. No when-not-to-use guidance or alternative tool names are mentioned.

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 provided, the description carries the behavioral disclosure burden. It does disclose API key requirements, a per-call cost model, and the effect of omitting chain. Still, it does not explicitly state that the operation is read-only, nor does it mention rate limits or side-effect risk, so some behavioral ambiguity remains.

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 text contains necessary info but front-loads a dense, payment-related sentence about authentication and costs before stating the actual purpose ('Network load per chain'). It could be structured more clearly, though no information is redundant.

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

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

For a single optional parameter with both an input enum and an output schema, the description covers access control, pricing, supported metric scope, and across the behavior. The main missing piece would be a direct statement that the tool is read-only, but the context and schema make that sufficiently 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?

Schema description coverage is 0%, but the description adds essential parameter behavior: omitting 'chain' fetches all nine chains. The single enum-based parameter is also self-descriptive in the schema, so the combination is sufficient for an agent to understand how to supply or omit it.

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

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

The description identifies the resource as per-chain network/gas load and enumerates specific metrics (latest transaction count, MEV count and rate, average gas, large transaction count). It clearly conveys what the tool provides, but it lacks an explicit retrieval verb like 'gets' or 'returns', and it does not differentiate from sibling tools such as congestion 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?

The description explains how to use the chain parameter with 'Omit chain for all nine' and implies the tool is for network-load data. However, it gives no explicit when-to-use-this-vs-another-tool guidance or exclusions, so the usage context is inferred rather than directed.

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

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

No annotations are present, so the description carries the full disclosure burden. It crediting a actually authenticates ChainHelix API key or pricing via token payments, outlines Snapshot governance data, and exposes ordering, default window, and max window. This is meaningful behavioral context beyond the schema, though it leaves some invocation details 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 dense and contains no pure filler, but the payment details overwhelm the main purpose sentence and the entire text is a single heavily packed paragraph. The information is organized by topic, but more structured formatting would make parameter constraints and defaults more discoverable.

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 output ordering, window range, Snapshot ID format, authentication, and cost, and an output schema exists for return values. However, it does not clarify whether `space` is required, what happens when `space` is omitted, or what `limit` controls; those gaps prevent the context from being 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 explain the parameters. It adequately documents `space` with an example and `window` with default and max values, but it never explains `limit`, its default behavior, or whether it caps the number of proposals and votes. One of three parameters remains semantically underspecified.

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 returning DAO governance data from Snapshot: proposals, votes, and scores per space, ordered by activity. It is specific enough to distinguish the tool from the many other data tools in the sibling list, though it relies on the tool name and phrasing rather than an explicit verb like 'fetch' or '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 says what the tool queries and gives parameter details, but it never states when to use this tool or when not to use an alternative. No exclusions, use cases, or comparisons to sibling tools are provided, so an agent has to infer the appropriate invocation 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 and does disclose authentication, payment cost, payment routes, accepted tokens, and output behavior: a signed offer envelope and funding steps. It also restricts the operation to live-map-listed hireable agents. The quote-only workflow avoids claiming side effects beyond generating a quote.

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 moderately long but each sentence carries needed information: prerequisite auth/payment, the actual request workflow, the expected output, and the hireable-agent restriction. The only redundancy is the repeated ChainHelix reference, and the payment rail enumeration is dense but relevant.

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 workflow, payment prerequisites, expected output, and the hireable-agent limitation, while an output schema exists to carry return-value details. It is incomplete around the required 'id' field and the acceptable structure of 'terms', making the full request construction ambiguous.

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 partially does by mapping 'task_description' and 'terms' to the instruction to send a task description and terms, but it never explains the required 'id' parameter or the shape/semantics of the nested 'terms' object. An agent must guess what 'id' refers to before invoking the tool.

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

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

The description states a concrete action: ask a hireable agent on BNB Smart Chain for a live signed ERC-8183 quote, and explains what the caller sends and receives. It does not explicitly name a sibling tool to distinguish itself from, but the quote workflow is unmistakably different from the search, buy, claim, and report 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?

It gives a clear context and gate: the tool is for getting a quote from an agent listed as hireable on the live map, and only with a ChainHelix API key or one of the listed payment paths. It does not explicitly list alternatives or when-not-to-use cases, so it stops just short of a full 5.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It explicitly states authentication requirements ('ChainHelix API key as bearer token') and payment alternatives (2 cents per call via Binance or x402), which are critical for an agent to invoke the tool successfully. However, it does not mention read-only status, rate limits, or return shape, but these are less critical given 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 a run-on first sentence about payment/auth details, burying the actual purpose in the second sentence. It is not front-loaded; the main verb (implied volatility) appears only after a lengthy prerequisite clause. The content is useful but poorly structured and could be split into two focused sentences.

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

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

Given zero parameters, no annotations, and an existing output schema, the description covers the essential function and access requirements. However, it leaves ambiguities such as what 'near term' means (e.g., specific expiry durations) and how the temporal comparison is presented. The payment details are overemphasized relative to the functional description, but overall the tool is simple enough that this is minimally viable.

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 is empty (0 parameters), so schema coverage is trivially 100%. The baseline for 0 parameters is 4. The description adds context about the data content (Bitcoin and Ethereum, near term, now vs one week ago), which helps the agent understand what the tool will return, even though there are no parameter details to clarify.

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 clearly stated: 'Near term option implied volatility for Bitcoin and Ethereum, now vs one week ago.' This identifies a specific resource (implied volatility for BTC/ETH) and a temporal comparison, distinguishing it from siblings like 'prices' or 'congestion.' It lacks an explicit verb like 'provides' but the intent is 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 implies usage (when you need implied volatility data) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The heavy focus on payment/authentication requirements does not help with selection criteria compared to other market data tools.

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

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

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 the full burden and does excellently. It discloses authentication via bearer token, a per-call payment option with specific instructions, and the on-chain immutability of signals ('sealed on chain... cannot be edited afterward'). It also notes that anyone can verify with free proof tools.

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 efficient and every sentence adds value, but it front-loads the payment/auth requirement before stating the core purpose. A more purpose-first structure would improve scannability, though this is a minor issue.

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, an output schema, and two optional parameters, the description covers auth, cost, content, immutability, verification, and parameter limits. It doesn't explicitly state read-only behavior or rate limits, but these are reasonably implied by the context and the absence of side effects.

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, so the description compensates by noting both parameters are optional, that 'chain' filters the stream, and that 'limit' is capped at 50. While it doesn't explain each enum value, the schema already lists the enums, and the description adds crucial bounds and optionality.

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 returns 'The live ChainHelix signal stream, newest first,' and details the signal content (chain, direction, entry price, win probability, conviction score). This distinguishes it from siblings like 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?

The description gives clear context: it is a live stream, newest first, with optional chain and limit parameters. It also mentions 'free proof tools' as an alternative for verification, but does not explicitly say when to use this tool versus other signal-related siblings, leaving a small gap.

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 behavioral disclosure. It does surface that a ChainHelix API key/bearer token is required and that each call has a cost, which is useful context. However, it does not describe rate limits, error behavior, empty responses, or pagination, leaving the behavioral picture incomplete.

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 content is dense and mostly high-signal, but it opens with the auth/payment block rather than stating what the tool does. A front-loaded description starting with 'Get lending liquidations...' would make tool selection much easier.

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 two optional params and an output schema, the description covers the required essentials: purpose, filter semantics, defaults, auth, and cost. It does not cover edge-case behavior explicitly, but for a simple query-style tool this is reasonably 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 coverage is 0%, so the description must compensate, and it does meaningfully: it explains window as hours, gives the default and maximum values, and clarifies that omitting chain returns all chains. The chain enum still supplies the allowed values, but the description adds practical parameter semantics the bare schema lacks.

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 liquidations and enumerates the returned dimensions: event count, borrowers and liquidators, debt covered, and collateral liquidated. It lacks an explicit verb like 'fetch' or 'get' and does not explicitly distinguish itself from sibling tools, but the resource and metrics 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?

It gives concrete invocation guidance: window is measured in hours, defaults to 24, has a maximum of 720, and chain can be omitted to query all chains. It does not explicitly discuss when not to use this tool or mention alternatives, but the call behavior is clear.

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

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

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?

Since no annotations are provided, the description carries the full behavioral disclosure burden. It does meaningfully add context by requiring a ChainHelix API key or a 2-cent payment over Binance b402/x402, and it lists the exact indicator calculations an agent would want to understand before calling. However, it does not explicitly state side effects, read-only behavior, rate limits, or any error/precondition beyond payment, leaving part of that burden unmet.

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 not bloated, and most sentences add information, but is structural opening is questionable: the authentication/payment conditions come first instead of the tool's actual purpose and outputs. The tool description also crams many indicator details into ad-later, somewhat run-on, list-like 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?

For a one-optional-parameter market data tool, the description is practically sufficient: it communicates authentication, payment, parameter omission, and the shape of what is returned. The existence of an output schema arguably handles detailed return shape, so the description does not need to list every field. It lacks explicit when-to-use guidance, but that is already scored separately in Usage Guidelines.

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 just one optional 'chain' parameter with 0% description coverage, so the description must compensate. It does specify the useful omission behavior ('Omit chain for all nine') and frames chain as a per-chain selector. The chain list itself is not restated in the description, but the schema enum already provides the exact values, so the additional meaning is moderate rather than substantial.

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 market-state information provider, listing the exact data returned: regime, range age, volatility state, RSI/MACD indicators, EMA trend, and a summary momentum state. This is far more specific than a sentence that merely restates 'market state', though it lacks an explicit verb like 'fetches' or 'returns'.

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 over siblings such as situation_report, latest_signals, or congestion. The only form of usage guidance is 'Omit chain for all nine', which is a parameter behavior rather than a situational recommendation. Two details that some agents could view as usage prerequisites — the API-key/payment requirements — are present, but the description never states what scenarios call for this tool versus 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?

No annotations are supplied, so the description carries the full disclosure burden. It documents the authorization/payment model, the exact returned fields, ordering by detections, and defaults/maximum for key inputs. It does not explicitly clarify read-only behavior or side effects, but it is substantially more transparent than a minimal or code-driven description.

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 text is compact and information-dense: auth/payment, output fields, result ordering, and input defaults all fit in three short sentences. The main structural weakness is that the tool's purpose appears after the lengthy payment sentence, so it is not strictly 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 three-parameter tool with an output schema, the description covers core result fields, ordering, chain, defaults, limits, and access requirements. The main gaps are the absence of deeper active_hours semantics and any 'when-not-to-use' or alternative-tool 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 schema has no per-property descriptions, so the description adds real value by documenting active_hours default 168, limit default 50, and limit max 200. However, it does not explain what active_hours or limit formally represent beyond their names, and the chain parameter is left almost entirely to the enum.

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

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

The description identifies a specific resource — active MEV bot addresses on a chain — and enumerates the returned content: detections, strategy types, first/last seen, and a high-confidence flag. It lacks an explicit verb like 'list' or 'return' and does not differentiate it from sibling tools like mev_intel, so it doesn't earn full marks.

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 invocation context: an API bearer token or payment requirement, permissible chains, defaults, and limits. However, it does not explicitly state when to use this tool versus close siblings such as mev_intel, nor provide exclusions or alternative routing guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states the payment/auth requirement (API key or per-call fee) and window constraints (default 24, max 168). However, it does not mention whether the operation is read-only, what errors may occur, or any rate limits, leaving notable 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 two sentences and covers key operational details without excessive length. The first sentence lists payment options concisely, and the second defines the tool's purpose and window parameter. No wasted words, though the payment details could be streamlined.

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 explains the core functionality and window constraints, but does not elaborate on the 'type' dimension or provide usage context relative to siblings. An output schema exists, so return values need not be described. However, with no annotations, more context about authentication behavior or response handling would improve completeness.

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

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

The description adds meaningful detail for the 'window' parameter (hours, default 24, max 168), which the schema does not provide. The 'chain' parameter is fully enumerated in the schema, making its semantics self-explanatory. The mention of 'type' in the description adds context but does not map to a specific parameter. Overall, this compensates well for the 0% schema description coverage.

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 vs the trailing weekly pace.' This specifies the resource (MEV event rates) and is distinct from sibling tools like prices or congestion. However, it lacks an explicit verb like 'get' or 'list', which slightly reduces clarity.

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 does not provide guidance on when to use this tool versus alternatives. It mentions payment requirements but no explicit context like 'Use this to monitor MEV activity' or exclusions. The purpose is implied, but no direct comparison or recommendation is given.

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

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

With no annotations provided, the description carries the full behavioral burden and does it well. It explicitly discloses the API key bearer-token requirement and the pay-per-call option (2 cents via Binance b402 or x402 on Base). It also discloses the window boundary behavior (default 24, max 720). Missing details like rate limits or error handling keep it from a 5.

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

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

The structure is somewhat dense and not front-loaded: the first and longest sentence is about authentication and payment logistics, while the actual functional description only appears in the second sentence. The payment details are relevant, but they could be summarized more concisely. The core purpose sentence itself is tight and informative.

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

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

Given the output schema and the input schema, the description provides sufficient context for an agent: what is returned, how the parameters behave, and the required payment/auth flow. Minor gaps remain such as unclear exactly how the sampled series is omitted, but they are not blocking. The description is complete enough to decide to call and invoke correctly.

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

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

The schema has no parameter descriptions (0% coverage), but the description fully compensates. It explains that window is measured in hours, provides the default value, and the maximum. It also explains the chain behavior with 'Omit chain for all nine', which is not obvious from the schema alone. This is exactly the kind of semantics a tool description should add.

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 (open interest per chain) and enumerates the exact data components ('latest value, the value at the start of the window, change in percent, high and low inside the window and a sampled series'). The explicit verb is missing, but the noun phrase 'Open interest per chain' functions as a clear resource description. It is distinguishable from the sibling market-data tools, though it does not name any 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 communicates how to use the parameters (window in hours, default 24, max 720, omit chain for all nine) and the required authentication/payment model. However, it provides no explicit guidance on when to use this tool versus related siblings such as candles or prices. The usage context is implied: if you need open interest data, use 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?

With no annotations, the description carries the full burden for behavioral disclosure. It reveals authentication and billing requirements, the data source (Deribit), horizons available, and the time comparison baseline (latest hour versus 24 hours earlier). It stops short of describing rate limits or exact return formatting, but that is partially covered by the presence of an output 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 fits into a single sentence but is dense and front-loaded with billing routes before stating the actual function of the tool. All content earns its place, but the structure obscures the core purpose and could be improved by putting the functional description first.

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

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

With output schema present and only two enum-only optional parameters, the description covers the main input and output semantics. It adds essential operational context (authentication/payment, data source, horizon types, and time window) and is mostly complete for tool selection and invocation, though it leaves horizon definitions implicit.

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

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

The schema description coverage is 0%, and the description compensates by naming both parameters: horizon values (front, short, mid, long) and currencies (BTC, ETH as Bitcoin and Ether). It enriches the semantic meaning by listing the volatility metrics and explaining the comparison window, which param names alone would not convey.

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 providing a Bitcoin and Ether options volatility surface from Deribit, including the specific metrics (ATM, put/call IV, risk reversal, butterfly, open interest) and horizons. It lacks a direct command verb like 'get' or 'list', and the purpose is buried after billing information, but 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 usage prerequisites: a ChainHelix API key or pay-per-call via Binance b402/x402. It does not specify when to prefer this tool over sibling tools like iv_summary or open_interest, and provides no exclusions or alternative routing guidance.

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

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

No annotations are provided, so the description carries the full burden of disclosure. It transparently explains authentication and payment requirements (Bearer token or per-call fee) and the scope of the request (all nine chains or a single chain). However, it does not describe what happens without valid payment, error behavior, or the response format, leaving gaps for a tool with zero annotation support.

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 long sentence that leads with payment requirements rather than the core purpose, which reduces front-loading effectiveness. The payment details are extensive and somewhat verbose, though they do convey necessary authentication context. It could be restructured to state the function first and move payment details to a secondary position.

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

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

Given the low complexity (one optional parameter, output schema present), the description covers the essential aspects: what it does (live prices), how to invoke it (omit chain for all), and important constraints (authentication/payment). It does not explain the return value structure, but the output schema presumably handles that. It lacks rate limits or failure scenarios, which would make it more complete, but for a simple price check tool this is adequate.

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

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

The schema has 0% description coverage, but the description explicitly explains the key behavior of the only parameter: 'Omit chain for all nine.' This directly tells the agent how to use the optional chain field and what the default behavior is. While it doesn't list each enum value (the schema already does), it adds meaningful usage semantics 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 clearly states the tool's function: 'Live price for every chain in one call' and 'the one cent market check,' which conveys it returns current prices for blockchain networks. It does not use a direct verb like 'get' or 'retrieve,' and it does not explicitly distinguish itself from sibling tools such as market_state, so it misses the top score.

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 as a quick, low-cost market check and provides a concrete instruction: 'Omit chain for all nine.' However, it does not specify when to use this tool versus alternatives like market_state or deep_report, nor does it mention any situations where this tool should be avoided. No exclusions or comparisons 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?

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 carries the full burden and does so thoroughly: it discloses authentication requirements, per-call payment options, default and maximum limit, live status semantics, probe age for verified agents, unverified labeling, and a free check link. This goes well beyond a typical short description and helps an agent understand real-world constraints.

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

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

The description is front-loaded with a long billing preamble that buries the actual search functionality until the second sentence. The cost and token details are much more verbose than needed for a tool selection description. While every detail might technically earn its place, the ordering and verbosity damage 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?

The description provides enough context for a caller to understand the full system: network, registry, search behavior, status semantics, auth/cost requirements, and the limit range. Since an output schema exists, the lack of an explicit return shape is not a penalty here. It is complete for the operational context.

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

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

Schema coverage is 0%, so the description must provide parameter meaning. It does: 'by name and description' explains how `query` is used, and it supplies the otherwise missing default and maximum for `limit`. This is strong compensation for an otherwise minimal 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 searches the ERC-8004 registry on BNB Smart Chain by name and description, and joins results with live ChainHelix status. The specific registry, network, and search fields make it distinct from simpler sibling tools like verified_agents. The billing preamble does not obscure the core purpose.

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

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

Usage is implied rather than explicit: the description explains that the tool searches by name/description and includes unverified agents, which hints at when to pick it over a verified-only list. However, it does not name alternatives, say when not to use it, or clarify trade-offs versus 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, the description carries the full burden. It discloses auth/payment requirements (API key or pay-per-call) and defines session boundaries, which adds useful behavioral context. However, it does not mention read-only status, failure modes, or whether the output varies by chain parameter, leaving some 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 only two sentences but the first sentence is a lengthy payment list (over 40 words) that delays the core purpose. The actual functionality is in the second sentence. While not overly long, the structure is not front-loaded and the payment detail could be condensed or placed after the purpose.

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?

Although an output schema exists, the description lacks context about how the chain parameter affects the results, what 'share of price movement' means precisely, and whether this is a read-only query. The session definitions are helpful, but for a tool with one simple parameter, the description should link that parameter to the output.

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 one parameter 'chain' with a list of chains but zero descriptions. The description does not mention the chain parameter at all, so it adds no explanation of how to choose a chain or what role it plays. With 0% schema coverage, the description was expected to compensate but fails.

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 output: "Share of price movement per trading session over 7 days" and defines the sessions as Asia, London, New York in UTC thirds. This distinguishes it from siblings like correlation_matrix or market_state, though it lacks a traditional verb+resource structure.

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

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

No guidance is given on when to use this tool versus alternatives. The description focuses on payment requirements and output definition, but does not indicate scenarios where session_stats is preferred over related tools like latest_signals or situation_report.

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 disclosure burden. It transparently states authentication requirements, per-call payment alternatives, and the scope of data included, which is valuable for an agent deciding whether and how to invoke the 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 informative but opens with a long payment/financial detail sentence before stating the tool's actual purpose. The pricing alternatives are more detailed than an agent likely needs up front, and this slightly weakens discoverability and focus for core use.

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 only one optional parameter and an output schema, the description is complete: it gives needed auth context, optionality, chain scope, and what the report contains. The agent has all required details to select and invoke the tool for a broad multi-chain situation snapshot, and there is no need for rich parameter semantics.

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 an enum for chain but no description, so the description's 'Omit chain for all nine' adds meaningful optional/default behavior. It could have explicitly said 'pass one of the enum values to narrow to that chain,' but the enum and optionality make that reasonably inferable.

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 what the tool returns: a single cross-chain market report covering momentum, price walls, large transfers, bot activity, and the Bitcoin queue. This is specific enough to separate it from a generic 'market state' tool, though it never names or contrasts 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?

It gives strong operational context: this is a one-call, full-market-picture tool and omitting chain includes all nine chains. It does not explicitly describe when not to use it or which sibling tool should be preferred for narrower reports.

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 behavioral burden. It discloses the access requirement (ChainHelix API key or paid payment options), and the output composition (mints, burns, counts, dollars, large events, net). While it does not explicitly state read-only, the data-query framing is clear enough.

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 text is appropriately sized and makes every sentence count, but it is not front-loaded: the access/payment details lead, pushing the actual tool purpose to the second sentence. The core function would be better served if stated first.

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

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

For an analytics query with an output schema present, this is reasonably complete: it covers parameters, defaults, access, and output semantics. It omits response-level detail like pagination or error conditions, but those are lesser gaps 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%, but the description compensates well: 'window in hours' and default/max are given, and 'Omit chain for all' explains the optional behavior of the chain parameter. The parameter values are clear even without additional 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 clearly states that the tool reports stablecoin mints and burns per chain and coin, listing specific outputs (counts, total dollars, large events, net). The resource and action are unmistakable, and the stablecoin focus differentiates it from related siblings like bridge_flows or whale_flows.

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

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

It gives operational guidance ('window in hours, default 24, max 720', 'Omit chain for all'), which helps an agent understand how to parameterize a call. However, it does not explicitly mention when to prefer this tool over sibling alternatives or what scenarios are not 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 disclosure burden. It reveals that every ERC-8004 registration is probed on-chain, only alive and hireable agents are returned, and the output includes probe age, latency, and permanent evidence. It also mentions the required auth/payment condition. It does not mention rate limits or explicit read-only behavior, but given the query-like nature it is reasonably transparent.

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 not front-loaded. Payment and authentication details dominate the first sentence, pushing the actual purpose to the second. The text is dense and includes repeated concepts such as 'alive and hireable' and 'on-chain/on BNB Smart Chain', making it harder to parse 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?

Given a single optional parameter and no explicit output schema, the description supplies enough to call the tool: it names the returned fields, the verification process, the filter options, and the auth/payment requirements. The main gaps are lack of pagination, error behavior, and rate limit details, but these are secondary for a simple list tool.

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

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

Schema description coverage is 0%, so the description should compensate. It only repeats the enum values without explaining what 'hireable' vs 'alive' means, whether the status field is a filter, or what happens if it is omitted. The phrase 'Optional status hireable or alive' mirrors the schema rather than adding useful 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: verified live agents on BNB Chain, and explicitly says the tool lists agents that are actually running and hireable with endpoint, skills, latency, and evidence. It does not use an explicit verb like 'list' or 'get', and does not distinguish itself from sibling tools, so it falls short of a 5.

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

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

There is an implied use case: when you need the current map of verified running/hireable agents on BNB Smart Chain, and an optional status filter of 'hireable' or 'alive'. However, it never explicitly explains when to choose this tool over alternatives or when not to use it, so we have inferred usage, not clear 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. 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?

There are no annotations, so the description is the default fallback behavior communicator. It clearly discloses authentication and payment requirements, public onchain data scope, and the specific event/attribute types included (mixer, bridge, transfer events). It is transparent about the financial barrier and that it's purely based on public behavior, but it doesn't cover things like cache freshness or rate limiting.

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 has two sentences and contains useful information throughout, but it front-loads payment details before the core purpose, which reads as a run-on. The long list of output fields is useful but also likely duplicates an output schema and partially interfere with readability.

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

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

Given an output schema exists and the schema provides the chain enum, the core function and the payment/scope requirements are covered. But the description remains incomplete regarding input semantics for the optional chain parameter and doesn't clearly articulate the default or expected behavior when chain is omitted. This is a moderate gap for an agent that must construct this 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?

With 0% schema description coverage, the description needs to explain the address and chain parameters with special care. It mentions 'wallet address' and 'across chains' but never references the 'chain' parameter directly, does not indicate whether chain is an active filter or aggregation scope, and gives no guidance on address format or default chain behavior. This is a meaningful 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 states 'Risk profile of one wallet address across chains' and enumerates the specific output fields (risk score, mixer funding, dormancy, transaction count, protocols used, etc.). This clearly conveys the tool's verb-adjacent purpose and resource. It's a bit indirect because it doesn't begin with an imperative like 'gets', but the meaning is unambiguous and distinct from 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 conveys the broad intended use case (assessing risk of a wallet) and important preconditions around API key or alternate payment. It does not, however, explicitly mention when NOT to use this tool, what sibling tools alternatives it compares to, or how it differs from tools like situation_report, chain_brief, or deep_report. The use is implied rather than explicitly contrasted.

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 transparency burden. It discloses authentication requirements (bearer token or payment via Binance/x402), which is valuable context. However, it does not mention whether the operation is read-only, potential rate limits, or data freshness, and the payment details are verbose without adding functional clarity.

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 front-loads payment/authentication details before explaining the actual purpose. The payment breakdown (Binance b402, USDT, USDC, USD1 or U, BNB Smart Chain, x402, USDC, Base network) is lengthy and better suited for a separate auth section. The core functionality is buried in the middle, making it less scannable.

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 an output schema and one optional parameter, the description covers the essential functional purpose and the unusual payment/auth context. However, it omits behavioral details like rate limits, read-only status, and any edge cases. The verbose payment info does not fully compensate for these gaps.

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

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

The single parameter 'chain' has an enum in the schema but no description (0% schema coverage). The description compensates by explaining 'per chain' and 'Omit chain for all nine', which clearly clarifies the optionality and default behavior. This adds meaningful semantic value 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 'Support and resistance price walls per chain with touch counts, from hourly to weekly market structure.' This identifies the resource and scope, and distinguishes it from sibling tools by its unique output. However, it lacks a verb like 'get' or 'list', making it slightly less direct.

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 guidance on how to use the chain parameter ('Omit chain for all nine') and explains authentication/payment options, which is useful. However, it does not explicitly state when to use this tool over sibling alternatives or provide exclusions, leaving the when-to-use context 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?

No annotations are present, so the description carries full burden. It discloses auth requirements (bearer token), payment options and cost, event payload types (signal_sealed and trade_closed), that deliveries are signed, and that re-registering with the same URL extends the delivery period. It doesn't specify idempotency or duplicate registration behavior, but the disclosed behaviors are substantial.

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 front-loads the auth/payment requirement, then explains the purpose and event types. While it mixes pricing details with functional behavior, each sentence adds necessary context for a tool with no annotations. It could be better structured with separators, but it is not bloated.

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 registration tool with a minimal input schema and no annotations, the description covers the core purpose, required auth, payment model, event payloads, signing, and extension behavior. The output schema exists, so return values are not required in the description. Some edge cases (duplicate registration, URL validation) are not covered, but the description is complete enough for typical usage.

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 only url (required) and events (optional array of enums), with 0% schema description coverage. The description explains that the URL is 'your https URL' and describes the two enum values with meaning: 'signal_sealed (the sealed signal stream the moment each signal exists) and trade_closed (every finished trade with its result).' It does not explicitly state that events is optional or the default behavior, but it adds meaning beyond the schema's bare enums.

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 registers a webhook to receive pushed ChainHelix events ('Get ChainHelix events PUSHED to your https URL instead of polling'), names the two event types, and the verb 'PUSHED' distinguishes it from polling-based tools. The sibling names webhook_unregister and webhook_status reinforce the unique purpose.

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

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

It provides a clear when-to-use: 'instead of polling' and lists the required authentication/payment prerequisite. It also explains how to extend delivery ('call again with the same URL any time to extend') and notes that an active API key registers at no charge. However, it does not explicitly exclude cases like one-time data needs or mention alternative tools by name.

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

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

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.

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

With no annotations, the description carries the full burden. It discloses the authentication requirement ('only the holder of the secret can remove it') and implies a destructive action via 'Remove'. However, it does not detail side effects (e.g., immediate deactivation) or error behavior, making transparency 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?

One concise sentence with clear structure: it states the purpose first, then the required inputs and condition. No unnecessary words or 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?

The tool is simple (2 params, output schema present), and the description covers the core purpose, required inputs, and authorization condition. It does not explain return values (covered by output schema) or error cases, but for this tool that is 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?

The schema provides no descriptions (0% coverage), so the description compensates by explaining that 'id' is the webhook identifier and 'secret' is the signing secret from registration. This adds meaning beyond the raw string types.

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 the specific verb 'Remove' with the resource 'webhook', clearly stating the action. It distinguishes from sibling tools like webhook_register (which creates) and webhook_status (which checks status).

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 through the verb 'Remove' and mentions the prerequisite of having the id and signing secret from registration. However, it does not explicitly compare with alternatives like webhook_register or webhook_status, so it lacks explicit when-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 full burden. It discloses payment requirements, default/max window, and threshold, which are useful behavioral traits. However, it does not clarify whether the tool is read-only, mention rate limits, or describe data freshness, leaving important operational aspects unclear.

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 with important information but lacks clear sentence structure. It is not overly verbose, but the run-on format makes it harder to parse quickly. Each piece of info has its place, but better organization would improve readability.

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

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

Given that both parameters are optional, the description does not explain what happens if chain is omitted (e.g., returns all chains? errors?). It also doesn't describe the response format, though an output schema exists. The missing default behavior for optional parameters is a significant gap for an agent choosing this 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% and the description partially compensates by explaining window (hours, default 24, max 168). It mentions 'per chain' but does not elaborate on chain choices, though the schema's enum provides those. The threshold is described but is not a schema parameter. Overall, the description adds value for window but leaves chain semantics 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 states 'Large transfer counts and USD totals per chain', which indicates the tool's primary output but lacks an explicit verb like 'Get' or 'List'. The purpose is inferable but not clearly phrased as a command, and the heavy focus on payment details obscures the main function.

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 versus alternatives or when it might be appropriate. The description only covers authentication and output type, with no mention of typical use cases or exclusions.

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