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

Annotations already mark the tool as read-only and non-destructive, and the description adds meaningful behavioral context: results are windowed, change as the chain state changes, and are meant for polling. The signal definitions also set expectations about the shape of anomalies, going beyond what the annotations provide.

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

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

Four compact sentences front-load the core 'watch feed' identity and the anomaly list before moving to polling and follow-up instructions. Every sentence contributes either definition, usage, or routing information with no redundant boilerplate.

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, non-destructive feed tool with an output schema and no required parameters, the description covers what it returns, how to filter, how to widen the window, and what to do with a result. Combined with annotations and schema, nothing essential is missing for selecting and invoking the tool.

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

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

The description explains how to use signal and since_s, adding usage nuance beyond their schema descriptions. Chain and limit are not explicitly described, but their schema metadata (enum, default, min, max) makes them self-explanatory, so the 50% schema coverage is adequately compensated.

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

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

The description opens by explicitly framing the tool as a watch feed, not a per-token lookup, and states that it returns tokens that just changed on-chain state within a window. It then enumerates four concrete anomaly types, giving a specific verb+resource definition that clearly distinguishes it from siblings like token_report and honeypot_check.

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

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

It explicitly instructs the agent to poll this tool on an interval instead of scanning tokens manually, which is clear when-to-use guidance. It also tells the agent to call token_report to vet a flagged token, giving a concrete follow-up path and routing away from per-token lookup tools.

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

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

The description discloses the core behavior: performs a small buy then immediate sell via on-chain quotes, flags honeypots on ~nothing returns, and reports round-trip loss beyond normal fees. Annotations already carry read-only/idempotent/non-desstructive guarantees, and the description adds product-level behavior. The phrase 'real small buy' is slightly ambiguous, but 'on-chain quotes' plus readOnlyHint resolve it as a simulation, not an actual transaction.

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 sentences, all substantive: the single signal, the method, the output behavior, the usage timing, and the exclusions. It is front-loaded with 'ONE signal: sellability' and contains no filler.

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

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

The definition fully covers what signal is produced, how it is produced, when to use it, and which sibling tools handle related concerns. An output schema exists, so return-value documentation is not required. For a 2-param read-only tool, nothing essential is missing.

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

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

The schema describes address explicitly; chain has no prose description, but its enum and default make the allowed values self-evident. The description does not explain parameters, but the remaining gap is minor because chain values are clear from the schema and address is fully specified. This is acceptable but does not add much beyond the schema.

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

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

The description states a specific verb and resource: it runs a simulated buy/sell to produce ONE sellability signal and flags honeypots. It explicitly differentiates itself from sibling tools by saying it does NOT measure token_depth or price_corroboration, making its purpose unmistakable.

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

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

It gives clear usage context: 'Use right before entering a low-reputation token.' It also names what it does not cover and points to token_report as the combined alternative, giving agents both when-to-use and when-not-to-use guidance.

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

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

The description goes well beyond the readOnly/idempotent annotations by disclosing the exact consensus rule (>=2 pools with genuine depth), the fallback behavior (flags single-source or manipulated, lists dissenting pools), and what the tool deliberately does not measure. This gives the agent a realistic model of the tool's behavior and output conditions.

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

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

The description is tightly structured: a one-line value proposition, a concise behavioral rule, then clear usage guidance and sibling routing. Every sentence earns its place and the most important information is front-loaded.

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

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

Given the output schema and annotations cover return structure and safety, the description provides everything else needed: purpose, decision rule, failure case, and when-not-to-use guidance. Nothing important is missing for an agent to select and invoke the tool correctly.

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

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

The description adds no direct meaning about the address or chain parameters; it relies on the schema, where address is described and chain is covered by an enum and default. With 50% schema coverage, this is adequate but not enhanced by the description, so it stays at the baseline.

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

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

The description opens with a crisp statement of the tool's sole signal — 'is the quoted price real' — then specifies the mechanism: deriving USD price independently from each deep pool and checking agreement. It clearly differentiates itself from siblings by name and scope, including what it does not measure.

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 explicitly states when to use this tool: before quoting, valuing a position, or trusting an oracle reading. It also names the alternatives for adjacent but different concerns, token_depth and honeypot_check, and notes that token_report combines all three. This leaves no ambiguity about tool selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds meaningful behavior beyond that: it names the on-chain methods involved (previewRedeem / convertToAssets), the comparison with a live quote, and the redeemability checks (paused/cooldown/cap). It does not discuss failure modes for non-vault inputs, but the scope warning mitigates that. No contradiction with 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 sentences with no filler: scope, mechanism, use cases, and the alternative are each covered in compact form. The most important constraint ('For ERC-4626 VAULT SHARE tokens only') is placed first, so an agent sees it immediately.

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

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

