ChainHelix for Machines

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 authentication/payment methods, on-chain behavior (opBNB), automatic publish of claim and salt at reveal time, and important limitation (attests when, not truth). This is exceptionally 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 a single dense paragraph packed with necessary details. While every sentence earns its place, it could be structured with bullet points for readability. Still, it is appropriately sized for the complexity.

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, identity, on-chain sealing, reveal process), the description covers all essential aspects: authentication, payment options, identity, chain, reveal behavior, and a pointer to verification spec. Output schema exists, so return details are not needed. This is complete.

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

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

The schema has 0% coverage, but the description fully explains both parameters: 'payload' as the claim string and 'revealDelayHours' with range (1 to 720) and default (72). This adds critical meaning beyond the schema's bare type definitions.

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 explicitly states the tool's function: 'Seal any claim on chain now, reveal it later' and clarifies it attests 'WHEN you said it, never whether it is true.' It distinguishes itself from sibling tools like attest_spec and verify_reveal by focusing on the sealing 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 gives clear operational context (payment requirements, claim format, reveal delay) and points to attest_spec for verification. However, it doesn't explicitly contrast with alternatives for when to use this specific tool versus list_attestations or verify_reveal, so a slight deduction.

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

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

The description indicates the tool delivers 'live' counts, implying real-time read-only data. However, it does not elaborate on authentication needs, rate limits, or the meaning of 'gaps'. With no annotations, more behavioral disclosure would be beneficial.

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 concise phrase that directly communicates the tool's purpose without any fluff. Every word adds value.

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

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

For a zero-parameter tool with an output schema, the description adequately covers what the tool does and what it returns (counts of different attestation statuses). It could be slightly more explicit about the output structure, but the output schema likely covers that.

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 the description does not need to explain parameter details. The baseline of 4 applies.

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

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

The description clearly identifies the tool as providing live counts for the attestation stream, specifying categories (committed, anchored, revealed, gaps). This distinguishes it from sibling tools like attest_status or list_attestations, though it lacks an explicit verb.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions or suggest using it instead of listing attestations for aggregate counts.

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 communicates that this is a spec (implying read-only/documentation) and describes the content, but it does not explicitly state there are no side effects, what the output format is, or any constraints. The description adds some context beyond the name but lacks explicit behavioral disclosure.

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

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

The description is a single sentence with no wasted words. It is concise but slightly dense; a clearer structure (e.g., a colon or list) could improve scannability, though it remains acceptable.

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 simplicity of a zero-parameter tool with an output schema, the description sufficiently outlines the scope of the spec. It could mention that this is a reference resource and not an action, but the nature of a 'spec' makes that mostly implicit. Overall, it provides enough context for basic understanding.

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

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

The tool has zero parameters and the schema coverage is 100% (empty). There is nothing to document, so the description doesn't need to compensate. The baseline of 4 is appropriate.

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

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

The description clearly identifies the tool as the machine verification spec for the attestation service, detailing what it covers (how sealed claims are hashed, put on chain, and verified). It goes beyond the name and gives a concrete understanding of the resource, though it lacks an explicit action verb and doesn't differentiate 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 guidance is provided on when to use this spec versus other attestation-related tools. It doesn't state that this is a reference/documentation resource or mention alternatives, leaving the agent to infer usage.

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

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

With no annotations, the description carries the full burden and does well by explaining the before/after reveal time differences in output. It lacks error handling or permission info, but the key behavioral nuance is covered.

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

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

Two concise sentences with front-loaded action and no filler. Every word contributes to understanding the tool's behavior.

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

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

