ChainRay

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that results carry trust scores and discloses a cost ($0.007), which is genuinely useful context, but omits pagination/result-size behavior beyond the schema's limit.

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

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

Three short sentences, front-loaded with the verb and resource; every clause carries information except the parenthetical cost, which is terse and arguably useful. No padding or repetition.

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

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

An output schema exists, so return structure need not be explained, and the description still summarizes the payload (agents with trust scores). All parameters are schema-documented, leaving only sibling differentiation and pagination as minor gaps for a read-only discovery 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 100%, so chain, limit, keyword and capability are already documented at the field level (including the capability enum list). The description only restates the filter dimensions and adds no format or syntax detail, matching the baseline-3 expectation.

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

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

States a specific verb (Discover) and resource (AI Agents) plus the three filter facets, and adds what is returned (matching agents with trust scores). However, it does not name or contrast the sibling agent.card.lookup, so the boundary between 'discover many' and 'lookup one' is left to inference.

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

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

'Useful for finding agents to collaborate with' gives an implied scenario but no explicit when-to-use versus agent.card.lookup or agent.reputation. No exclusions or alternatives are named, so routing depends on the agent's own reading of the sibling list.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely new context beyond the annotations: the returned fields and, importantly, the $0.002 cost of the call, which is not captured in any structured field.

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

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

Two tight sentences, front-loaded with the action and scope, followed by return contents and cost. No wasted words; every clause earns its place.

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

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

With an output schema documenting the return shape and annotations covering the safety profile, the description only needs to frame purpose, scope, and cost, which it does. Minor gap: no explicit distinction from agent.card.discover within the crowded agent.card.* family.

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

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

Schema description coverage is 100% for the single agentId parameter, so the schema carries the semantics. The description adds nothing about ID format or provenance (e.g., where agentId comes from), so the baseline 3 applies.

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

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

