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 read-only, idempotent, non-destructive, open-world behavior. The description adds the scope of what is evaluated and the important caveat that results are 'evidence-based scoring, not identity verification', which meaningfully shapes interpretation. The return shape is also noted, though an output schema exists.

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

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

Front-loads the KYA purpose, then evaluation factors, then outputs, then usage and caveat, in tight sentences with 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 rich annotations and an output schema present, the description supplies the remaining context an agent needs: what it measures, what it returns, and how it differs from identity verification. 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 description coverage is 100%, so the schema already documents both parameters, including the full chain enum. The description adds no parameter syntax or format detail beyond the schema, 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+resource ('on-chain reputation scoring') and enumerates the evaluation factors (transaction volume, balances, token diversity, DeFi interactions, cross-chain intel, risk flags). It also distinguishes itself from sibling agent.card.lookup by clarifying it is evidence-based scoring rather than identity verification.

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

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

Explicitly states when to use it ('to assess an agent or wallet's on-chain trust signals before collaboration') and names the alternative for a different purpose ('use agent.card.lookup for the registered card'). The when-to-use and sibling routing 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 readOnly, idempotent, non-destructive, and openWorld behavior, so the safety profile is covered. The description adds meaningful context beyond this: it discloses that results are a composite aggregation of three distinct risk dimensions into a single score, which tells the agent the shape and derivation of the output. It stops short of disclosing latency, rate limits, or partial-failure behavior, 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 tight sentences with zero filler: the capability and its components are front-loaded, followed by usage and then the exclusion. Every sentence earns its place.

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

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

With a fully covered schema, full annotations, and an output schema that handles return values, the description supplies everything an agent needs: what it does, what it aggregates, when to choose it, and when to prefer siblings. No material gap remains.

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) are fully documented in the schema, including the lengthy chain enum and default. The description only implicitly references the address parameter ('for any address') and says nothing about the chain dimension, so it does not materially add 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 verb and resource ('Get a unified risk assessment for any address') and immediately enumerates the three signals it fuses (contract security scan, token approval risks, market liquidation stress). This distinguishes it from security.contract.scan, token.approval, and wallet.report without needing to open 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?

Explicitly names when to use it ('combined address risk view spanning contract, approval, and liquidation signals') and when not to, routing the agent to 'the focused security or wallet tools' for single-dimension inspection. Both the positive and negative conditions are stated.

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

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

Annotations already fully cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds the single-chain vs aggregate scoping distinction, which is modestly useful behavioral context, but says nothing about return shape, pagination, or failure behavior. With rich annotations carrying the 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?

Front-loaded and readable, but the field list 'including gas, transactions, and timestamps' is stated twice in consecutive sentences, so the description is more redundant than necessary. The second sentence largely restates the first plus routing.

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 purpose, usage, and alternatives are all present. The remaining gap is the redundant phrasing rather than missing information, so it is nearly complete for a 2-param read tool.

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

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

Schema description coverage is 100% and both parameters (block, chain) are already documented with pattern and default. The description mentions 'block number' but adds 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 latest or specific block data') plus the fields returned (gas, transactions, timestamps), and explicitly separates itself from chain.health and oracle.chain_status. 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?

Explicitly says when to use it ('exact latest or historical block facts on one chain') and when not ('Do not use it for an aggregate chain health view'), routing to named alternatives. 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, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context by explaining how to interpret results (inflow = bullish, outflow = bearish), which annotations cannot convey. It omits freshness/lag or rate-limit behavior, so it falls 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?

Four short sentences, front-loaded with the core purpose and followed by interpretation, usage and alternatives. The bullish/bearish parenthetical is useful rather than wasteful, but the routing sentence is slightly dense and could be trimmed.

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 structure; combined with rich annotations and a fully documented single parameter, everything an agent needs to call and interpret this tool correctly is present.

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 sole 'chain' parameter has an enum, a default, and a description enumerating supported chains. The description only implies the 'one chain' scope and adds no syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb (Analyze) and resource (cross-chain bridge capital flow direction) with explicit interpretation of the output as bullish inflow vs bearish outflow. It names an alternative tool (chain.bridge.monitor) so an agent can distinguish it from adjacent bridge functionality 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 the use case (directional net capital flow across bridges on one chain) and routes two alternatives: chain.bridge.monitor for large-transfer detection and chain.compare for chain selection. Conditions for choosing this tool over siblings are 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 safety is covered. The description adds genuine scope framing beyond them — it is a decision aid, not an outage monitor or executor, and operates on a bounded set of chains. It omits any rate-limit or data-freshness note, so it falls short of a 5.

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

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