For a single-claim check tool, the description covers the main complexity (reveal-time behavior) and the selection criteria. With an output schema present, return values need not be described in text, though error cases are not mentioned.

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 clarifies that tenant is required and that seq or hash is an alternative selector, which is not evident from the schema. However, it does not define the exact format or semantics of seq and hash beyond their 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 checks a single sealed claim using tenant plus seq or hash. The verb 'Check' is somewhat generic, but the resource and scope are specific, distinguishing it from sibling list 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 implies usage for checking one claim's status, and the reveal-time behavior provides context, but it does not explicitly compare to alternatives like list_attestations or verify_reveal.

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 the return values (payment address, exact amount, claim token), the expiration of orders after 24 hours, and the optional email behavior. It also describes the required payment flow. This is substantive behavioral context, though it does not mention error cases or whether the operation is reversible.

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 appropriately sized and every sentence earns its place. It front-loads the purpose, then gives necessary plan/chain details, return values, next steps, and expiration/email behavior. There is no redundancy 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 description covers key aspects: return values, next step (claim_key), expiration, and email behavior. It lacks explanation of the 'alerts' plan and does not describe potential errors or payment confirmation details. Given no output schema and no annotations, it is fairly complete but has minor 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 description adds significant value beyond the schema by explaining plan options (standard $99/120 RPM, pro $249/600 RPM) and listing supported chains. However, it completely omits the 'alerts' plan that appears in the schema enum, leaving a gap that could mislead the agent. Email is described as optional, which is helpful.

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 purpose: 'Buy a ChainHelix API key without a browser or account.' It specifies the action (buy), the resource (API key), and key context (no browser/account). It also distinguishes from sibling 'claim_key' by describing the follow-up step, making the role 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 provides clear usage context: it is the first step to obtain a key, and it explicitly instructs to 'call claim_key' after payment. It implies this is for new purchases without an account, but does not explicitly state when not to use it or mention alternatives beyond the implied next step.

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 of behavioral disclosure. It adds valuable context: 'The key is returned exactly once, save it' highlights a one-time retrieval behavior, and the 30-minute timing provides expectations about claim availability. It does not mention what happens on duplicate claims or errors, but the disclosed behaviors are meaningful.

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 short sentences, each providing distinct information: the action, the save caveat, and the timing expectation. There is no fluff or repetition; it is front-loaded with the core purpose and remains compact.

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

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

For a tool with one parameter, no output schema, and no annotations, the description covers the essential aspects: purpose, the claim token input, the one-time retrieval, and the claimability delay. It lacks error behavior or prerequisites beyond a paid order, but the low complexity makes this a reasonably complete 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?

The description only repeats the parameter name ('Takes the claim token') without explaining what the token is, where to obtain it, or its format. With 0% schema description coverage, the parameter is effectively undocumented beyond a raw string type. The description fails to compensate for the missing semantic guidance.

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

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

The description clearly states the action ('Claim the API key') and the specific resource ('a paid buy_key order'), distinguishing it from related tools like buy_key (which creates the order) and key_order_status (which checks status). The verb is specific and the scope 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 provides clear context on when to use the tool: after a paid buy_key order, with the claim token, and notes that payments usually become claimable within 30 minutes of on-chain confirmation. It does not explicitly name alternatives, but the lifecycle is clear. No exclusions are given, but the context is sufficient.

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

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

With no annotations, the description carries the full behavioral burden. It clearly discloses authentication (ChainHelix API key as bearer token) and alternative payment methods, which is critical for invocation. However, it does not mention other behavioral aspects like rate limits, caching, or any side effects (though the tool appears read-only). The payment information is a useful behavioral context.

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

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

The description is a single long sentence that leads with payment/auth details before stating the actual purpose. This is not optimally front-loaded; the core functionality appears later. It is concise in word count but structurally could be improved by stating the service first, then the access requirements.

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

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

For a zero-parameter tool with an output schema, the description sufficiently covers the main data points (queue depth, time range, fastest fee) and access constraints. It does not explain return format, but the output schema should cover that. The payment options are clearly enumerated, adding necessary context for real-world invocation.

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

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

The input schema has zero parameters, so baseline for parameter semantics is 4. The description does not miss any parameter documentation since none exist. It implicitly conveys that the tool takes no arguments and returns current and historical congestion data.

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

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