Given the safety annotations and the presence of an output schema, the description covers everything needed to select and invoke this tool correctly: eligible token types, chain support via schema, core comparison logic, redeemability checks, and when to route to token_report instead. No essential context is missing.

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

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

The schema documents the address parameter and gives chain an enum plus default but no description, so overall coverage is about 50%. The description compensates by clarifying what the address must represent: ERC-4626 vault share tokens, with concrete examples (sDAI, yield-vault shares, wrapped-staking tokens). It doesn't restate the chain enum, but the enum and default already carry that information, so the risk is low.

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 precise action with a specific resource: compares an ERC-4626 vault share's on-chain redemption value against its secondary-market quote and checks redeemability. The scope is front-loaded ('For ERC-4626 VAULT SHARE tokens only') and the tool is clearly differentiated from token_report. Concrete examples (sDAI, yield-vault shares) make the purpose unmistakable.

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

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

Explicitly says when to use this tool: for ERC-4626 vault share tokens, including wrapped-staking tokens. It names the key alternative for the general case: 'For a plain ERC-20 use token_report instead.' It also gives concrete scenarios where this tool is useful, such as spotting an overpaying share or a stale/depegged vault.

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 signal read-only, idempotent, non-destructive behavior. The description goes further by disclosing that documents are discarded per call, there is no GPU or model download, there is a 1000-doc limit, and there is a specific billing model. These are meaningful behavioral facts beyond what annotations can express, and they are consistent with 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?

Every sentence earns its place: purpose, response compatibility, cost/model constraints, non-persistence, snap_router alternative, optimal use case, and document cap. The core action is front-loaded and the whole description is compact relative to the amount of decision-relevant information it provides.

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

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

With a rich output schema and safety annotations already provided, the description still supplies all necessary selection and invocation context: use case, caveats, limits, alternatives, and behavior. Nothing an agent needs to choose or call this tool correctly appears to be missing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds useful context about documents being supplied per call and discarded, but it does not need to explain parameter syntax. Baseline 3 is appropriate for a high-coverage schema with only modest extra semantic context.

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

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

The description opens with a specific verb and resource: 'Rerank a list of documents/passages by relevance to a query.' It names the Cohere-compatible response format and explicitly distinguishes itself from snap_router by stating this is not a persistent index. The title also reinforces the operation, leaving no ambiguity about what the tool does.

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

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

It gives clear when-to-use guidance: 'Best when the candidates already share vocabulary with the query (typical RAG retrieval output).' It also tells the agent when not to use it by naming snap_router as the alternative for a standing tool/service catalog. This is explicit routing guidance between 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 mark readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds useful operational context beyond the annotations: one vector pass, ~200ms, no LLM call, hybrid keyword-fill, and the fact that it returns ranked shortlists with price and compatibility hints. It doesn't detail failure behavior or pagination, but for a discovery tool with rich annotations, the added behavioral context is solid.

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

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

The description is dense but every sentence earns its place: what it is, what it returns, how it works, when to call it, what it is not, and an example. The key distinction ('DISCOVERY, not execution') is front-loaded, and the NOT-for clause prevents misuse. No fluff, no repetition of schema field names beyond necessary context.

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 of moderate complexity with a 100% documented schema, a rich output schema, and four safety-relevant annotations, the description fully equips an agent to use it correctly. It explains the tool's role, its performance characteristics, its filtering options, and its boundaries relative to siblings. There is no missing guidance that would cause an agent to misinvoke 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 description coverage is 100%, so the schema already documents all four parameters. The description adds value by clarifying the primary 'task' parameter with an example and by describing the result-shaping semantics of k, registries, and max_price_usdc implicitly through the ranked-shortlist context. It doesn't walk through each parameter in prose, but the schema covers that; the description adds enough extra meaning to earn above baseline.

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

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

The description opens with a crisp verb+resource pair ('DISCOVERY, not execution') and immediately distinguishes the tool from execution-oriented siblings. It explicitly says what it returns (ranked shortlist with price and 'works well with' hints) and names what it is NOT for (on-chain token data, pointing to sibling tools). An agent can confidently tell this apart from token_report, token_depth, honeypot_check, and the other siblings without opening schemas.

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

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