Front-loaded with purpose, then routing guidance, then explicit exclusions; every sentence carries routing value. 'Helps choose the optimal chain for transactions' is mildly redundant with 'when selecting a network for an action', keeping it from a perfect score.

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

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

An output schema exists, so return values need no explanation, and annotations carry the safety profile. Purpose, usage, and disambiguation against oracle.chain_status and gas.tracker are all present — nothing needed 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 coverage is 100% and the single 'chains' parameter is fully documented in the schema with the enum list and maxItems. The description only restates the 'bounded set' constraint, adding little syntax or 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 (compare) and resource (EVM chains), and enumerates the compared dimensions (gas costs, block time, best DeFi yields). An agent can distinguish this from siblings like chain.health or gas.tracker 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?

Explicitly says when to use it ('compare a bounded set of EVM chains when selecting a network for an action') and when not to ('not an outage monitor or transaction executor'), naming the correct alternatives (oracle.chain_status for availability, gas.tracker for a live quote).

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 genuine non-obvious scope: it only scans Aave V3 across chains, which constrains what 'yield ranking' means. It stops short of disclosing freshness, caching, or rate-limit behavior.

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

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

Three tight sentences, front-loaded with the core action, followed by usage and alternative routing. 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 no explanation, and zero params mean no schema gaps. The description covers purpose, scope, and routing, though references to defi.yields/defi.compare do not match the provided sibling list, leaving a small ambiguity about downstream navigation.

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

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

Zero parameters, so there is nothing to document and the baseline is 4. The description adds no parameter detail, but none is needed given the empty input schema.

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

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

States a specific verb and resource: a cross-chain DeFi yield ranking that scans Aave V3 for best supply APY and cheapest borrow rates. It even names the sibling tools (defi.yields, defi.compare) it should be distinguished from, 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?

Explicitly states when to use it (cross-chain ranking of configured DeFi lending opportunities) and when not to, routing to defi.yields or defi.compare for chain-specific protocol comparisons. Both the positive condition and the exclusion 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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds the meaningful scope constraint that the assessment is single-chain and describes what the score is composed of, though it says nothing about latency, data freshness, or failure modes for unsupported chains.

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

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

Two sentences, zero filler. The definition of the score is front-loaded and the sibling routing follows immediately, so the agent gets scope and disambiguation in one pass.

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 explained, and the single enumerated parameter is fully documented in the schema. What remains for the description – what the score means, its scope, and how it differs from neighboring tools – is all present.

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 single 'chain' parameter already enumerates all 44 supported chains and documents its default. The description only obliquely reinforces this via 'on one chain', 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 ('Assess DeFi protocol health') and immediately defines the composite metric as TVL + utilization + liquidation frequency scored 0-100. It also names the sibling tools it is not (defi.yields, defi.compare, token.risk), so an agent can discriminate 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 explicit when-to-use ('protocol-level DeFi health and stress signals on one chain') and explicit when-not-to-use, routing yield ranking and contract inspection to defi.yields, defi.compare, and token.risk. Both the positive trigger and the alternative set are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description's added constraints ('EVM only', 'requires both token addresses') largely duplicate the schema's chain field description and required list, so it contributes little genuinely new behavioral context beyond the negative routing statement.

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

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

Three tight sentences, front-loaded with the verb+resource and return values before routing guidance. The only inefficiency is the 'EVM only' clause, which repeats the chain field's own schema description.

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 details need not be repeated, and the description still covers scope (EVM-only), inputs (token pair), and sibling routing. Nothing an agent needs in order to select or call this tool is missing.

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

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

Schema description coverage is 100%: chain documents its full enum and default, and tokenA/tokenB are described. The description only restates that both token addresses are needed and that the chain must be EVM, so it adds no syntax or format meaning beyond the schema. 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 and resource (read Uniswap V3 pool state) plus the three returned values (price, active liquidity, fee tier), which immediately distinguishes it from siblings like defi.yields and defi.compare. An agent can tell what this tool produces without opening the schema.

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

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