The description states the tool provides 'Bitcoin queue depth now vs the past 30 days plus the current fastest fee', which clearly identifies the resource and data. However, it lacks an explicit verb like 'get' or 'fetch', so the purpose is inferred rather than grammatically explicit. It distinguishes from siblings by focusing on Bitcoin congestion metrics.

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 mentions payment requirements but does not explain when Bitcoin congestion data is relevant or how it compares to sibling tools like market_state or prices. There are no explicit when/when-not statements.

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 meaningful behavioral context: it reveals the need for a ChainHelix API key or per-call payment, and specifies the window parameter's default and maximum. However, it does not describe the return structure or error behavior, though an 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 reasonably concise but leads with payment requirements rather than the core function, which is slightly suboptimal for front-loading. All information is relevant and there is no filler.

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

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

For a tool with one parameter and an output schema, the description covers the essential context: payment/auth, core function, and parameter limits. It could be improved by listing the nine chains or clarifying the output format, but overall it is adequate for an agent to use the tool correctly.

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

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

The schema only lists 'window' as a number with no description. The tool description compensates by specifying units ('in days'), a default of 7, and a maximum of 30, providing critical meaning that the 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 states the tool computes 'Pairwise correlation of hourly returns across the nine chains', which is a specific verb+resource. It distinguishes itself from sibling tools like 'prices' or 'market_state' by focusing on correlation analysis.

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 provided on when to use this tool versus alternatives. The description focuses on authentication/payment requirements and the parameter, but does not explain scenarios where correlation analysis is appropriate or when another tool might be preferred.

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

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

The description discloses important behavioral traits: it requires a ChainHelix API key as bearer token or a payment of 25 cents per call via specific payment channels. However, with no annotations, it should also explicitly note that this is a read-only operation and any other side effects; it does not.

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 run-on sentence that leads with payment/auth details before getting to the tool's purpose. Key information is buried, and the structure is verbose. A more concise, front-loaded description would put the purpose first and summarize payment separately.

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 lists many report features but fails to clarify the only parameter, which is critical for invocation. It also doesn't explain how this tool differs from sibling tools like situation_report or market_state. While an output schema exists and may describe return values, the description leaves the agent unclear on usage scope.

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 a single 'chain' parameter with an enum of nine blockchain names, but the description provides no explanation of what this parameter does. The phrase 'nine chain research brief' is ambiguous—it might mean the report covers all nine chains or that the user selects one. With 0% schema description coverage, the description was required to compensate and did not.

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

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

The description eventually states the tool produces 'the complete nine chain research brief' and lists specific contents (price walls, large transfers, bot activity, conviction scores, etc.). However, the purpose is buried after a long payment explanation, and it doesn't explicitly differentiate from sibling tools beyond calling itself 'the most complete single answer this server produces.'

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

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

The phrase 'most complete single answer' implies this tool is the go-to for a comprehensive research brief, but it doesn't name alternative tools (e.g., situation_report, market_state) or state when not to use this tool. The guidance is implied but not explicit.

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

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

With no annotations, the description carries full burden. It does disclose a critical behavioral trait: the requirement for a ChainHelix API key or payment via Binance/x402. However, it does not disclose whether the operation is read-only, rate limits, or what the output contains beyond the stated comparison. The payment requirement adds useful context but leaves other behavioral aspects undisclosed.

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 details, burying the actual purpose ('Near term option implied volatility...') at the end. It is not front-loaded and could be split into two sentences for clarity. However, it is not overly verbose, so it earns a mid-range score.

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

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

Given the tool's simplicity (no parameters, output schema exists), the description covers the core purpose and the essential auth/payment context. The output schema presumably handles return values, so the description does not need to explain those. It is complete enough for a straightforward data-retrieval tool with a paywall caveat.

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

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

The tool has zero parameters and the schema is empty, so there is nothing to explain. The description therefore needs no parameter semantics. A baseline of 4 is appropriate because no parametric ambiguity exists.

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 near-term option implied volatility for Bitcoin and Ethereum, comparing now vs one week ago. This distinctly identifies the resource and scope, differentiating it from siblings like prices or market_state. However, it lacks an explicit verb like 'Get' or 'List', so it is clear but not a model example of verb+resource.

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 provided on when to use this tool compared to alternatives such as prices or market_state. The extensive payment/auth information is a prerequisite, not usage context. The description does not mention exclusions or preferred 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, the description carries the burden. It details what is reported (payment seen, key ready) but does not explicitly state side-effect-free behavior, idempotency, or error conditions.

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

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