States a specific verb (look up) plus resource (AI Agent's card) and scope (by ID), and lists the returned content. It contrasts implicitly with agent.card.discover via 'specific ... by ID', but never names that sibling, so differentiation is inferential rather than explicit.

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

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

The phrase 'by ID' implies the usage context (fetch one known agent), but there is no explicit when-to-use, no when-not-to-use, and no routing to agent.card.discover for browsing. Usage is implied only.

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

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

Annotations declare mutation (readOnlyHint=false), non-idempotent, and open-world behavior. The description adds real context beyond that: the auto-attachment of a KYA trust score when paymentAddress is supplied, the returned registration status, and the $0.05 cost. It stops short of describing auth/ownership implications of updateToken.

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

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

Four tight sentences, front-loaded with the action and resource. Every sentence carries information (required inputs, KYA trigger, return, cost) with little waste.

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

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

For a registration mutation with an output schema present, the description covers required inputs, the notable side effect (KYA scoring), and the response. It does not address ownership/update semantics of updateToken, a minor gap given the schema documents it.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by naming the three required params and, importantly, explaining the behavioral consequence of paymentAddress (triggers KYA scoring) beyond the schema's own text.

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

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

States a specific verb+resource: 'Register an AI Agent in the ChainRay A2A Agent Card registry.' This clearly distinguishes it from siblings like agent.card.discover and agent.card.lookup (read operations). It does not explicitly name siblings, so it stops short of a 5.

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

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

The description explains what is required to register but gives no when-to-use guidance, no when-not conditions, and no alternatives among the sibling tools (e.g., when to register vs. look up an existing card). Usage is only implied by the tool name.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds real value beyond the schema by disclosing the ERC-8004 output composition and the $0.025 cost, but says nothing about latency, data freshness, or what an unknown address returns.

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 tight sentences, front-loaded with the core action and format, with the cost tacked on at the end. No filler, though the parenthetical schema enumeration is slightly dense.

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

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

An output schema exists, so return values need not be explained, and the low parameter complexity is well handled. The main gap is the missing routing signal against the agent.reputation sibling, which an agent would need to pick correctly between the two.

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

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

Schema coverage is 100% with only 2 parameters (address required, chain enum with default), so the schema already documents everything. The description adds no parameter-level meaning, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('Get agent reputation') plus the output format (ERC-8004 standard: Identity + Reputation + Validation Registry schema). The phrase 'same KYA analysis but formatted for on-chain registry compatibility' implicitly differentiates it from the agent.reputation sibling, though it never names that sibling explicitly.

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

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

The format contrast ('same KYA analysis but formatted for on-chain registry compatibility') implies when to pick this over the plain reputation tool, but no alternative is named and there is no explicit when-to-use/when-not guidance. Usage is left to inference.

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

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

Annotations already declare the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds useful context: the scoring inputs, the 0-100 trust score output, trust level, and ERC-8004 compatibility. It does not add auth/rate-limit or data-freshness details, keeping it short of a 5.

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

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

Purpose is front-loaded, followed by use case, then scope exclusions. The final negation sentence packs three exclusions but remains parseable. Slightly dense, though every clause carries routing 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?

With an output schema present, the description needn't explain return structure; it still mentions outputs briefly. Annotations cover safety, schema covers params, and the description covers purpose, inputs, and sibling disambiguation. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% and the chain enum with its default is fully documented in the schema, so the baseline is 3. The description adds no addressing or chain-selection nuance beyond what the structured fields already carry.

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

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

States a specific verb+resource ('KYA: 10-factor on-chain reputation scoring') and enumerates the exact factors evaluated. It explicitly names the siblings it is not (wallet.credit_score, agent.card.lookup), so an agent can distinguish it without opening any schema.

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

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

Gives an explicit trigger ('Use this before relying on another Agent') and negative routing with named alternatives ('It is not a wallet's financial activity score (wallet.credit_score), a registered identity card (agent.card.lookup)'). When-to-use and when-not-to-use are both spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds the ~2000-block lookback window and the entity-labeling behavior (CEX, DEX, bridges), which are useful traits beyond the annotations, but it omits pagination limits, result caps, and whether results are sorted or truncated.

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

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

Three short sentences, front-loaded with the core action and scope, then the labeling behavior, then the chain constraint. No filler or redundancy.

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

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

With an output schema present, return values need not be explained. The description covers scope, labeling, and chain restriction, which is sufficient for a read-only analysis tool, though a note on result limits or ordering would make it fully complete.

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

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

Schema description coverage is 100%, and the chain enum with its default is fully documented in the schema. The description adds no parameter-level detail beyond restating the EVM-only restriction, so the schema carries the burden and baseline 3 applies.

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

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

The description states a specific verb ('Show'), a precise resource ('addresses that interacted with a target'), and a bounded scope ('recent ~2000 blocks'). It also notes the labeling behavior and the EVM-only constraint, so an agent can distinguish it from generic label or portfolio tools, though it does not explicitly name a sibling alternative.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. 'EVM only' is a hard constraint rather than usage guidance, so the agent must infer the appropriate context from the tool name and description alone.

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

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

Annotations already declare readOnly=true, destructive=false, idempotent=true, and openWorld=true, so the safety profile is covered. The description adds meaningful behavioral context beyond that: this tool fans out across contract security, approval risk, and liquidation stress to produce a composite score, which tells the agent the call is heavier/aggregated rather than a single-dimension lookup.

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

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

Front-loaded with the core capability and tightly scoped, but the first sentence and the 'Scope:' sentence overlap ('combines contract security scan, token approval risks, and market liquidation stress' vs. 'combining contract, approval, and liquidation-risk signals'), so some content is restated rather than earned twice.

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 aggregating read tool with an output schema present, the description needn't explain return values, and it adequately covers scope, decision use-case, and sibling alternatives. It stops just short of 5 only because it doesn't note latency/cost implications of a multi-source composite call.

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

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

Schema description coverage is 100%, so both parameters (address, chain with its full enum list) are already fully documented in the schema. The description adds no format hints or constraints beyond 'one wallet or contract', which merely restates the address parameter. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

Starts with a specific verb+resource ('Get a unified risk assessment for any address') and enumerates the three constituent signals it composes. It explicitly distinguishes itself from security.contract.scan, token.approval, and wallet.credit_score, so an agent can route without opening any schema.

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

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

'Use this when the agent wants one prioritized address risk summary' states the selecting condition, and 'Use security.contract.scan, token.approval, or wallet.credit_score when it needs one focused dimension instead' names the alternatives and the condition that favors them. This is explicit when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is fully covered elsewhere. The description adds no behavioral context beyond that — no error behavior for unknown hashes, no rate/latency notes — and the field list it does give duplicates the 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?

A single front-loaded sentence with no filler; the verb and resource lead and the field list follows. Slightly compressed to the point of omitting usage context, but nothing is wasted.

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

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

With 100% schema coverage, an output schema, and annotations carrying the safety profile, the essentials are covered. However a decode tool with no note on invalid/missing hash handling or which chain defaults apply leaves small gaps an agent may need to discover at call time.

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

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

Schema description coverage is 100% with only two parameters, both documented in the schema (chain default: base, txHash). The description adds nothing about parameter semantics, so the baseline 3 for high coverage applies.

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

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

States a specific verb ('Decode') and resource ('a transaction') and enumerates the decoded fields, so the agent knows exactly what comes back. It does not differentiate itself from nearby read tools like chain.block or security.contract.events, but no sibling is a true duplicate.

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

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

There is no statement of when to reach for this tool versus alternatives, and no prerequisites or input-format guidance. The agent must infer usage purely from the name and one-line purpose.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint, so the safety profile is covered. The description adds the single-chain scope constraint, which is useful, but says nothing beyond that about behavior since an output schema documents the return shape. Adequate but not rich.

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

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

Front-loaded with the core action and the alternative-tool routing is at the end where it belongs. The field list ('gas, transactions, and timestamps') is stated twice across the first two sentences, which is a small redundancy.

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 covering return values and annotations covering the safety profile, the description only needs purpose and routing, both of which it supplies. The duplicated payload enumeration is the only slack.

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

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

Schema description coverage is 100% and both parameters document their defaults ('omit for latest', 'default: base'). The description repeats the field list rather than adding syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get latest or specific block data') and enumerates the payload (gas, transactions, timestamps). It names the sibling tools it is not (chain.health, oracle.chain_status), so an agent can distinguish it without opening schemas.

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

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

Explicitly states when to use it ('exact latest or historical block facts on one chain') and when not to ('Do not use it for an aggregate chain health view'), naming the two alternative tools by name. Routing is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine interpretive context beyond the annotations: inflow reads bullish, outflow reads bearish. It stops short of describing refresh cadence or how the directional signal is computed, so not 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?

Three tight sentences: purpose, interpretation, then routing. Front-loaded with the core action and zero filler or repetition of the title.

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

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

A read-only, single-parameter analytical query with an output schema that carries the return values, so the description need not explain response shape. Purpose, interpretation, and sibling routing are all present, leaving nothing an agent needs before calling it.

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

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

Schema coverage is 100% and the single chain parameter is fully documented with an enum and default, so the schema does the heavy lifting. The description adds no filtering syntax or format guidance beyond what the schema already provides, which is the correct baseline here.

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

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

States a specific verb (analyze) and resource (cross-chain bridge capital flow direction), and immediately distinguishes itself from the two nearest siblings by name. An agent can select it without opening any other schema.

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

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

Explicitly states when to use it ('directional net capital flow across bridges on one chain') and routes the agent elsewhere with conditions: chain.bridge.monitor for large transfer detection, chain.compare when choosing between chains. Both the usage condition and the exclusions are present.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful scope context (EVM-only, which bridge contracts are watched), but says nothing about what 'large' means operationally, whether results are pushed as alerts versus returned, or any cadence/rate 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?

Two compact sentences, front-loaded with the core detection purpose and immediately followed by the scope constraint. Zero filler or restated title text.

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

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

With an output schema present and 100% parameter description coverage, the definition needn't explain return values, and it correctly limits itself to purpose plus scope. The one remaining gap is sibling disambiguation from chain.bridge.flow, which would make routing unambiguous.

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

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

Schema description coverage is 100% for both parameters, including the chain enum list and the minAmount default/minimum, so the schema carries the parameter burden. The description's phrase 'large token transfers' loosely maps to minAmount but adds no threshold or format detail beyond what the schema already provides; baseline 3 applies.

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

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

States a specific verb ('Detect') and resource ('large token transfers involving known bridge contracts') and names concrete protocols (Across, Wormhole, official bridges), so the subject matter is unambiguous. It does not, however, distinguish itself from the very similar sibling chain.bridge.flow, leaving the agent to guess which bridge tool applies.

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 'EVM only' clause functions as an implicit exclusion (don't use for non-EVM chains), and the monitoring intent is implied by the tool name. But there is no explicit when-to-use guidance and no mention of the overlapping sibling chain.bridge.flow, which an agent would need in order to choose correctly.

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

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

Annotations already establish readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral framing by labeling itself a decision aid rather than a monitor or executor, which prevents misuse. It stops short of describing comparison recency or data-source freshness.

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

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

Three sentences, front-loaded with the comparison scope before the routing guidance. The middle sentence ('Use to compare a bounded set of EVM chains when selecting a network for an action') partially repeats the opening sentence's scope, a minor redundancy in an otherwise tight definition.

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

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

An output schema exists, so return-value detail is not owed here. Between the stated dimensions, the usage boundaries, and the named alternatives, an agent has everything needed to decide when and how to call 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?

With one parameter and 100% schema description coverage, the schema already documents the chain enum, the default set, and the maxItems cap. The description's only added signal is 'bounded set of EVM chains', which restates the maxItems constraint the schema already encodes. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('side-by-side comparison of EVM chains') and enumerates the compared dimensions (gas costs, block time, DeFi yields). It explicitly contrasts itself with chain.health, gas.tracker, and oracle.chain_status, so an agent can route without opening a sibling schema.

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

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

Gives an explicit when ('selecting a network for an action') and explicit when-not ('not an outage monitor or transaction executor'), naming three alternative tools for adjacent needs. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive, so the safety profile is covered. The description adds a useful behavioral detail — that it fans out across all supported EVM chains in parallel — but says nothing about rate limits, latency, or failure handling for a multi-chain fan-out.

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 tightly written sentences with the scope and outputs front-loaded and no filler; every clause earns its place.

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

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

With an output schema covering the return shape and annotations covering safety, the description is nearly complete for a single-parameter read tool. The remaining gap is routing guidance versus the many chain.* and wallet.* siblings, which the description omits.

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

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

Schema coverage is 100% and the single address parameter is fully documented in the schema, so the baseline of 3 applies. The description adds no format or validation detail (e.g., checksummed vs lowercase) beyond what the schema provides.

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

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

States a specific verb and resource ('Cross-chain wallet correlation') and enumerates the outputs (balance, nonce, activity, diversity score, classification), which is far more than a name restatement. It doesn't, however, differentiate itself from overlapping siblings like wallet.profile or chain.compare, so an agent can't fully disambiguate without opening schemas.

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

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

The description explains what the tool does but gives no when-to-use guidance, no prerequisites, and never names an alternative such as wallet.profile or chain.compare. Usage is only implied by the tool's scope.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: it clarifies the score's scope boundaries (not an audit, not a transaction guarantee) and what feeds it, which prevents misreadings. It stops short of detailing freshness, coverage latency, or scoring methodology, so it is not 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?

Three sentences with zero filler, front-loaded with the definition, then the use case, then the exclusions. Each sentence earns its place and the ordering follows the reader's decision path.

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

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

An output schema exists, so return-value detail is not needed. For a one-parameter, read-only aggregate the description supplies purpose, usage trigger, exclusions, and scope limits, leaving nothing an agent needs in order 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?

Schema description coverage is 100% with a single optional 'chain' parameter defaulting to base, so the schema carries the parameter documentation. The description's 'single-chain' framing implies exactly one chain is scoped, but it adds no syntax, default, or accepted-value detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific resource and scope: a 'chain health score' aggregating three named inputs (gas data, protocol TVL, stablecoin stability). It also distinguishes itself from siblings by explicitly excluding contract audits, transaction guarantees, risk analysis, and block facts, so an agent can route correctly without opening a schema.

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

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

Gives an explicit when-to-use ('single-chain operating snapshot before choosing where to act') plus when-not-to-use, naming concrete alternatives: security.contract.scan and token.risk for safety, chain.block for block facts. Both the trigger and the exclusions are spelled out.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral scope: the scan is limited to Aave V3 across supported chains and returns a ranking of supply APY vs borrow rates. It omits freshness/caching and rate-limit behavior, which keeps it short of a 5.

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

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

Three tight sentences with zero filler: capability first, then usage, then routing to alternatives. Every sentence earns its place and the scoping statement is front-loaded.

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

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

For a zero-parameter, read-only ranking tool with a declared output schema, the description covers what it does, its data source scope, and its sibling boundaries. Nothing needed to call 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. It correctly avoids inventing parameter guidance that does not exist.

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

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

States a specific verb+resource+scope: cross-chain yield ranking that scans Aave V3 for best supply APY and cheapest borrow rates. It explicitly distinguishes itself from defi.compare (chain-specific protocol comparison) and defi.yields (one protocol's rates), so an agent can route without opening any schema.

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

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

Gives an explicit when-to-use ('cross-chain ranking of configured DeFi lending opportunities') plus two named alternatives with the exact condition that selects each. Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description usefully narrows behavior to fixed protocol pairs per chain (only Aave V3 vs Compound V3 on the ~44 EVM chains, Kamino + staking on Solana), which is non-obvious context, but says nothing about data freshness or response shape.

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

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

Three short fragments, front-loaded with the core purpose, zero filler. The terse protocol/chain notation ('EVM: Aave V3 vs Compound V3 side-by-side') is efficient but slightly telegraphic.

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

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

With an output schema present, return values need no explanation, and the single enum parameter is fully documented in schema. The description supplies the missing scoping context (which protocols are compared on which chain family), leaving little an agent needs beyond whether it should prefer defi.yields instead.

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?

Single optional 'chain' parameter with 100% schema description coverage, so the schema fully documents the enum and default ('base'). The description's breakdown of what each chain family returns is protocol context rather than parameter semantics, so the baseline 3 applies.

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

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

Clear verb+resource: 'Compare DeFi lending rates across protocols', then names the concrete protocol pairs per ecosystem (Aave V3 vs Compound V3 on EVM, Kamino + staking yield on Solana). This is specific and distinguishes it from a generic yields tool, though it does not explicitly contrast itself with siblings like defi.yields or defi.aggregator that also deal with protocol rates.

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 — the tool exists to do side-by-side protocol rate comparison — but there is no explicit 'use this when... / instead of defi.yields' routing. With nine defi.* siblings, a sentence naming the alternative would materially help selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds the shape of the returned data (liquidity, fee tiers, tick), but says nothing about chain-dependent coverage, rate limits, or empty/missing-pool behavior beyond what annotations carry.

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

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

A single front-loaded sentence with no filler, and the resource is stated before the enumerated data fields. It is efficiently sized, though it leaves room for a routing sentence that would cost little.

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

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

For a one-parameter read-only tool with an output schema and full annotations, the description covers the essentials: what is fetched and what fields it contains. The main gap is disambiguation from defi.liquidity/defi.yields and the mismatch with the 'Yield Farming' title, which could misroute an agent expecting yield opportunities.

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

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

Schema description coverage is 100% and the single 'chain' parameter has a documented enum plus a default, so the schema does the heavy lifting; baseline 3 applies. The description contributes nothing about the chain parameter or the default of 'base', nor which chains actually have Uniswap V3 pools despite the 44-chain 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 gives a clear verb + resource ('Get Uniswap V3 LP pool statistics') and names the data scope (liquidity, fee tiers, current tick). It is specific enough to distinguish the resource from most siblings, but it never addresses the tension with its own name/title 'Yield Farming' nor differentiates itself from near-neighbors like defi.liquidity and defi.yields, which overlap heavily with 'LP pool statistics'.

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

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

No when-to-use guidance, no exclusions, and no mention of alternatives such as defi.liquidity or defi.yields that an agent would plausibly consider for the same question. The only usage signal is implied by the resource 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the tool is a composite/derived metric rather than raw data, the score range is 0-100, and the scope is single-chain. It does not mention latency, rate limits, or data freshness, which keeps it short of a 5.

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

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

Three sentences, each earning its place: definition and output, positive use case, then negative routing. The core capability is front-loaded and the sibling disambiguation is packed into one clause rather than padding.

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

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

With an output schema present, the return shape needn't be described, and annotations cover the safety profile. The description supplies the derived-metric framing, chain scope, and full routing context, leaving no gap an agent needs to call this correctly.

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

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

Schema description coverage is 100% and the single chain enum is fully enumerated with a description, so the schema carries the parameter burden; baseline 3 applies. The description only reinforces the single-chain scoping ('on one chain') and adds no format or default guidance beyond what the schema already states.

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

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

States a specific verb (assess) and resource (DeFi protocol health) and spells out exactly what the tool computes: a composite 0-100 score from TVL, utilization rates, and liquidation frequency. It explicitly contrasts itself with defi.aggregator, defi.compare, and token.risk, so an agent can distinguish it from siblings without opening any schema.

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

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

Provides both positive guidance ('use for protocol-level DeFi health and stress signals on one chain') and explicit exclusions ('does not rank yields or inspect a token contract'), each paired with the named alternative that covers that case. Nothing about routing is left to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description still adds meaningful scope constraints: Uniswap V3 only and EVM-only chains, which the agent cannot infer from annotations. It stops short of saying what happens when no pool exists for the pair or how the default chain is applied.

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

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

Three short sentences with no padding: the operation and return fields come first, the platform constraint second, and routing guidance last. Every sentence carries information the agent needs.

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

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

An output schema exists, so return values need no explanation, and the description covers scope, chain restriction, prerequisites, and sibling routing. It is slightly thin on edge behavior for unknown pairs or unsupported chains with no active pool, which is the remaining gap.

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

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

Schema description coverage is 100%, so the chain enum and both token address parameters are already documented in the schema. The description only restates what the schema supplies ('requires both token addresses', 'EVM only'), adding no format, ordering, or resolution details for symbols vs. addresses. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Read Uniswap V3 pool state') plus the exact payload (current price, active liquidity, fee tier), and scopes it with 'EVM only'. It also explicitly contrasts itself with defi.aggregator/defi.compare, so an agent can route without opening schemas.

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

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

Gives an explicit use condition ('Use when a known token pair needs pool-depth and active-liquidity context'), a prerequisite ('requires both token addresses'), and names the alternatives for what it is not ('does not rank lending yields; use defi.aggregator or defi.compare for rates').

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds only that the result blends yield discovery with gas timing — useful context but no detail on freshness of data, chain coverage, or how the two signals are combined.

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

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

A single front-loaded sentence with no filler or repetition. It is appropriately sized, though it could spend a few more words on the routing conditions that the sibling list makes 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, with ~70 sibling tools and several near-neighbours, the definition omits the routing guidance and scope detail an agent needs to pick it confidently.

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

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

Only one optional parameter (chain) with 100% schema description coverage ('EVM chain (default: base)'), so the schema already carries the semantics. The description adds nothing about supported chains or what happens when chain is omitted, which is exactly the baseline-3 situation.

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

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

States a specific verb ('Find') and a composite resource ('best DeFi yield opportunity combined with optimal gas timing'), which distinguishes it from single-purpose siblings like defi.yields or gas.optimize. The word 'best' is left undefined, so the exact optimisation criterion is not clear, but the tool's role as a yield+gas synthesiser is legible.

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 indication of when to prefer this over the many adjacent siblings (defi.yields, defi.farming, defi.compare, gas.optimize, gas.predict). An agent must guess whether this is an aggregate entry point or a narrow query. No prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds one genuinely useful behavioral detail beyond the annotations: that values are read directly from on-chain aToken and Comet supplies (i.e., live protocol state, not an aggregated/indexed source). It says nothing about refresh timing, rate limits, or how unsupported protocol positions are handled.

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

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

A single well-formed sentence with the action, scope, and data source front-loaded and no filler. It is efficient, though the parenthesis-heavy construction packs in detail that could be slightly tighter.

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 (one optional parameter) and has an output schema, so return-value documentation is not needed. The description covers what is computed, which protocols are supported, and where the data comes from. The main remaining gap is the absence of any routing guidance relative to its many defi.* siblings.

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

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

Schema description coverage is 100% and the single 'chain' parameter is fully enumerated with a default in the schema, so the baseline of 3 applies. The description adds no format or semantic detail beyond what the schema already provides.

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

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

States a specific verb ('Calculate'), a specific resource ('total value locked (TVL)'), and even names the protocols and data sources ('Aave V3, Compound V3... aToken and Comet supplies'). This is far more specific than a tautology. It stops short of distinguishing itself from defi.liquidity or defi.health, which could plausibly overlap.

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 never states when to use this tool versus alternatives such as defi.liquidity, defi.aggregator, or defi.health, and offers no exclusions or prerequisites. Usage is only implied by the nature of the calculation, leaving the agent to infer routing among eight defi.* siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description usefully adds the per-chain source breakdown (Aave on EVM vs Kamino plus staking on Solana), but discloses nothing about caching, freshness, rate limits, or empty-result behavior for an open-world live-data call.

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

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

Two sentences, front-loaded with the core action and then the per-chain source detail. Every clause carries information and nothing is wasted.

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

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

With an output schema present, return values need not be described, and annotations cover safety. The source/chain mapping is a nice completeness touch, but the absence of any routing guidance against the many sibling defi tools leaves a small gap.

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

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

Schema description coverage is 100% and the single chain parameter is fully enumerated with its default, so the schema carries all parameter meaning. The description mentions chain families (EVM vs Solana) but adds no syntax or usage detail beyond what the schema already provides, making 3 the correct baseline.

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

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

Specific verb+resource ('Get live DeFi lending rates') with named data sources (Aave V3 supply/borrow APY, Kamino KLend reserves, native staking yield), so the agent knows exactly what it returns. However, it offers no differentiation from close siblings such as defi.opportunity, defi.farming, or defi.liquidity, so an agent cannot tell them apart from the description alone.

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

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

There is no when-to-use, when-not-to-use, or alternative guidance. In a cluster of defi.* tools (opportunity, compare, farming, liquidity, health), the description never says when yields is the right pick versus those siblings.

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

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

Annotations already cover read-only/idempotent/open-world safety, so the description's added value is the data shape: a fixed 6-hour window with 36 samples, base fee per block on EVM, TPS samples on Solana. That is real behavioral context beyond the annotations, though it says nothing about pagination, staleness or latency.

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

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

Front-loads the core capability and window, then scope, then the use-case question, then exclusions. Every sentence earns its place with no filler.

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

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

With an output schema present, return values need not be explained; the description covers window, sampling density, per-chain semantics and sibling differentiation. Nothing needed to call 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 coverage is 100% and the enum description already enumerates chains, so the baseline is 3. The description earns a bump by explaining what the chain parameter actually yields per family (base fee per block for EVM, TPS samples for Solana), which the schema does 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?

States a specific verb and resource (get gas fee trend) plus scope (6-hour window, 36 sampled points) and chain-specific semantics for EVM vs Solana. An agent can immediately distinguish this from gas.tracker, gas.predict and gas.optimize.

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

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

Explicitly names the natural-language question it answers ('how have fees behaved recently?') and enumerates the three sibling tools it is NOT, with the role each plays (current quote, forecast, submission recommendation). Routing is unambiguous.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered structurally. The description adds real context beyond that: it is advisory/derived, based on 'current and recent fee conditions', and includes a savings estimate. It stops short of describing how the recommendation is derived or its confidence, which keeps it out of 5 territory.

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

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

Three tight sentences: purpose, scope, and disambiguation, front-loaded so the core purpose lands first. The negative enumeration is compact and each clause carries distinct routing value; 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 read-only advisory tool with an output schema (so return values need not be explained) and annotations covering the safety profile, the description supplies everything an agent needs: what it does, when to use it, and which siblings to prefer instead.

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

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

There is a single optional 'chain' parameter with 100% schema description coverage, so the schema fully documents it (including the base default). The description adds no meaning about the parameter, which is acceptable given full coverage — the baseline 3 applies.

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

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

The description states a specific resource and verb ('Gas price optimization advisor') plus the concrete action ('analyzes recent block patterns to recommend the best time to transact'). It explicitly names the sibling tools it is not (gas.tracker, gas.history, gas.predict), so an agent can distinguish it without opening any schema.

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

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

It gives an explicit trigger phrase ('Use this for "when should I submit?"') and enumerates the three sibling tools whose use cases it does NOT cover, with the reason for each (raw quote, history response, standalone forecast). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds real context beyond that: the analytical technique (moving average/trend of base fees), the short-horizon scope, and the explicit statement that it never executes a transaction. It doesn't mention accuracy caveats or refresh/cadence behavior, keeping it just short of a 5.

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

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

Front-loaded with purpose, method, and return shape, followed by scope and routing. Well structured and readable, though the "Scope: short-horizon fee forecast from recent samples" clause partially re-states the opening sentence, and the "Returns prediction, trend, and recommendation" line overlaps with the output schema.

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

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

For a single-optional-parameter, read-only forecast tool this is complete: only one input is fully documented in the schema, return values are covered by the output schema, and annotations handle the safety profile. The description's remaining job — routing and method disclosure — is done.

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 chain parameter has 100% schema description coverage with a fully enumerated list of supported chains, so the schema carries the semantics. The description adds no chain-specific guidance, so the baseline 3 applies.

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

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

States a specific verb and resource ("Predict near-future gas prices") plus the method used (moving average and trend analysis of recent block base fees). It explicitly names the siblings gas.tracker, gas.history, and gas.optimize and how this tool differs from each, so an agent can disambiguate without opening schemas.

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

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

Gives an explicit trigger phrase ("what may fees be soon?") and negative routing for each close alternative: not a live quote (gas.tracker), not historical data (gas.history), not timing advice (gas.optimize). When-to-use and when-not-to-use are both covered.

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

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

Annotations already declare readOnly=true, idempotent=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds genuine behavioral context beyond that by disclosing the shape of the returned data per chain family (base fee, priority fee, predictions for EVM; priority fees, TPS, congestion for Solana). It stops short of stating freshness/latency or rate-limit behavior, so it is not a full 5.

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

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

Four tight sentences, each earning its place: capability, per-chain payload, scope trigger, then exclusions. Front-loaded with the verb+resource and no redundant restatement of the title or schema.

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

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

An output schema exists, so return values need not be described, and the description instead supplies the routing context (scope plus the three sibling exclusions) an agent needs to call it correctly. Nothing material is missing for a single-parameter read tool.

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

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

Only one parameter (chain) and schema description coverage is 100%, with a fully enumerated set of values and a documented EVM/non-EVM split, so the schema carries the semantics. The description restates the EVM vs Solana distinction but adds no new per-parameter meaning, which is the baseline-3 case.

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

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

States a specific verb and resource (get current gas/fee data) and immediately scopes what the payload contains per ecosystem (EVM base/priority fee/predictions; Solana priority fees/TPS/congestion). It explicitly names the sibling tools it is not, so an agent can distinguish it from gas.history, gas.predict and gas.optimize without opening any schema.

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

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

Gives an explicit trigger phrase ("what are fees now?") and then enumerates the excluded use cases with their correct alternatives: historical series -> gas.history, short-horizon forecast -> gas.predict, timing advice -> gas.optimize. This is exactly the when/when-not/alternative structure that removes routing ambiguity.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description restates 'read-only' and adds the pool-scoping constraint, which is mildly useful, but discloses nothing beyond the annotations about return limits, pagination, or rate constraints. Baseline 3 given annotation coverage.

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

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

Three short sentences, front-loaded with the core action and scope. Minor redundancy between 'Get recent DEX swap trades' and 'Use for recent swaps,' but nothing wasted overall.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description covers what, when, and alternatives, leaving only minor gaps around result limits or time windows.

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

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

Schema description coverage is 100%, so both parameters (pool, chain) are already documented in the schema, including the chain default of base. The description adds no syntax or format detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb+resource ('Get recent DEX swap trades') scoped precisely to a Uniswap V3 pool. It explicitly distinguishes itself from market.overview and defi.liquidity, so an agent can differentiate it from siblings without reading the schema.

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

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

Gives an explicit when-to-use condition ('recent swaps in a known Uniswap V3 pool') and names two alternative tools with the different purposes they serve. Routing is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorldHint, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond them: the tool returns an explicit unavailable result when the chain has no configured factory, which tells the agent how to interpret a non-data response. Rate limits, pagination, and result caps are still unstated.

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

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

Two sentences, no filler, and the core capability is front-loaded ahead of the edge-case degradation note. Everything stated earns its place.

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

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

An output schema exists, so return shape need not be explained, and the failure mode on unconfigured chains is covered. The only real gap is routing guidance against the many market.* and token.* siblings, which the description leaves entirely to inference.

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

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

Schema description coverage is 100%, with chain enum values, the hours 1-168 range, and withRisk all documented in the schema itself. The description only alludes to 'the selected chain' and 'token metadata', adding no syntax or meaning beyond what the schema already provides. Baseline 3 applies.

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

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

States a specific verb and resource: discovering recently created Uniswap V3 pools plus token metadata inspection. That is far more precise than the title 'New Pair Discovery'. It does not, however, contrast itself with nearby siblings like market.dex_trades, market.overview, or token.trending, so an agent must still infer the boundary.

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

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

There is no when-to-use guidance, no exclusions, and no named alternative. 'Recently created' hints at the lookback intent, but the agent is never told when this tool beats market.dex_trades or defi.liquidity for the same question.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive). The description adds useful context beyond them: it is a 'fixed' snapshot delivered 'in one call', implying no customization and a single aggregated fetch. It does not discuss freshness or rate limits, so not a full 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?

Three sentences, front-loaded with the payload contents, then usage, then exclusions. Every sentence carries distinct information with no waste.

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

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

With an output schema present, the description need not explain return values, and annotations carry the safety profile. The description supplies scope, contents, and sibling routing, so an agent has everything needed to select and 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?

The tool takes zero parameters, so the baseline is 4. The description's 'fixed broad snapshot' reinforces that there is nothing to configure, consistent with the empty schema.

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

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

States a specific verb ('Get') and resource ('cross-chain market snapshot') and enumerates the exact contents (ETH price, gas costs, DeFi TVL) and the four chains covered. It is immediately distinguishable from siblings like token.price or gas.tracker.

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

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

Explicitly says when to use it ('fixed broad snapshot of major market, gas, and TVL signals') and when not to, naming three concrete alternatives (chain.health, token.price, chain.compare) with the question each answers. Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the safe-read profile is covered. The description adds useful context beyond that: it does not execute the intent, it is not a guaranteed quote, both chains must be supported EVM chains, and there is a $0.007 cost. That is meaningful behavioral disclosure, though nothing about rate limits or freshness of the analysis.

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

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

Purpose is front-loaded in the first sentence, followed by placement guidance and caveats; the $0.007 cost is tucked in without disrupting flow. Three sentences, little waste, though the enumeration of dimensions is repeated between the first and second 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?

An output schema exists, so return-shape explanation is unnecessary, and annotations carry the safety profile. For a read-only analysis tool with 100% schema coverage, the description supplies enough scope, caveats, and cost context. It could say a bit more about what 'supported EVM chains' excludes, but overall it 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?

Schema description coverage is 100% and two params carry enums, so the schema fully documents fromChain, toChain, tokenIn, tokenOut, and amountUsd. The description adds no syntax or format detail beyond that. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific domain (ERC-7683 cross-chain intent execution) and enumerates the outputs it produces — profitability analysis, gas costs, competition level, recommendations — so the agent knows exactly what it returns. The negative scope ('does not execute the intent') further bounds it. It does not explicitly name a sibling like util.intent_router, so sibling differentiation is implied rather than stated.

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

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

Gives a clear placement in a workflow ('Use before evaluating an ERC-7683 cross-chain intent') and lists the comparison dimensions. It also warns against misinterpreting the output as a guaranteed quote. No alternative tool is named for when this isn't the right choice, so it stops short of full when/when-not guidance.

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

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

Annotations already cover readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful context beyond annotations by naming the data source (on-chain DEX pool data), the monitored assets, and the $1.00 peg threshold.

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 tightly written sentences with no filler. The core purpose and the detected deviation scope are 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?

With a rich output schema, complete parameter documentation, and annotations covering safety semantics, the description provides everything needed for correct invocation. The agent need not rely on the description for return formats or chain enumeration.

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

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

Schema description coverage is 100% and the single chain parameter is fully documented in the schema, so the baseline is 3. The description does not add parameter-level meaning beyond the schema.

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

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

States a specific verb and resource: monitor stablecoin peg stability. It further narrows scope to USDC/USDT/DAI deviations from $1.00 using on-chain DEX pool data, which distinguishes it from sibling market.stablecoin.supply.

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 monitoring purpose implies a use case, but there is no explicit when-to-use guidance, no conditions or exclusions, and no mention of the sibling market.stablecoin.supply alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds the asset scope and multi-chain aggregation semantics but says nothing about refresh cadence, caching, or how the cross-chain totals are composed.

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 short sentence, front-loaded with verb and resource, zero filler. Nothing could be removed without losing meaning.

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

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

An output schema exists, so return values need not be explained, and annotations plus the schema cover the remaining structured fields. The only meaningful gap is routing guidance against market.stablecoin.monitor and other market.* siblings.

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

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

Schema description coverage is 100% and the single chain parameter is documented as 'Specific chain or omit for multi-chain'. The description's 'across chains' phrase echoes that behavior but adds no format, enum, or default detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (Get) and resource (stablecoin total supply) with the exact assets covered (USDC/USDT/DAI) and cross-chain scope. An agent can distinguish it from token.supply (generic token) and from the similarly named market.stablecoin.monitor, though the latter distinction is left implicit.

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

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

No statement of when to use this versus alternatives, and the sibling market.stablecoin.monitor is not addressed despite the near-identical naming. Usage is only inferable from the name and asset list.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that it targets Aave V3 specifically and reports premiums, but says nothing about the lookback window implied by 'recent', rate limits, or data freshness.

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

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

Two tight sentences, no filler, with the protocol scope front-loaded ahead of what the tool returns.

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

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

An output schema exists so return values need no explanation, and the tool is a one-parameter read. The only real gap is that 'recent' is undefined, so an agent cannot tell whether extra time-window arguments are 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 100% and the single 'chain' parameter is fully enumerated with a default, so the schema carries the meaning. The description adds no chain-selection guidance, leaving this at the baseline for a fully documented 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?

States a specific verb and resource ('Monitor flash loan activity on Aave V3') plus the concrete outputs it detects (amounts and premiums paid), which separates it from generic monitor.* siblings like monitor.liquidation and monitor.whale.alerts. It does not name those alternatives, so it is clear but not maximally differentiated.

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 reach for this tool versus monitor.liquidation, security.mev.detect, or defi.* siblings, and no exclusions or prerequisites. Usage must be inferred from the word 'Monitor' alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds interpretive context (high counts = stress/cascading risk) but no behavioral specifics such as polling cadence, time window of returned events, or rate limits, so it adds only modest 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?

Two tight sentences with the verb+resource front-loaded and no filler. The second sentence is slightly tangential interpretation rather than operational detail, keeping it just short of a 5.

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

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

An output schema exists so return values need not be explained, and the single param is fully documented. However, for a monitoring tool the description omits the observation window (real-time vs historical), event volume, and threshold semantics, which an agent needs to interpret results 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 single 'chain' parameter has 100% schema description coverage including the full enum and a documented default of 'base', so the schema does the heavy lifting. The description adds nothing about chain selection or default behavior, making baseline 3 appropriate.

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

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

States a specific verb and resource (monitor DeFi liquidation events) plus a protocol scope (Aave V3), which an agent can act on. It does not explicitly distinguish itself from siblings like monitor.flashloan or monitor.whale.alerts, but the liquidation/Aave focus is distinct enough to route correctly.

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

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

No when-to-use vs when-not-to-use guidance and no named alternatives among the many monitor.* siblings. The market-stress interpretation hints at intent but never states a condition for selecting this tool over defi.health or analyze.risk_dashboard.

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 cover the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), so the description's added value is the stateful disclosure: the returned watchId only works within the same MCP session. That is a genuinely useful behavioral trait not derivable from the schema. It stops short of saying what happens to the watch if the session ends or whether repeated calls for the same address dedupe.

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

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

Front-loaded with the operation and its return value, followed by workflow routing. Mild redundancy between "Returns a wallet snapshot and watchId" and "Save the returned watchId," but each sentence carries a distinct instruction.

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

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

With an output schema present, return values need not be explained, and the description still flags the two key outputs. For a 2-param, non-destructive-but-stateful tool it covers what an agent needs; only edge cases (session expiry, duplicate watches) go 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 100% — the chain enum with defaults and the address format (EVM 0x... or Solana base58) are already fully documented in the schema. The description adds no parameter-level semantics beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ("Create a watch on an address") and immediately names its counterpart monitor.watch.diff, so the agent can distinguish the stateful setup tool from the diff tool without opening either schema. Also names the concrete artifact produced (wallet snapshot + watchId).

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

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

Explicitly says when to use it ("create the first address snapshot in a stateful watch workflow") and what to do next with the alternative ("call monitor.watch.diff in the same MCP session for later changes"). The sequencing and the session constraint are both spelled out rather than left to inference.

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

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

The description explains the non-idempotent state mutation that the annotations only flag abstractly: it 'advances the snapshot' and is tied to a watchId created in the same MCP session. This reconciles well with readOnlyHint=false and idempotentHint=false, since the operation mutates internal state despite reading like a diff. It does not cover edge behavior such as expired/invalid watchIds or rate limits.

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

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

Three short sentences with the core behavior front-loaded and the prerequisite immediately after. The 'changes since the last check' idea is stated twice (opening sentence and second-to-last clause), a minor redundancy.

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

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

Covers purpose, prerequisite, session scoping, and state-advancement behavior, and an output schema exists so return-value detail is not required. Remaining gaps (error handling for a stale or foreign-session watchId) are minor for a single-parameter 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?

There is a single parameter with 100% schema description coverage, and the schema already states it is the watch ID from a previous watch-address call. The description's mention of the watchId origin duplicates that, adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Get changes since the last check for a watched address,' plus the return content (changed fields and numeric deltas). It clearly differentiates itself from its sibling monitor.watch.address by describing what happens after a watch exists.

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

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

Explicitly states the prerequisite ('Use only after monitor.watch.address has created a watchId in the same MCP session') and the exclusion ('create a new watch for a new address'). An agent knows exactly when this tool is valid versus when to create a new watch.

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

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

Annotations already disclose readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety and idempotence are covered. The description adds that results are threshold-filtered and time-bound, which is useful, but does not explain rate limits, latency, pagination, or what 'recent' means operationally.

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, no filler, and the supported-chains caveat is front-loaded. Could be tightened further but nothing is wasted.

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

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

Given an output schema exists, return-format explanation is not needed, and annotations carry the safety profile. The description is adequate but leaves the sibling disambiguation unresolved, which for a crowded monitor.* namespace is a meaningful gap.

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

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

Schema description coverage is 100%, so every parameter including the 47-value enum is documented there. The description names supported asset classes (USDC, WETH, SOL) which adds marginal context, but relies on the schema for parameter meaning – appropriate baseline of 3.

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

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

The description states a specific verb (monitor), resource (large token transfers / whale movements), and scope (EVM & Solana chains). This distinguishes it clearly from siblings like monitor.whale.tracker and predict.whale_move, though it names neither directly.

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

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

No guidance is given about when this tool should be used versus the closely-named sibling monitor.whale.tracker or predict.whale_move, nor about prerequisites. The agent must infer that this monitors *current/recent* movements while 'predict' forecasts them.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds only the return content (labels + profile); it does not clarify whether 'Track' means a one-shot snapshot or a persistent subscription (the name and verb otherwise suggest ongoing monitoring), nor does it mention rate limits or auth. Useful but thin beyond the annotations.

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

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

A single front-loaded sentence with no filler, and the resource and return payload come first. It is arguably too terse for a tool with four close siblings, but there is no wasted verbiage.

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

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

With an output schema present, the description need not explain return values, and the input schema fully documents both params. The remaining gap is routing context: nothing explains how this differs from monitor.whale.alerts / monitor.watch.address, which is the main thing an agent needs to pick correctly.

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

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

Schema description coverage is 100% for both parameters, including the chain default of 'base', so the schema already carries the parameter burden and baseline 3 applies. The description adds no format hints (e.g., address casing/checksum, supported chains) beyond what the schema states.

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

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

States a specific verb (Track) plus resource (a specific whale address) and names the payload (Address Intelligence labels and wallet profile), so the agent knows what it gets back. It does not, however, distinguish itself from near-identical siblings such as monitor.whale.alerts, monitor.watch.address, or wallet.profile, which a reader would have to disambiguate from the name alone.

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

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

There is no statement of when to use this tool versus monitor.whale.alerts, monitor.watch.address, or wallet.profile, and no exclusions or prerequisites. The only implied usage is the word 'specific', which is too weak to route an agent among the several overlapping whale/wallet 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds the meaningful applicability constraint that only EVM chains and ERC-721/1155 contracts are supported. It says nothing about failure modes for unsupported contracts/chains, so a 3 is appropriate.

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

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

Two short clauses with zero filler: the resource/fields first, the platform constraint second. Nothing could be removed without losing information.

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

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

With an output schema present, return-value detail is already handled, and annotations cover the safety profile, so the description only needs to scope the tool. It does that via the field list and EVM/ERC-721/1155 constraint. A brief note on behavior for unsupported chains or missing contracts would close the remaining gap.

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

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

Schema description coverage is 100% with only 2 parameters, so both `chain` (with its large enum and default of base) and `contract` are already documented in the schema. The description's 'EVM chains only' statement reinforces the chain constraint but adds no syntax, format, or address-validation detail beyond the schema.

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

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

States a specific verb and resource ('Get NFT collection info') and enumerates the returned fields (name, symbol, total supply, owner count), which implicitly separates it from nft.holders, nft.floor, and nft.metadata. It never names a sibling explicitly, so the differentiation is inferred rather than stated.

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

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

There is no when-to-use guidance, no exclusions, and no routing to alternatives such as nft.floor or nft.metadata when the agent wants pricing or token-level data. The EVM/ERC-721/1155 note is a scope 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful behavioral context by naming the data source (on-chain ERC721 events) and the derived metrics, but says nothing about rate limits, freshness, or failure modes; with annotations doing the heavy lifting a 3 is appropriate.

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

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

A single front-loaded sentence with the verb and resource first, followed by the analyzed signals. No filler, though the colon-list format is dense and could be split for 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?

The tool is low-complexity (2 params, 100% schema coverage, output schema present, rich annotations), so the description does not need to explain return values. What it states is accurate and sufficient; only the missing sibling/usage orientation keeps it from a 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?

Schema description coverage is 100%: the address param is described and the chain param carries a full enum plus supported-chain list and a default of "base". The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ("Analyze") and resource ("NFT collection activity"), then enumerates the concrete outputs: recent transfers, mints, burns, unique buyers, activity level, sourced from on-chain ERC721 events. It is clear what the tool returns, but it does not distinguish itself from nearby siblings nft.collection, nft.holders, or nft.metadata, and the name nft.floor vs. the title/description (activity, not floor price) creates mild ambiguity.

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

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

The description gives no when-to-use guidance, no prerequisites, and never names an alternative among the NFT siblings (nft.collection, nft.holders, nft.metadata). An agent must infer usage purely from the purpose statement.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds a genuinely useful behavioral trait beyond that: holders are derived from scanning recent Transfer events, implying the snapshot may exclude older holdings. It stops short of mentioning chain coverage or data-window limits explicitly.

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

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

A single front-loaded sentence that states the action, the object of analysis, and the data source with zero filler.

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

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

An output schema exists, so return-value explanation is unnecessary, and annotations cover safety. However, for a tool whose results depend on a 'recent' event window, the description leaves the scope of that window and per-chain support unstated, and offers no usage routing.

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

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

Schema description coverage is 100%, documenting both chain (default base) and contract. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (Analyze), resource (NFT holder distribution), and mechanism (scanning recent Transfer events). This is clearly distinguishable from siblings like nft.floor or nft.metadata, though it does not explicitly contrast with the closely related token.holders.

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 on when to use this versus alternatives like token.holders or nft.collection, and no exclusions or prerequisites. The agent must infer usage context entirely from the purpose statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description still adds real behavioral context beyond that: it resolves IPFS URIs and restricts lookups to EVM chains, which tells the agent something the annotations do not. It lacks failure-mode detail (missing/burned tokens, off-chain metadata 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?

Three short sentences, front-loaded with the action and returned fields, followed by the IPFS behavior and the chain restriction. Every clause carries information 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?

An output schema exists, so return values need no explanation, and the annotations plus full param coverage mean the description only needs to add scope and behavior. It largely does, though it omits what happens for non-existent tokens or unresolvable metadata, which would matter for an agent handling failures.

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 100% schema description coverage across all three parameters, the schema already documents contract, tokenId and chain (including the full chain enum and default). The description adds no parameter-level syntax, format, or address-normalization detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get individual NFT token metadata') and enumerates the returned fields (owner, tokenURI, image, attributes), which implicitly separates it from the collection-level siblings nft.collection and nft.holders. It stops short of explicitly naming those siblings as alternatives, so an agent must infer the boundary.

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

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

Usage is implied by 'individual NFT token' versus collection-level siblings, and 'EVM chains only' sets a scope constraint, but there is no explicit when-to-use, when-not-to-use, or named alternative. No prerequisite guidance (e.g., needing a contract address for a deployed ERC-721/1155) 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: real-time data, block freshness, and the specific failure modes it detects (outages, stale blocks, RPC degradation).

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

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

Two tight sentences with zero filler, and the core purpose (real-time chain health/freshness) is front-loaded ahead of the detection detail. Every clause carries information.

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

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

With a present output schema, rich annotations, and zero params, the description needn't explain returns or arguments, and it covers what it monitors and why. The one omission is sibling differentiation from chain.health, which leaves a small ambiguity for tool selection.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. No parameter-level detail is expected or missing.

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

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

States a specific resource and scope — real-time health and block freshness across configured EVM chains — with concrete detection targets (outages, stale blocks, RPC degradation). It is clear what the tool does, but it never distinguishes itself from the near-twin sibling chain.health, so an agent cannot tell them apart on the description alone.

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

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

"before agents submit transactions" gives clear preflight context for when to call it, which is more than implied usage. However, it names no alternatives or exclusions, so the overlap with chain.health is left unresolved.

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

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

Annotations already declare this is a read-only, idempotent, non-destructive, open-world call, so the safety profile is covered. The description adds that results include a cheapest-chain recommendation, which is useful output context, but discloses nothing about rate limits, defaults beyond the schema, or freshness of prices.

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

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

Three short sentences with the core capability front-loaded and no filler. Slightly tight on elaboration, but every sentence carries information.

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

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

An output schema exists, so return-value structure need not be restated, and annotations cover the interaction safety profile. For a single-parameter read-only oracle the description is essentially complete; only the sibling-differentiation gap is notable.

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

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

Schema description coverage is 100% and the single 'chains' parameter is fully documented in the schema (comma-separated names, defaults to top 5 EVM). The description adds no parameter-level detail, so the baseline 3 applies.

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

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

Names a specific verb and resource (multi-chain gas price aggregation) and states what is returned (gas prices plus a cheapest-chain recommendation). However, it does not distinguish itself from the many gas-related siblings (gas.tracker, gas.history, gas.optimize, gas.predict), so an agent still has to infer which gas tool is right.

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 'Ideal for agents choosing settlement chains' implies a usage scenario, which is more than nothing. But there is no explicit when-to-use/when-not guidance and no named alternative among the gas.* or predict.gas siblings, leaving selection ambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description mentions returning price, source, and confidence, which overlaps with the output schema's job. It does not disclose rate limits, freshness/staleness, or what 'verified' guarantees beyond an annotation-level claim.

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

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

A single dense sentence with no waste, and the core purpose is front-loaded. It is appropriately sized for a two-parameter read tool.

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

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

The tool has full annotations and a full output schema, so the description needn't explain returns or safety. However, given a rich sibling set including token.price and oracle.chain_status, the description should clarify how it differs and when to prefer it, which it fails to do.

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

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

Schema description coverage is 100%, so both the chain enum and token format are already fully documented in the schema. The description adds no syntax or format detail beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

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 (token price feed) and labels it a 'Data Oracle' with verified prices, which is clear enough as a purpose. However, it does not differentiate from the obvious sibling token.price, nor does it explain what 'Chain Proof signature' adds. The purpose is understandable but sibling differentiation is absent.

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 positions it as a 'lightweight alternative to Chainlink', which implies a comparison, but gives no when-to-use guidance relative to the sibling token.price or oracle.chain_status. There are no explicit conditions or exclusions for selecting 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully carried by structured data. The description adds some genuine value by disclosing the method (EMA) and its dependence on 'accumulated readings', but says nothing about prediction reliability, required history depth, or whether it fails when no readings exist.

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

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

A single sentence with no waste, front-loading the core identity ('Gas price prediction') before the qualifying detail. Every clause earns its place: method, horizons, and data dependence.

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

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

An output schema exists, so return values need no explanation, and the safety profile is covered by annotations. The description is nearly complete for a one-parameter prediction tool; the only real gap is whether accumulated readings must already exist before calling, which affects whether the tool can be used cold.

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

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

Only one parameter and schema description coverage is 100%, with the full enum of supported EVM chains already documented in the schema, including the EVM-only constraint and the 'base' default. The description contributes nothing about the chain parameter, so the baseline 3 is appropriate.

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

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

States a specific verb (prediction/forecast) and resource (gas price) plus concrete horizons (next 5 minutes and 1 hour) and method (EMA). This clearly separates it from a current-price tool like gas.tracker or gas.history, but it never explicitly names which sibling it replaces or overlaps with.

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

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

There is no when-to-use guidance and no named alternatives (gas.tracker, gas.optimize, gas.history, oracle.gas_avg all sit adjacent). An agent must infer from the word 'forecast' that this is the forward-looking gas tool, which is left entirely to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds the output content (health scoring, risk factors, 24h range), but with an output schema present that is partly redundant. No mention of data latency, prediction horizon beyond '24-hour range', or limitations.

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

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

A single, front-loaded sentence that leads with the operation and follows with the deliverables. No filler or repetition. It is efficient, though the compressed list of outputs is only lightly structured.

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

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

With an output schema and full annotations, the definition is functional for a read-only prediction tool. Still, it omits the prediction horizon/inputs and gives no routing versus the many overlapping defi.* and predict.* siblings, leaving a gap for a tool in a dense namespace.

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

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

Only one optional parameter (chain), and schema description coverage is 100% with a full enum list and default. The description adds no additional parameter meaning, so the baseline 3 is appropriate.

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

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

The description gives a specific verb+resource (liquidity prediction) and enumerates the concrete outputs: TVL trend analysis, health scoring, risk factors, and a 24-hour range. This is clearer than a tautology and tells the agent what it gets back. However, it does not distinguish itself from siblings like defi.liquidity, defi.tvl, or chain.health, which appear to overlap.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative routing. With siblings such as defi.liquidity, defi.tvl, and defi.health, the agent is left to infer why it would pick predict.liquidity over those. Only implicit usage is conveyed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the result is a discrete BUY/SELL/HOLD classification derived from price and trending data, which is useful, but it says nothing about data freshness, confidence, signal thresholds, or rate limits. With annotations carrying the safety burden, a 3 is appropriate.

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

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

A single, front-loaded sentence with zero filler. It is tightly sized, though the extreme brevity is part of why usage and behavioral context are thin rather than a structural flaw in itself.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a prediction tool sitting among several closely related predict.* and token.* siblings, the definition omits the basis of the signal and any guidance that would let an agent distinguish it from token.sentiment or token.trending.