It gives an explicit trigger ('when a known token pair needs pool-depth and active-liquidity context'), a prerequisite (both token addresses required), and a negative boundary with named alternatives ('does not rank lending yields; use defi.yields or defi.compare for rates'). This is the exact when/when-not/alternative structure the dimension asks for.

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, non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the 6-hour window, 36 sample count, and that the sampled metric differs by chain family (base fee per block on EVM, TPS on Solana). It stops short of noting latency, caching, or resolution, but the added context is substantial.

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

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

Three tight sentences with zero filler; the core scope and the 6-hour/36-point specifics lead, and disambiguation against siblings follows. Every clause earns its place.

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

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

An output schema exists, so return-value explanation is not required. The description supplies the window, sample density, per-chain metric semantics, and full sibling routing, leaving no gap an agent needs to fill before calling.

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 carries its own enum and description, so the schema does the heavy lifting. The description's mention of EVM-vs-Solana behavior lightly informs how to read results per chain, but adds no syntax or format guidance beyond the schema. 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 6-hour gas fee trend') plus the sampling model (36 data points, EVM base fee per block vs Solana TPS samples). This is enough to distinguish it from gas.tracker, 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?

Explicitly frames the tool's scope both positively ('inspect recent fee conditions and trend') and negatively ('not as a current quote or a future forecast'), then routes to each sibling by condition: gas.tracker for now, gas.predict for forecast, gas.optimize for timing. This is textbook when/when-not/alternative 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is partly redundant with 'advisory and read-only'. The description nonetheless adds useful behavioral context, the 'analyzes recent block patterns' mechanism and that the result 'includes savings estimate', which is not in 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?

Three tight sentences, purpose front-loaded, followed by usage and routing. 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?

An output schema exists, so return values need not be explained, and the description still notes the included savings estimate. Combined with annotations covering the safety profile and a single well-documented parameter, 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% for the single 'chain' parameter (EVM chain, default base), and no enum is present. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies when the schema carries full 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?

States a specific verb and resource ('Gas price optimization advisor: analyzes recent block patterns to recommend the best time to transact') and explicitly distinguishes itself from gas.tracker and gas.predict. An agent can tell what it does and how it differs 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?

Gives explicit when-to-use ('Use when deciding when to submit a transaction based on recent fee patterns') and names two alternatives with their distinct roles ('use gas.tracker for the current quote and gas.predict for a standalone forecast'). The routing decision is fully specified.

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, open-world, non-destructive, so the safety profile is covered. The description adds methodology (moving-average and trend analysis of block base fees) and states the returned fields (prediction, trend, recommendation) plus explicit scope limits (not a live quote/executor). It stops short of disclosing refresh cadence or latency, 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, front-loaded with the core action, then the return values, then the usage and exclusion guidance. Every sentence carries distinct information with no 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 supplies exactly the remaining context an agent needs: what it computes, its horizon, and when to prefer siblings. Nothing required for correct invocation is missing.

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

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

There is a single 'chain' parameter with 100% schema description coverage, including the full enum and default. The description adds no syntax or format detail beyond what the schema already provides, so baseline 3 is appropriate.

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

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

States a specific verb (predict) and resource (near-future gas prices), names the methodology, and explicitly distinguishes itself from gas.tracker and gas.optimize. An agent can differentiate 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 explicit when (short-horizon fee forecast when planning a transaction) and when-not (not a live quote, not a transaction executor), and routes to the correct alternatives (gas.tracker for current fees, gas.optimize for timing advice). 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, covering the safety profile. The description adds chain-type-dependent content behavior (EVM vs Solana fields), but with an output schema already present, most of the return-field detail is redundant. No auth or rate-limit context is provided, 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?

Three tightly packed sentences: purpose and outputs first, then the when-to-use, then alternatives. Front-loaded and no sentence 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?