Two sentences that front-load the purpose and include only necessary details. 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?

For a simple one-parameter tool with no output schema, the description sufficiently explains what it does, what it takes, and what it returns. Could mention repeat-call safety but not essential.

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 mentions the claim token and connects it to buy_key, adding some meaning beyond the bare schema. However, it lacks detail on token format, source, or constraints, and schema coverage is 0%.

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?

Clearly states the tool checks a key order created with buy_key, and reports on payment status and key readiness. This distinguishes it from siblings like buy_key and claim_key.

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?

Implies usage after buy_key and before claim_key by describing the status check flow. Does not explicitly exclude alternatives, but context 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 fully carries the burden. It discloses authentication/payment requirements, output fields, immutability ('sealed on chain... cannot be edited afterward'), and verifiability. This is substantial behavioral transparency, though it omits potential rate limits or latency details.

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

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

The description is detailed but every sentence serves a purpose: payment prerequisites, the core function, output content, immutability, verification, and parameters. It is somewhat dense but not verbose, with clear front-loading of essential access information.

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

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

Given the presence of an output schema and no annotations, the description covers the essential usage context: authentication/payment, the nature of the stream, output fields, immutability, verification, and parameter constraints. It is sufficiently complete for an agent to decide when and how 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 schema has 0% description coverage, so the description must compensate. It adds that 'chain' is optional and 'limit up to 50' imposes a maximum. This adds some meaning beyond the schema (which only shows types/enum), but it does not fully explain each parameter's purpose or behavior in detail.

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

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

The description clearly states it provides 'The live ChainHelix signal stream, newest first', naming the specific resource and action. It also lists the signal contents (chain, direction, entry price, win probability, conviction score), which distinguishes it 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?

Clear context is provided: this tool returns live signals, with optional chain filtering and a limit up to 50. It also references 'free proof tools' for verification, suggesting a workflow. However, it does not explicitly state when to use this tool versus alternatives, or any exclusions.

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

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

No annotations are provided, so the description carries the burden. It discloses behavior: ordering (newest first), content (matured claims include text and salt), and a limit (up to 200). However, it does not mention whether the stream is paginated, what happens if tenant is invalid, or any other side effects. It adds some useful behavioral context beyond the name, but not a complete profile.

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

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

The description is a single sentence that front-loads the core purpose and includes import behavior details (ordering, limit, matured claims content). No wasted words; every phrase contributes understanding.

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

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

For a simple listing tool with 2 parameters, the description covers the primary return value ('full sealed-claim stream'), ordering, and limit. It does not explain what a sealed-claim stream is in depth, but that may be domain knowledge. An output schema is present (per context), though not shown, so the description's mention of claim contents is sufficient. It is complete enough for an agent to use the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the limit parameter ('Optional limit up to 200') and implies the tenant parameter is the scope ('A tenant's full sealed-claim stream'). However, it does not specify that tenant is required (schema does), nor does it describe acceptable formats or defaults. It adds meaningful context for limit and general tenant semantics, but leaves gaps.

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 a tenant's full sealed-claim stream, newest first, which directly aligns with 'list_attestations'. It specifies the resource (sealed claims) and scope (per tenant), and it is distinct from sibling tools like attest or attestation_stats which have different purposes.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or compare to sibling tools such as attestation_stats or list_reveals. The only usage hint is 'Optional limit up to 200', which is a parameter constraint, not usage guidance.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions that reveals include Merkle paths and are 'matured', but does not state that the operation is read-only, whether pagination is applied, what happens with the 'month' filter, or any limitations. The description adds minimal behavioral context beyond the tool name.

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 extremely concise, containing no filler words. It front-loads the core resource ('Matured signal reveals') and immediately notes the optional parameters. However, the structure is fragmentary: the first clause lacks a verb, and the second sentence is incomplete. Still, it is appropriately brief for the tool's simplicity.

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 there are no annotations and the description is sparse, the tool is under-specified for an agent. It does not clarify what 'matured' means, how the month filter interacts with reveals, or how this tool differs from related listing tools. The presence of an output schema helps, but the description alone does not provide enough context for reliable selection and invocation.

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

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