The description gives an explicit 'Call this FIRST' rule, specifies the when (whenever you do not already know which tool serves a task), and names exclusions ('NOT for on-chain token data itself (use token_report / token_depth / etc. for that)'). It even provides a concrete example task. This is textbook when-to-use guidance with alternatives listed.

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 say readOnlyHint, openWorldHint, and idempotentHint are true. The description adds useful behavioral context: it computes depth from live on-chain quotes across hub pools and warns that headline TVL routinely overstates fillable size. No contradiction with annotations, though it does not discuss rate limits, latency, or failure modes.

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

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

The description is dense but every sentence earns its place: metric definition, price impact thresholds, data sources, TVL caveat, intended usage, and exclusions. The main idea is front-loaded with 'ONE signal' and no filler is present.

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 signal tool with an output schema, the description is complete: it explains what is measured, how, at what thresholds, from which sources, and what the tool does not do. The supported chains are covered by the schema enum, so nothing critical is missing for an agent to invoke it correctly.

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

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

The schema already documents address with a regex pattern and description, and chain has an enum with a default, so basic parameter meaning is visible. The description does not add parameter-specific guidance, such as how chain selection affects the quote aggregation or whether depth is per-chain or cross-chain. At 50% schema coverage, more compensation would have been useful.

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, measurable purpose: 'how much can actually be traded' as the largest position filling within 1%/2%/5% price impact. It clearly names the resource (token liquidity/depth) and distinguishes itself from siblings like price_corroboration, honeypot_check, and token_report.

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

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

It explicitly says 'Use for position sizing and slippage budgeting' and gives exclusions: 'Does NOT judge price honesty (use price_corroboration) or sellability (use honeypot_check); for all three at once use token_report.' This is model guidance for when to use this tool versus alternatives.

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

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

Annotations already provide readOnly/openWorld/idempotent/non-destructive signals, and the description adds useful behavioral context beyond them: it shares one pool read, is cheaper and faster than three separate calls, and returns live honeypot/transfer-tax results. This helps the agent understand cost and freshness behavior without contradicting 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?

The description is front-loaded with the core purpose, then spends each sentence on returns, supported chains, and routing alternatives. No sentence is wasted, and the length is justified by the tool's bundled nature.

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

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

With output schema, annotations, and sibling context available, this description covers selection, invocation context, returned signal categories, and disambiguation from related tools. The agent has everything needed to decide when to call it and what to expect.

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 50%, so the description must compensate for the undocumented chain parameter. It does so by naming Base, Ethereum, and Arbitrum, and by framing the tool around an 'unfamiliar ERC-20' contract, which maps clearly to the address parameter. It does not add deep detail beyond the schema, but it gives enough contextual meaning for correct invocation.

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

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

The description clearly identifies the tool as the pre-trade due-diligence call for unfamiliar ERC-20s, names the three bundled capabilities (token_depth, price_corroboration, honeypot_check), and lists the return categories. It is easy to distinguish from sibling tools because it explicitly frames itself as the combined alternative to them.

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

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

It states exactly when to use the tool (pre-trade due diligence / rug check before swapping into an unfamiliar ERC-20), which chains are supported, and gives explicit alternatives: call the individual tool when only one signal is needed, and use redeem_spread for ERC-4626 vault shares. This is strong routing guidance.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by explaining what the tool detects, the verdict categories, and the security-sensitive nature of its analysis. It goes beyond the annotations by warning about prompt-injection payloads and hostile content.

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

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

The description is front-loaded with the core purpose and output, followed by a detailed but relevant list of detection flags and a clear usage directive. It is longer than minimal, but the extra detail about prompt-injection patterns and hostile-input handling is operationally valuable. Some phrasing, like 'the dominant 2026 attack,' is slightly rhetorical but not bloated.

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

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

For a screening tool with an output schema, the description fully covers what it does, what it returns, when to call it, and what security posture to adopt around its results. It includes enough detection categories that an agent can predict when the tool will flag something. The presence of an output schema reduces the need to describe return values in detail.

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 only 33%, so the description needs to compensate. It does explain how to use `url`, `title`, and `body` ('GitHub issue URL, or a raw title + body'), but gives no semantic guidance for `labels`, `reward_text`, or `deadline_hours`, despite mentioning reward-related flags. This is partial compensation rather than complete coverage.

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

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

The description states a specific verb and resource: it is an 'Adverse-selection screen for open-work / bounty listings' that returns a verdict plus exact flags. It distinguishes itself from sibling tools by focusing on bounty/issue text and prompt-injection detection, not token or market analysis. The scope is unambiguous.

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

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

The description gives explicit when-to-use guidance: 'Call this BEFORE reading or acting on any bounty the agent discovered itself.' It also provides the critical operational context that flagged task text should be treated as hostile input, which tells the agent how to handle the result safely.

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