For a read-only, idempotent, single-parameter tool with a full output schema and complete annotation coverage, the description supplies everything an agent needs to select and invoke it correctly, including chain-family scoping and sibling 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% and the single chain parameter is fully documented in the schema with enum values and a default. The description adds no chain-specific parameter syntax or constraints beyond what the schema already carries, so the baseline 3 holds.

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 (current gas/fee data), then breaks down the exact outputs by chain family (EVM: base fee, priority fee, predictions; Solana: priority fees, TPS, congestion). It also names the three closely-related siblings it is not, 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?

Explicit positive guidance ('Use for the current fee snapshot before submitting a transaction') plus explicit alternatives with their selection conditions: gas.history for past samples, gas.predict for a forecast, gas.optimize for timing advice. 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 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 declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds scope (cross-chain, which chains, which metrics) but says nothing about freshness/caching, rate limits, or failure behavior across chains — modest added value on top of 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 — the verb, scope, and contents arrive immediately and 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 zero parameters and an output schema present, the description needn't explain return values, and it correctly states scope and contents. Slightly short of complete because it omits any note on data freshness or cross-chain availability, which matters for a live market snapshot.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies for a parameterless tool; the schema correctly documents an empty input object.

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 (Get) and resource (cross-chain market snapshot), and enumerates the three data pieces returned (ETH price, gas costs, DeFi TVL) plus the four chains. This is clear and self-contained, though it does not name the sibling tools it supersedes (e.g., defi.tvl, gas.tracker, oracle.price_feed) to sharpen the distinction.

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?

"in one call" implies this is a convenience aggregate versus calling individual tools, which hints at when to prefer it. However, no alternative tools are named and no exclusions or trigger conditions are given, so usage is only implied.

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

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

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 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 carry the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint). The description adds genuine context beyond them: analysis is purely local ('No external APIs') and chain-restricted ('EVM only'). It stops short of return-detail or rate-limit disclosure, which is minor given 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?

Front-loaded with the core action, followed by detection scope, constraints, and the sibling exclusion. Every sentence carries distinct information with no 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?

An output schema exists, so return values need no explanation. For a two-parameter read-only scan, the description covers purpose, detection scope, environment constraints, and alternative routing — 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%, so the schema already documents both the chain enum and the address parameter; the baseline is 3. The description reinforces the EVM-only constraint on chain but adds no syntax or format 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 (scan), resource (smart contract), and method (bytecode analysis), then enumerates what it detects: selfdestruct, delegatecall, proxy, ownership. It also names the sibling it is not (token.risk), so the agent can distinguish it without opening the schema.

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

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

Gives both positive and negative guidance: use for bytecode-level contract security signals, and it is explicitly not a complete audit or token-market assessment with token.risk pointed to as the alternative. This is explicit when-to-use and when-not routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context the annotations do not carry: the $0.05 cost per call and the fact that the output is advisory (recommendations and mitigations) rather than an executed trade.

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 purpose before the advisory detail and the cost tag. Nothing is wasted, though the appended '($0.05)' sits slightly awkwardly after the actionable 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 a full output schema, complete annotation coverage, and 100% parameter descriptions in the schema, the description need not explain return values, and it doesn't. Its only shortfall is not disambiguating the tool from the other MEV/sandwich siblings in a large 70+ tool catalog.

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 5 documented parameters including enums for chain and action, so the schema does the heavy lifting. The description contributes no additional parameter semantics such as token symbol format, chain scope limits, or how amountUsd bounds affect the analysis. 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: 'Pre-trade safety analysis. Evaluates sandwich attack risk, recommends optimal slippage, and suggests mitigations before executing on-chain trades.' That is concrete and tells the agent exactly what it gets. It does not explicitly differentiate itself from overlapping siblings like 'security.sandwich', 'security.mev.detect', or 'security.mev.intel', which is the only gap.

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?

'Every agent should call this before swapping' gives a clear trigger condition tied to the swap workflow. There is no explicit when-not guidance or a named alternative for cases where the agent prefers security.sandwich or security.mev.detect, leaving some routing ambiguity across the three MEV 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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds real substance: it explains the detection method (front-run + back-run in surrounding transactions) and scopes the read to "recent" history. It stops short of stating scanning depth/window limits or expected latency, so it is strong rather than exhaustive.

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

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