The schema has zero description coverage for its properties. The description adds some semantics by noting that 'month' is in YYYY-MM format and that both month and limit are optional. However, it does not explain the exact meaning of 'limit' (e.g., max number of reveals) or how 'month' filters the results. This partial compensation earns a mid-range score.

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 ('signal reveals') and a key attribute ('Matured', 'with Merkle paths'), making the tool's function recognizable. However, it lacks an explicit verb; the action is only implied by the tool name 'list_reveals'. It does not explicitly distinguish from sibling tools like 'list_attestations' or 'latest_signals'.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or comparisons to sibling tools such as 'latest_signals' or 'verify_reveal'. The only hint is the phrase 'Matured signal reveals', which implies use when interested in matured reveals, but this is not explicit.

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

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

With no annotations, the description carries the transparency burden. It discloses the authentication/payment requirements ('Requires a ChainHelix API key as bearer token, or 2 cents per call...') which is useful. However, it does not explicitly state whether the operation is read-only or describe error behavior/rate limits, 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 a single dense sentence that front-loads payment details before the functional description. While concise in length, the structure could be improved by stating the core purpose first. It includes necessary info but the ordering makes 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 one optional parameter, an output schema, and no nested objects, the description covers the essential purpose and the key usage nuance (omitting chain). It also covers the unusual payment/auth context. Some domain terms ('regime', 'range age') are undefined but likely acceptable for the intended audience.

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%, so the description must compensate for parameter semantics. It does so by explaining the 'chain' parameter behavior: data is provided 'per chain' and omitting chain retrieves 'all nine'. This directly informs how to use the optional parameter beyond the enum list.

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 the tool returns market state data: 'Regime, range age and volatility state per chain.' The verb is implied but the resource and scope are clear. It doesn't explicitly differentiate from sibling tools like 'prices' or 'congestion', but the specific metrics define its 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?

The description gives usage context by mentioning 'Omit chain for all nine' and the authentication options. However, it does not explicitly state when to use this tool over alternatives like 'prices' or 'congestion'. The guidance is implied through the described data outputs rather than explicit comparisons.

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

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

The description discloses authentication requirements (bearer token or payment methods), window defaults and maximum, and the comparative nature of the data (trailing weekly pace). No annotations are provided, so the burden is on the description; however, it omits details about return format, error behavior, or rate limits. It is not contradictory, but 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 description is two sentences but the purpose is buried in the second sentence after a lengthy authentication and payment explanation. The first sentence is verbose (listing multiple tokens and networks) and delays the core purpose. It is not excessively long, but the front-loading is poor.

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

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

There is an output schema, so return values need not be described. However, the description leaves ambiguity around the 'type' dimension, does not clarify how chain selection works, and provides no context about expected data granularity or use cases. The authentication and window constraints are covered, but overall completeness is moderate.

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 useful semantics for the 'window' parameter (default 24 hours, max 168), which is beyond the raw schema. It vaguely references 'per chain' but does not explain the 'chain' parameter values or the meaning of 'type' (which is not even in the schema). With 0% schema coverage, more compensation was expected, but the window details give some value.

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: 'MEV event rates per chain and type vs the trailing weekly pace.' This indicates a retrieval/reporting operation, distinct from siblings like congestion or whale_flows. However, it lacks an explicit verb like 'get' or 'query', 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions or preferred use cases. The description focuses on auth/pricing and basic parameters but does not discuss situational applicability.

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 clearly states the authentication requirement (Bearer token or per-call payment) and the scope of the call (all chains vs one chain). It does not mention rate limits or error behavior, but the auth/payment context is valuable and beyond what structured data would 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 compact and information-dense. The first sentence lists payment options in detail, which could feel heavy, but every part serves a purpose. The core price-check functionality appears early, and the parameter guidance is concise. Minor jargon like 'b402' and 'x402' could confuse, slightly reducing clarity.

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 context: purpose, auth/payment, and parameter behavior. It does not explain return structure or format, but the presence of an output schema makes that unnecessary. The unexplained 'b402'/'x402' terminology is a minor gap, but overall the description 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?