Three short sentences, front-loaded with the core action, then the mechanism, then the routing constraint. Every sentence adds distinct information with no repetition of the schema or annotations.

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 annotations covering safety and an output schema covering return values, the description only needs to establish purpose, method and routing, which it does. Minor residual ambiguity (how far back "recent" reaches, chain default) is documented in the schema rather than here.

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 (address and optional chain defaulting to base), so the schema already carries the parameter semantics and baseline 3 applies. The description only implies the address input and gives no detail on the chain default or the time window behind "recent transactions."

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 pair ("Batch scan an address's recent transactions") plus the exact target of the analysis (MEV sandwich attacks, front-run + back-run patterns). It explicitly distinguishes itself from the sibling security.mev.shield, so an agent can separate the two without opening either schema.

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

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

Gives both sides of the routing decision: use this for historical inspection of sandwich patterns around an address, and explicitly "It is not a pre-trade protection decision; use security.mev.shield before a swap or liquidity action." The when-not plus named alternative is exactly the guidance needed.

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 detection context ('unlimited approvals and risky spender contracts') but says nothing about rate limits, latency, or required permissions, so it adds only modest value 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?

Two tight sentences with zero filler; the core action is front-loaded and the detection behavior follows immediately. Every clause earns its place.

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

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

An output schema exists, so return values need not be described, and the annotations cover safety semantics; the description supplies purpose plus what it detects. The only gap is routing guidance against the many sibling security/token tools, which 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% and both parameters (address, chain) are fully documented in the schema, so the schema does the heavy lifting. The description adds no syntax, format, or chain-selection guidance beyond what the schema already states, 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 ('Check'), resource ('wallet's ERC20 token approvals'), and scope ('for security risks'), so the agent immediately knows what the tool does. It doesn't explicitly distinguish itself from nearby siblings such as token.risk or security.contract.scan, so it lands at 4 rather than 5.

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

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

Usage is implied by the phrase 'for security risks' but the description never states when to reach for this tool versus alternatives like wallet.report or monitor.watch.address, and gives no exclusions or prerequisites. This is the minimum viable implied-usage level.

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 genuinely new behavioral context beyond that: it discloses the underlying method (scanning Transfer events) and that results are net receivers ranked by recent accumulation, which tells the agent the output is derived and time-windowed rather than a snapshot balance. It does not state the recency window or scan limits, so it falls 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, method, and routing exclusions. Front-loaded with the core purpose and no redundant restatement of the name or 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?

An output schema exists, so return-shape explanation is unnecessary, and annotations cover the safety profile. The description supplies the method, the intended question type, and the sibling alternatives — everything an agent needs to select and call this tool correctly.

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

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

Schema description coverage is 100% — chain, limit and address are all documented in the schema (including the chain enum and limit bounds). The description adds no parameter-level meaning such as what 'recent' means in time or how limit interacts with the accumulation ranking. 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 verb and resource ('Analyze top token holders') and clarifies the mechanism ('Scans Transfer events to identify the largest net receivers'). Explicitly distinguishes itself from siblings wallet.profile and token.price, 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 both positive framing ('Use for token-holder concentration and recent net accumulation') and an explicit exclusion with named alternatives ('Do not use it for a wallet's portfolio or token price; use wallet.profile or token.price'). When-to-use and when-not-to-use are both stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the exact on-chain oracle mechanism per chain family and the fact that no external API is involved, which tells the agent about reliability and latency characteristics.

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 zero filler; the action is front-loaded and the mechanism detail follows. Each sentence earns its place.

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

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

An output schema exists and annotations cover safety, so the description need not explain return values. What remains is minor: no freshness/staleness caveat for a 'real-time' claim and no handling note for tokens lacking an oracle or pool.

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 enum contents and the token symbol/address formats are already documented in the schema. The description hints that a 'chain' value changes the underlying source (EVM vs Solana Pyth) but adds no syntax or format 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 and resource ('Get real-time token price') and goes further by naming the price source per chain (Uniswap V3 TWAP for EVM, Pyth for Solana). This differentiates it from adjacent oracle tools, though it never explicitly names the closest sibling (oracle.price_feed) to disambiguate.

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 or when-not-to-use guidance, and no alternative is named despite oracle.price_feed occupying overlapping territory. The note about the data source implies a use case (on-chain-verified pricing) but leaves the selection decision to the agent's 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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered and the bar is lower. The description adds the per-chain-family checklist of what is inspected, which is useful context, but says nothing about latency, rate limits, or coverage limits 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?

Two front-loaded sentences with zero filler: the core action first, then the platform-specific breakdown. Nothing is redundant.

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

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

An output schema exists, so return values need not be explained, and the read-only annotations cover risk. The description gives an adequate picture of scope for a two-parameter analysis tool, though it could note coverage boundaries or that results depend on on-chain availability.

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 both parameters are fully documented in the schema (chain enum with EVM/non-EVM notes, address format). The description's EVM vs Solana split loosely maps to the chain parameter but adds no syntax or format guidance beyond it, so baseline 3 is appropriate.

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

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

States a specific verb and resource ("Analyze a token's risk profile") and enumerates the concrete checks performed (contract verification, proxy status, ownership renouncement, liquidity for EVM; mint/freeze authority, supply, Metaplex metadata for Solana). This is more informative than most siblings, but it never contrasts itself against overlapping tools such as security.contract.scan or token.screener.

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 purpose implies a use case (vetting a token before interacting), but there is no explicit when-to-use, when-not-to-use, or named alternative among the many token.* and security.* siblings. 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 readOnly, idempotent, openWorld, non-destructive, so the safety and side-effect profile is fully covered. The description adds the meaningful detail that it's a deterministic signal-based oracle with 'No LLM', which sets expectations about output. It doesn't mention caching, rate limits, or what the sentiment output looks like (though an output schema exists).

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

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

Three compact sentences, front-loaded with the resource and scope, then the signal list, then the pricing note. Nothing wasteful, though the '($0.012)' cost tag is stuck at the end and could be folded in.

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 annotations, full schema coverage, and an output schema, the description only needs to convey purpose and method, which it does. It's complete enough to invoke correctly, missing only sibling differentiation and any hint of output shape.

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 both parameters carry descriptions (chain enum list plus 'native'), so the schema does the heavy lifting. The description adds only 'any token/chain' framing, not new format or semantics. 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 noun phrase (on-chain sentiment oracle) and lists the exact 5 input signals it derives sentiment from. This distinguishes it from siblings like predict.token_momentum and token.trending by scoping it to on-chain gas/health/ecosystem signals rather than price or trade data.

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

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

The description implies usage ('for any token/chain', gas/health signals) but names no alternative and gives no when/when-not guidance. Siblings such as predict.token_momentum and token.trending overlap enough that a routing sentence would help.

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 useful negative scope (no price, safety, or holder concentration assessment), which is genuine behavioral context beyond the annotations, though it doesn't discuss caching, chain support limits, or failure modes for non-contract addresses.

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 action and return fields. Slight redundancy: the field list ('total supply, decimals, symbol, name') is effectively restated in the second sentence, which costs a little efficiency.

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 values, and annotations plus 100% schema coverage carry the structural burden. The description covers purpose, scope, and routing, leaving no functional gap for an agent.

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

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

Schema coverage is 100% and both parameters (address, chain with default 'base') are already documented in the schema. The description adds no format, validation, or chain-support detail 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 ('Get') and resource ('ERC20 token total supply, decimals, symbol, and name from on-chain data'), naming the exact fields returned. It is immediately distinguishable from sibling token tools by scope.

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 ('contract-level supply metadata') and names three alternatives with their conditions: token.risk, token.price, token.holders for the concerns this tool does not cover. 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 destructiveHint=false, so the safety profile is covered. The description contributes the ranking methodology (Transfer event count in recent blocks), which is real behavioral context, but the EVM-only constraint it states is already repeated verbatim in the chain parameter schema description.

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

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

Two tight sentences, front-loaded with the core purpose before the qualifying detail. Nothing is redundant or padded.

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

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

With an output schema present and annotations covering the safety profile, the description only needs to establish scope and ranking semantics, which it does. Minor omission: no hint of result volume or ordering beyond 'recent blocks', though the output schema likely handles that.

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

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

Schema description coverage is 100%: both `chain` (with its long enum and explicit Solana exclusion) and `hours` (lookback window, 1-6 bounds) are fully documented in the schema. The description adds no syntax or format detail 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 and resource ('Get trending tokens') and pins the ranking mechanism to on-chain Transfer event volume, which separates it from token.price or predict.token_momentum. It doesn't explicitly name a sibling it is not, but the mechanism and EVM scoping make the tool's identity unambiguous.

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

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

Usage is implied by 'trending tokens' (discovery of what's moving now), but there is no explicit when-to-use statement and no routing to alternatives like token.screener or predict.token_momentum. Adequate but leaves the agent to infer the context.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuinely useful context beyond them: 'No LLM cost — pure data' and a per-intent breakdown of which signals are aggregated (swap = gas+price+whales, etc.). It doesn't describe pagination or freshness/latency characteristics, but the additions are substantive.

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

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

Front-loads the purpose and packs intent semantics and the use/avoid guidance densely with little waste. The intent parenthetical list is information-dense but each entry earns its place by clarifying the param.

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 rich annotations, the description needn't explain return values. It covers purpose, intent behavior, and routing, leaving only minor details like data freshness undisclosed — adequate for a 2-param, zero-required aggregator.

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 both params are enums, so the schema already lists valid values. The description goes further by explaining what each intent value aggregates (swap=gas+price+whales, bridge=multi-chain gas, invest=yields+trending, monitor=whales+gas), adding meaning the terse schema description ('Agent's intent') lacks.

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

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

States a specific verb (aggregates) and resource (real-time on-chain signals into a structured context brief) and immediately frames it as 'Context as a Service' for agent decision-making. It differentiates itself from the many focused signal siblings by explicitly routing agents to 'focused tools' instead.

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 ('Use at the start of a swap, bridge, invest, monitor, or general workflow') and when not to ('Use focused tools when the agent already knows the exact data it needs'). The condition selecting the alternative is spelled out, leaving nothing 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 cover safety (readOnly, idempotent, non-destructive, openWorld), so the description correctly focuses on non-obvious behavior: it counts against the client hourly MCP capacity policy and settlement differs on the paid HTTP API. This billing/capacity disclosure is genuine added value beyond structured fields; only the slightly repetitive phrasing of the policy keeps it from a 5.

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

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

Front-loads purpose in the opening clause and every sentence carries information. Minor redundancy: the paid-HTTP settlement point is stated twice ('use the paid HTTP API for per-request settlement' and 'paid HTTP requests are separate from this MCP capacity policy'), and 'focused route/set' is repeated, costing a point.

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 rightly omitted, and annotations carry the safety profile. Usage, routing behavior, and billing context are all present; the only soft spot is that the dual-channel settlement message is split across two sentences, creating slight ambiguity about which channel this call uses.

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 'query' param already ships with examples ('Is 0xABC safe?', 'Best yield on base?') and the 44-value chain enum is fully documented. The description restates the natural-language nature of the input but adds no format, constraint, or default 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+resource: natural-language intent routing where the agent describes a question and ChainRay 'selects a focused set of data services.' It explicitly distinguishes itself from the sibling tool family ('For deterministic workflows, call the specific tool directly'), so an agent can tell it apart from token.risk, defi.aggregator, etc. without reading 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 clear when-to-use ('when the agent has a natural-language data question and needs ChainRay to select a focused route'), when-not ('for deterministic workflows, call the specific tool directly'), and an alternative channel (paid HTTP API for per-request settlement). All conditions are explicit rather than inferred.

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 safety is covered. The description adds genuine behavioral context the annotations cannot: it returns guidance/metadata rather than a live stream, and consuming the streams requires a direct HTTP connection with text/event-stream Accept and payment headers. This is valuable operational detail beyond structured fields.

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

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

Front-loaded and reasonably tight, but three of its sentences restate the same idea: 'learn how to connect', 'discover the five real-time SSE streams', and 'connect directly over HTTP'. The guidance repeats rather than builds, so a couple of the sentences do not fully earn their place.

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

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

An output schema exists, so return values need not be enumerated, and annotations cover the safety profile. The description supplies the key caveat (not a stream itself) and the connection prerequisites, leaving an agent equipped to act. It could be slightly more complete about what the guidance payload contains.

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 to document; the baseline for a parameterless tool is 4. The description does not invent parameter semantics and correctly implies no inputs are needed.

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

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

States a specific verb and resource: it retrieves connection info for ChainRay real-time SSE streaming endpoints. No sibling tool covers streaming, and the description makes clear this is a discovery/informational tool, not a data endpoint. An agent can tell what it produces without opening the schema.

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

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

Explicitly says 'Use this tool to learn how to connect' and to discover the five SSE streams, which sets clear usage context. It also warns that the returned guidance is not a stream itself, implicitly steering the agent toward direct HTTP for actual streaming. It stops short of naming a sibling alternative or a when-not-to-use condition.

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 open-world behavior, so the safety profile is covered. The description still adds genuine value by scoping the guarantee ('verifies a supplied hash and does not independently validate the underlying blockchain data'), heading off agent over-trust in the result.

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. The second sentence largely repeats the sourcing detail from the first (_proof.dataHash), which is mild redundancy, but nothing is bloated.

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

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

Output schema exists, so return values need no explanation, and the single parameter is fully documented. The scope limitation and usage trigger round out what an agent needs; only a note on failure behavior would add more.

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 baseline is 3. The description goes beyond the schema by telling the agent where the argument comes from (the _proof field of any ChainRay response) and that the hash is provenance-related, not arbitrary input.

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 (verify) and resource (data integrity / a supplied hash), plus the exact provenance of the input (_proof.dataHash from a ChainRay response). No sibling tool overlaps this function, so it is unambiguous without needing sibling differentiation.

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

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

Gives an explicit trigger condition: 'Use after receiving a ChainRay response with _proof.dataHash.' There is no competing alternative tool to name or exclude, so the missing exclusions cost little, but the guidance is purely a sequencing hint rather than a full when/when-not treatment.

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 safety (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description still adds meaningful behavioral context: the 0-100 output range, the grade scale AAA to C, and the five factor categories that drive the score. It does not, however, disclose score semantics (higher=better implies creditworthiness), refresh/caching behavior, or the address requirements.

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

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

Three short front-loaded sentences: verb+resource first, then factors, then output format. No filler, no repetition of schema fields. Front-loaded with the core action.

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

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

For a tool with a rich schema (enum, default), full annotations, and an existing output schema, the description is close to complete: it establishes scope, factor inputs, and output shape. A minor gap is that it doesn't clarify whether the address must match the chosen chain or which address formats are accepted, but this is a small omission given the schema and output schema carry the rest.

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 are already documented (address 'Wallet address to score', chain with a full enum and default 'base'). The description adds no parameter syntax or format guidance beyond what the schema provides. 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 ('Calculate an on-chain credit score (0-100) for any wallet') and enumerates the five factor categories used. This is distinguishable from siblings like wallet.profile or wallet.report because it produces a scored grade rather than raw holdings or narratives.

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?

Implicit usage is inferable from the name and description (evaluating a wallet's creditworthiness), but no explicit when-to-use/when-not, no prerequisite that the address must be an EVM wallet, and no routing to alternatives like wallet.profile or analyze.risk_dashboard for related signals.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that four heterogeneous data sources are bundled into one response (implying heavier cost/latency than a single-metric sibling), but says nothing about caching, rate limits, or partial-failure behavior.

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

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

A single front-loaded sentence that lists the payload components without filler. Every clause carries information and nothing is redundant with the name or 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?

With an output schema present, return values need not be described, and the annotations carry the safety profile, so the description is nearly sufficient for this read-only aggregate tool. The only real omission is guidance on when the bundled report beats calling the individual component tools.

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

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

Schema description coverage is 100% and the schema documents both parameters including the 'default: base' chain behavior, so the description correctly does not repeat them. No additional parameter meaning is supplied, which matches the baseline for fully documented schemas.

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

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

The description names a specific resource (address report) and enumerates exactly what it aggregates: wallet profile, credit score, token approvals, and recent interactions. This implicitly separates it from the single-purpose siblings (wallet.profile, wallet.credit_score, token.approval), though it never names those siblings 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?

Usage is only implied: the agent can infer this tool is for a one-shot overview of an address rather than calling each component tool separately, but there is no explicit 'use this when...' or 'prefer X for a single metric' guidance. No prerequisites or exclusions are stated.

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