Schema description coverage is 0% and there is one optional parameter with an enum. The description adds crucial semantics: 'Omit chain for all nine' explains the default behavior when the parameter is absent. This goes beyond the schema's simple optional flag, though it does not elaborate on each chain value.

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 prices for chains ('Live price for every chain in one call') and mentions the 'one cent market check' positioning. However, it does not explicitly distinguish itself from sibling tools like market_state or iv_summary, so it falls short of full 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 implies usage for quick market checks ('the one cent market check') and explains the optional chain parameter, but it does not provide explicit guidance on when to use this tool versus alternatives, nor when not to use it. The payment/auth context is useful but not a usage guideline.

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, and the description does not disclose behavioral traits such as whether this is a read-only operation, what the tool returns, or any side effects. The description carries the full burden and fails to reveal any behavioral context.

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

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

The description is extremely brief, but it is under-specification rather than concise. It is a nominal phrase without a verb, providing insufficient information for an agent to understand the tool's function. This mirrors the 'Process' example which scored 2.

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 having an output schema and zero params, the description fails to explain what the spec contains, how it is used, or what the output represents. The tool appears to be a simple retrieval, but the description is too incomplete to support correct invocation without additional 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?

With zero parameters, the input schema is trivially complete. The description adds no parameter details, but none are needed. Baseline of 4 is appropriate for a 0-param 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 is a noun phrase ('The machine verification spec...') rather than stating a specific action the tool performs. It lacks a verb like 'returns', 'gets', or 'validates', and does not differentiate from the sibling tool 'attest_spec' which likely has a similar name.

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. Since 'attest_spec' is a sibling, the description should clarify which spec is relevant, but it provides no such 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, the description carries the full burden of behavioral disclosure. It does disclose important operational requirements: a ChainHelix API key as bearer token, or a per-call payment of 2 cents via specific methods. It also defines the session boundaries precisely. However, it omits other behavioral traits such as response format, data recency, or potential errors, leaving the agent uncertain about execution 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?

The description is compact and front-loaded with critical operational information. The first sentence packs auth/payment details efficiently, and the next two sentences define the metric and session times. It is somewhat dense but every sentence adds information, and there is no redundant 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?

Given the simple one-parameter schema and the presence of an output schema, the description adequately explains the core purpose and session definition. However, it does not explain the role of the 'chain' parameter, nor does it clarify whether the output is per-chain or aggregate. The heavy focus on payment rather than functional context leaves some gaps in understanding what the tool actually does.

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 optional 'chain' parameter with an enum, but the description never mentions it. With 0% schema description coverage, the description should at least explain what 'chain' affects (e.g., which asset's session stats are computed), but it remains silent. The enum provides some hint, but the agent has to guess whether the parameter is required, what default exists, and how it relates to the described metric.

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 output: 'Share of price movement per trading session over 7 days.' It specifies the sessions (Asia, London, New York in UTC thirds) and the time window (7 days), providing a specific resource and scope. However, it lacks an explicit verb like 'retrieve' or 'return,' and does not differentiate from sibling tools such as market_state or iv_summary, so it falls short of a 5.

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

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

No guidance is provided on when to use this tool versus alternatives. The description focuses almost entirely on authentication and payment requirements, with no mention of use cases, prerequisites, or exclusions. The extensive sibling list further highlights the absence of any comparative direction.

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 burden. It does disclose authentication and payment requirements (ChainHelix API key or per-call payment via Binance b402/x402). However, it doesn't explicitly state read-only behavior, rate limits, or any other side effects, though the report nature implies non-mutating.

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 purpose is relegated to the second sentence after a lengthy payment sentence with detailed token and network specifics. While not wordy, the payment information is not front-loaded, and the purpose could have been prioritized for quicker parsing.

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

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

Considering the single optional parameter and presence of an output schema, the description covers the core functionality, the parameter's default behavior, and the cost/auth model. It doesn't explain the output structure, but that is handled by the schema, leaving the description 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?

The schema has a single optional 'chain' enum, but the description adds meaning by saying 'Omit chain for all nine', telling the agent that omission is valid and that the parameter selects specific chains. This goes beyond the schema's default documentation and clarifies the parameter's behavioral 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 states the tool provides 'the full market picture in one call' and lists specific data types (market state, price walls, large transfers, bot activity, Bitcoin queue) across all chains. This distinguishes it from focused siblings like market_state or whale_flows by emphasizing comprehensiveness and cross-chain coverage.

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

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

No explicit when-to-use or alternative guidance is provided. The phrase 'the full market picture' implies a broad overview, and 'Omit chain for all nine' suggests a default behavior, but the description doesn't state when this tool should be preferred over sibling tools or any 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 full burden. It does disclose the computation and return contents (check results and re-verification data), but it does not explicitly state whether the operation has side effects or requires any special permissions. The read-only nature is implied but not stated.

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

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

The description is a single sentence that front-loads the action and includes no filler. Every phrase adds value, making it appropriately concise.

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

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

For a simple tool with one parameter and an output schema, the description adequately covers the tool's behavior and return format. It does not address error cases or edge conditions, but those are not essential for a basic 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 only parameter 'seq' is described in the tool description as 'sequence number', which adds meaning beyond the schema's bare type 'number'. Since there is just one parameter, this coverage is sufficient.

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 a specific action ('Recompute the hash and Merkle fold') and a specific resource ('one reveal by sequence number'). It distinguishes itself from siblings like list_reveals by focusing on verification of a single reveal.

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 tool is for verification ('to re-verify independently on chain'), but it does not explicitly state when to use this over alternative tools like list_reveals, nor does it mention exclusions or prerequisites. Usage context is present but 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?

No annotations are provided, so the description carries the burden. It discloses authentication and payment requirements, which is useful. However, it does not mention response behavior, rate limits, or error handling, leaving some ambiguity.

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

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

The description is relatively concise but poorly structured: payment details are placed before the actual purpose. A reorder to lead with the tool's function would improve clarity without adding length.

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

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

For a tool with a single optional parameter and an output schema, the description provides sufficient context: what it returns (walls, touch counts, timeframes), how to authenticate, and the parameter semantics. It lacks a typical use-case statement but is otherwise complete.

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

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

The description explicitly explains the optional chain parameter behavior (omitting it returns all nine chains), which the schema does not. Since schema coverage is 0%, this is crucial. The enum values are self-explanatory chain 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 identifies the output as support/resistance price walls per chain with touch counts, distinguishing it from sibling tools like prices or market_state. However, it lacks an explicit verb (e.g., 'Returns'), and the purpose is buried after payment details.

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 accessing the same wall map used by the ChainHelix engine, and provides an explicit instruction to omit the chain parameter for all nine chains. It does not compare with alternatives or state when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses payment requirements (API key or per-call fee), event types, delivery duration (7 days), extension behavior, and that deliveries are signed. It does not explicitly state that this creates/changes a subscription, but the title and extension mention imply state change. Overall, it adds substantial behavioral context beyond the schema.

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

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

The description is a single dense paragraph, leading with payment details rather than the primary purpose. It contains useful information but lacks front-loading and scannable structure. The sentence 'Requires a ChainHelix API key as bearer token, or 70 cents...' is complex and sits before the actual functionality, making the intent less immediately apparent.

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 only two parameters, no annotations, and an output schema, the description covers cost, authentication, event semantics, delivery duration, extension, and signature verification. Missing details like error cases or how to unregister might be relevant, but sibling tools cover unregister. For a registration 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?

The schema has 'url' and 'events' with no descriptions (0% schema coverage). The description explains 'url' must be an https URL and defines the two event enum values. However, it does not clarify that 'events' is optional or how the system behaves if omitted (e.g., default to both events). This partial compensation leaves ambiguity about the events parameter.

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 conveys the core action—'Get ChainHelix events PUSHED to your https URL instead of polling'—which implies registering a webhook. It names specific event types (signal_sealed, trade_closed). However, it lacks an explicit verb like 'register' or 'subscribe' and does not clearly differentiate from sibling tools like webhook_status or webhook_unregister.

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

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

The phrase 'instead of polling' gives a clear scenario for using push, and 'call again with the same URL any time to extend' is a usage tip. There are no exclusions, prerequisites beyond authentication/cost, or comparisons to alternative tools 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 carries the full burden. It discloses important behavioral traits: the tool scopes results to the caller's tenant identity and never returns the signing secret. These are valuable privacy/security details that go beyond what the input schema alone conveys. It could additionally clarify pagination or read-only status, but the provided disclosures are sufficient for safe use.

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 with no fluff. It front-loads the main purpose, then adds necessary security context. Every clause earns its place, making it an excellent example of concise, structured documentation.

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 two parameters, an output schema, and no annotations, the description covers the essential aspects: what it returns, the tenancy scoping, and the secret non-disclosure. It lacks explicit alternative guidance (e.g., 'to register, use webhook_register'), but this is a minor gap given the tool's simplicity and the existence of an output schema. Overall, it is sufficiently complete for an agent to use correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by explaining 'tenant' as 'your paying wallet, or your key id' and 'id' as an optional narrowing to one webhook. This adds meaningful semantic meaning to both parameters, though it stops short of giving type formats or examples.

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

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

The description clearly indicates this tool retrieves a list of registered webhooks for the caller's tenant, optionally filtered by an id. While it lacks an explicit verb like 'list' or 'get', the phrasing 'Your registered webhooks...' makes the purpose clear and distinguishes it from webhook_register and webhook_unregister by emphasizing read-only scope and non-disclosure of secrets.

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 a prerequisite ('Requires your tenant') and a scoping rule ('only show your own webhooks'), but it does not explicitly mention when to use this tool over alternatives such as webhook_register or webhook_unregister. Usage context is implied rather than explicitly stated.

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

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

With no annotations, the description carries the full burden. It discloses an authorization constraint ('only the holder of the secret can remove it'), which is useful, but it does not mention permanence, idempotency, or error scenarios for a destructive 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 concise sentences, front-loaded with the action and containing no redundant filler. It earns every word.

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 unregister operation with two string parameters, the description covers the core behavior and prerequisites sufficiently, especially with an output schema present. Minor gaps around edge cases are acceptable.

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

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

The schema has no descriptions (0% coverage), but the description clarifies both parameters: 'id' is the webhook id from registration and 'secret' is the signing secret from registration, effectively explaining their origin and purpose.

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?

Description begins with a specific verb and resource ('Remove a webhook'), clearly distinguishing it from sibling tools like webhook_register (create) and webhook_status (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?

The description states that the id and signing secret must come from registration and that only the secret holder can remove, providing clear context for when to use this tool. It does not explicitly name alternatives but the conditionality is 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 burden of behavioral disclosure. It adds valuable context about authentication (bearer token or per-call payment), window bounds (default 24, max 168), and a 500,000 USD threshold. However, it does not explain the aggregation behavior, possible errors, or the meaning of the threshold as a fixed vs configurable value.

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 leads with payment information rather than the tool's purpose. It bundles disconnected facts (payment, output, window, threshold) without clear structure or front-loading, making it harder for an agent 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?

While an output schema exists, the description lacks crucial context such as the purpose of the threshold (is it a filter or a display threshold?), which chains are supported (left to the schema), and whether any rate limits or billing consequences apply. The payment model is disclosed but the overall usage context remains incomplete.

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%. The description explains 'window' semantics (hours, default 24, max 168) but mentions 'threshold 500000 USD' which is not a parameter in the schema, creating ambiguity. The 'chain' parameter is only described as 'per chain' with no additional detail beyond 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 mentions 'Large transfer counts and USD totals per chain', which indicates the tool reports whale flow activity, but it lacks an explicit verb like 'get' or 'list'. It does not clearly differentiate from sibling tools like 'deep_report' or 'situation_report'.

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

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

No guidance is provided on when to use this tool versus alternatives. The description focuses on payment requirements and parameter defaults, but does not mention use cases, exclusions, or related tools.

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