x402-suite

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about real-time scanning and cross-chain coverage, but does not disclose details like data freshness, rate limits, or chain-specific availability. This is acceptable given the strong 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?

The description is a single, front-loaded sentence with no redundant filler. The parenthetical pricing note is additional context that is useful for an agent deciding whether to invoke a paid tool, and it does not detract from the core purpose.

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

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

The description, combined with a full input schema and an output schema, covers all necessary information for invoking the tool: what it scans, which chains it covers, and the key filter concept. Minor details such as chain-specific limitations are absent, but they are not essential for a read-only scanner with fully specified parameters.

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. The description mentions the concept of arbitrage spread, which aligns with minSpreadPct, but it does not add any parameter-specific syntax or format details beyond what the schema provides. A baseline score 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?

The description states a specific verb ('Scans') and resource ('liquidity depth, swap fees, and arbitrage spread opportunities') across two named chains, Base and Solana. This clearly distinguishes it from the sibling tools, which focus on audits, remediation, governance, and signals rather than DEX market analytics.

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 makes the tool's context clear: it is for cross-chain DEX liquidity and arbitrage spread scanning. It does not explicitly name alternatives or exclusion conditions, but since no sibling tool directly overlaps with this functionality, the implied usage scenario is sufficiently 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 the tool read-only, idempotent, and non-destructive, covering the safety profile. The description adds useful operational context by mentioning the $0.495 USDC fee via x402 on Base/Solana, but it does not disclose details like rate limits, execution time, or whether an address is treated differently from source code.

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

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

The description is compact and front-loaded: a clear purpose statement followed by an essential pricing/payment note. Both sentences earn their place, and there is no filler or redundant elaboration.

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

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

For a single-parameter, read-only tool with an output schema, the description covers the key operational facts: audit focus, supported languages, input form, and cost. It could be more complete by noting any constraints or exclusions, such as network/chain limitations, but it is sufficient for an agent to understand the tool's role.

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

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

The input schema already documents the only parameter, code, as 'Smart contract source code (Solidity or Rust/Anchor) or contract address to audit.' The description repeats the supported languages but adds no new semantic detail beyond the schema, so the baseline score of 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 clearly states an audit function for smart contracts, specifying deep invariant analysis, CEI checks, and severity breakdown for Solidity and Rust/Anchor contracts. It is specific about the resource and method, though it does not explicitly contrast itself with sibling audit-related tools like order.commercial_audit or security.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?

The description establishes clear context: use this tool to perform a security-focused invariant audit on Solidity or Rust/Anchor smart contracts, with code or an address as input. It does not explicitly mention when not to use it or name alternatives, but the intended use case is clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotations: it bypasses JS clutter (handles JS-heavy pages), produces token-optimized output, and discloses the $0.095 USDC cost via x402 — an important operational trait for an agent. 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?

One compact sentence plus a parenthetical pricing note. Purpose is front-loaded and the cost disclosure is cleanly separated. Minor redundancy exists ('Autonomous Web Extraction & Clean Markdown Scraper' restates what the following clause describes), but the overall length is justified for a scrape tool with commercial terms.

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

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

For a single-parameter tool with an output schema present, the description is complete: it states what is fetched, what is produced (clean Markdown), the handling behavior (JS bypass), and the cost. An output schema removes the need to explain return values. Nothing critical 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?

Schema coverage is 100% — the single 'url' parameter is fully described in the schema ('Target URL to fetch and clean into semantic markdown'). The description mirrors this ('Fetches any target web URL') but adds no extra format requirements, constraints, or syntax beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.

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

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

The description states a concrete verb+resource: fetches a target web URL and extracts clean Markdown. It is immediately distinguishable from all sibling tools (analytics, audit, governance, remediation, signals), none of which involve web scraping or markdown extraction. The purpose is unambiguous and specific.

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 frames the intended use case ('for AI agent grounding') and signals it is an autonomous fetch-and-clean operation. No sibling tool competes for this function, so explicit when-not/alternative guidance is unnecessary. Clear context, no exclusions required.

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, so the safety profile is known. The description adds context beyond these by clarifying that on-chain execution is simulated rather than real, and by disclosing the price, payment mechanism (x402), and supported networks.

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

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

The description is two sentences with no wasted words. The first sentence front-loads the core purpose and outputs, and the second adds pricing and network context. 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 two parameters, full schema coverage, a complete safety annotation set, and an output schema present, the description covers the essential context: domain, behavior, pricing, and supported networks. No critical information for calling the 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 title and calldata are already documented. The description does not add further parameter-level detail such as expected calldata format or how title maps to the simulation, but it also does not need to compensate because the schema fully covers both parameters.

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

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

The description states a specific verb ('Simulates'), a specific resource ('DAO governance proposals'), and concrete outcomes ('treasury impact and governance attack vectors'). This clearly differentiates it from sibling audit, security, and analytics tools.

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

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

The description establishes a clear use context: it is for simulating DAO governance proposal execution and impact. It does not explicitly name alternatives or exclusions, but its domain scope is specific enough to guide an agent toward appropriate use.

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 read-only, idempotent, and non-destructive profile, so the bar is lower. The description adds useful context such as commercial pricing, payment via x402 on Base/Solana, and a git-apply-ready patch output. It does not disclose execution time or whether the payment is immediately charged, but it does not contradict 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 compact and front-loads the core deliverable, with the price and payment details tucked into a parenthetical. There is minor redundancy between 'AST Vulnerability Remediation' and 'Full AST Code Remediation', but overall it is efficient and not padded.

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

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

With an output schema present and annotations covering safety, the description is mostly sufficient for invoking the tool. However, it lacks usage guidance and sibling differentiation, and for a commercial tool it would benefit from clarifying payment/execution side effects. It is adequate but not 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%, so the schema already explains both sourceCode and auditReport. The description adds the general purpose of those inputs but no new parameter-level detail beyond what the schema provides, matching the baseline for high schema coverage.

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

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

The description clearly states the tool produces a commercial AST remediation git patch package that resolves vulnerabilities, reentrancy bugs, and gas inefficiencies, and is ready for git apply. The resource and deliverable are identifiable, though it does not explicitly distinguish itself from related siblings like remediate.code_patch or order.commercial_audit.

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

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

No explicit guidance is given for when to use this tool versus its siblings. The description implies it should be used when source code and perhaps an audit report are available, but it does not state exclusions, prerequisites, or alternatives, leaving the agent to infer 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 the tool as readOnly, idempotent, and non-destructive, and the description adds useful behavioral context by disclosing the commercial nature, $149.000 USDC price, x402 payment method, and supported networks. It does not contradict 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 package type and includes the critical price/payment detail. However, it contains redundant phrasing such as 'Commercial Security Audit & Invariant Verification Package' followed by 'Exhaustive Commercial Smart Contract Audit & Formal Verification Package', plus marketing filler like 'Exhaustive', so it could be tightened.

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

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

Given the low parameter count, strong annotations, and presence of an output schema, the description covers the essential usage context: target materials, network, package contents, and payment. A minor gap is that it never explicitly states that the tool places or initiates an order, but this is partially inferred from the 'order' prefix and pricing.

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 input schema already documents target and network adequately. The description reinforces that target can be source code, a contract address, or a GitHub repository and mentions Base/Solana, but it does not add meaningful parameter semantics beyond the schema.

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

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

The description clearly identifies a commercial smart contract audit and formal verification package for Solidity/Rust/Anchor codebases or GitHub repositories, including invariant proofs and gas analysis. However, it describes a package rather than an explicit action like 'orders' or 'purchases', and it does not distinguish itself from the sibling audit.smart_contract tool.

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

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

The description implies when to use the tool: when a paid, exhaustive smart contract audit with formal verification, invariant proofs, and gas analysis is needed on Base or Solana. It does not provide explicit when-not-to-use guidance or compare against alternatives such as audit.smart_contract.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations by disclosing pricing ('$1.495 USDC via x402 on Base/Solana') and the output format ('unified git diffs'). No rate limits or failure modes are mentioned, but this is a minor gap given the 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?

The description is two sentences and front-loads the core function before adding the payment note. Every sentence provides unique information with no filler or repetition of the tool name.

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 small parameter set, full schema coverage, and presence of an output schema, the description covers the essential invocation context: inputs, output form, and cost. The only mild gap is not naming a similar sibling, but this is more a differentiation issue than a completeness one.

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

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

Schema coverage is 100%, with both 'issue' and 'source' adequately described in the input schema. The description reinforces which issue types are relevant, but it adds little new detail about the 'source' parameter or input formatting. With full schema coverage, a baseline score 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?

The description names a specific action ('Generates'), a concrete deliverable ('ready-to-merge unified git diffs'), and the classes of problems it addresses (security flaws, missing Schema.org tags, performance bottlenecks). This makes the tool's purpose immediately clear and differentiates it from generic audit or analysis siblings.

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

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

The description clearly implies when to use it by listing concrete issue categories that trigger use, such as 'security flaws' and 'performance bottlenecks'. It does not explicitly state when not to use it or mention a sibling alternative such as order.ast_remediation, so it stops short of full exclusion 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 establish readOnly/idempotent/non-destructive behavior, and the description is consistent with them — it 'computes' rather than mutates. It adds genuinely useful context beyond annotations: the $0.045 USDC cost paid via x402 (a real consequence for the calling agent) and the Base/Solana network scope. 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?

A single dense sentence front-loads the purpose, and the parenthetical pricing note earns its place as actionable cost information. There is no filler and no repetition of schema content.

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

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

With an output schema and safety annotations present, the description need not explain return values or safety. The main gap is that the tool targets two chains but exposes no chain parameter and gives no guidance on how tokens or chains should be specified, so a caller could invoke it with ambiguous or wrong-chain inputs. Price, scope, and computed outputs are all covered.

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 each parameter is already documented at a basic level and the baseline is 3. The description adds some framing by indicating the inputs feed a gas/calldata optimization computation, but it offers no per-parameter detail such as token format or how chains are expressed in fromToken/toToken. It doesn't need to compensate for schema gaps.

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

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

The description uses a specific verb ('computes') and names precise outputs: gas-efficient calldata routing, slippage limits, and priority fees, scoped to Base & Solana DeFi transactions. This also disambiguates the tool from its name — it is an optimizer/calculator, not an execution router — and no sibling tool overlaps functionally.

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 scopes usage to Base & Solana DeFi transactions, giving clear applicability context. However, it never states when not to use it, names no alternative, and doesn't clarify that it produces routing recommendations rather than executing swaps/transfers even though the action param lists executable-sounding values (swap, transfer, approve, mint). Usage conditions are implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false; the description adds behavioral context beyond those flags by labeling the operation as a 'Static Checker' and by disclosing the exact price, payment rail (x402), and supported networks (Base/Solana). This is useful, though it does not cover rate limits or response shape.

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

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

Two short sentences, front-loaded with purpose. The first sentence communicates scope and specific checks; the second discloses pricing and target networks. There is no filler, repetition, or unnecessary background.

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, a 100%-covered input schema, and an output schema present, the description only needs to convey the tool's purpose and any non-obvious costs/constraints. It does so. It does not describe output semantics, but that is covered by the output schema, so the definition is essentially 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%, so both tokenAddress and network are already documented in the input schema. The tool description does not add parameter-specific detail, but given full coverage the baseline score of 3 is appropriate; no compensation is 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?

The description opens with a specific noun phrase—'Token Honeypot & Rug-Pull Static Checker'—and an explicit verb-resource pair: 'Checks newly deployed token contracts' for a concrete list of hazards (hidden taxes, blacklist functions, trading toggles, mint exploits). This scope distinguishes it from generic smart-contract audit or KYA risk siblings even without naming 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?

The phrase 'newly deployed token contracts' implies the target scenario, and calling it a static checker implies a pre-trade screening use. However, the description does not explicitly state when this tool should be chosen over audit.smart_contract or security.kya_risk, nor does it state any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the operation is known to be a safe, non-mutating read. The description adds meaningful behavioral context beyond the annotations: the call is a priced x402 request ($0.195 USDC), it supports Base and Solana, and it computes a bounded 0-100 score. No contradiction with annotations exists.

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

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

The description is two sentences and packs in the acronym, core behavior, score range, pricing, payment rail, and supported networks. It is front-loaded with purpose and has no filler. The first sentence is slightly dense, but every phrase 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?

Given the tool has only two parameters, full schema coverage, an output schema, and strong safety annotations, the description completes the picture by disclosing the paid nature and supported networks. It does not dwell on return values because an output schema exists. Minor missing context is limited to explicit guidance on choosing this tool over the closely related security.honeypot_check.

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 'address' and 'network' are documented with clear descriptions and the network enum is provided. The tool description adds no param-level meaning beyond mentioning Base/Solana and the general notion of a wallet address. Per the baseline for full schema coverage, a 3 is appropriate.

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

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

The description clearly names a specific verb ('Evaluates') and a concrete resource: agent wallet history, drainer interactions, and honeypot approvals, culminating in a 0-100 Trust Score. It is functionally distinguishable from siblings like security.honeypot_check, though it does not explicitly call out the distinguishing sibling. The meaning of the KYA acronym is also explained.

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

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

The intended use case is implied: an agent should call this when it needs a wallet safety or trust score on Base or Solana. However, there is no explicit guidance about when to prefer this over security.honeypot_check or other security siblings, nor any stated exclusions or prerequisites.

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 the tool as readOnly, idempotent, and non-destructive. The description adds useful behavioral context by mentioning confidence scoring, pre-drafted outreach angles, and the $0.995 USDC price via x402, which an agent would not otherwise know. No contradiction exists between the description and 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 compact, front-loaded with the core function, and every clause adds value. The pricing parenthetical is somewhat marketing-flavored but still operationally relevant for payment-aware agents. It earns high marks without being 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?

With two parameters, an output schema, and strong annotations, the description is largely sufficient. It discloses the payment requirement, which is a notable contextual gap otherwise. It does not explain stream lifecycle, pagination, or rate limits, but those are less critical given the output schema and annotation coverage.

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 baseline applies. The description does not add any meaning beyond the schema, though the phrase 'high-budget' loosely aligns with minBudgetUsd and the enum conveys the intended category filter. The schema already carries the parameter semantics.

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

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

The description uses a specific verb ('Streams') with a clear resource ('B2B buying intent & Web3 RFP') and adds meaningful detail about confidence scoring and pre-drafted outreach angles. It could be sharper in differentiating from siblings like signals.social_momentum, but it is not tautological or vague.

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 sales/outbound use cases by stating it streams verified high-budget buyer signals with outreach angles. However, it gives no explicit when-to-use vs. when-not-to-use guidance and does not mention alternatives such as signals.social_momentum, leaving usage context mostly inferential.

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, and non-destructive behavior. The description adds valuable operational context beyond annotations: pricing ($0.075 USDC), payment transport (x402), and chain availability (Base/Solana), which are important for an agent deciding whether to invoke this paid tool. It also names the data inputs synthesized.

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

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

The description is a single, dense sentence that front-loads the core function and adds only the crucial commercial detail as a parenthetical. There is no wasted text; every element contributes to understanding what the tool does and what it costs.

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 annotations, the 100% schema coverage, and the presence of an output schema, the description is nearly complete. It covers the tool's purpose, pricing, and network context, and the remaining operational details are carried by the structured fields. It could add a sentence about intended use cases relative to siblings, but nothing critical 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 input schema covers 100% of the parameters with descriptions, including the token symbol format and the timeframe enum with defaults. The description adds no parameter-level detail beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description clearly identifies the tool's function: synthesizing real-time social velocity, developer commits, and token mention spikes into a momentum signal. It is specific about the resource (token momentum) and domain (social sentiment), and it is distinguishable from siblings like signals.intent_feed by focusing on momentum rather than intent.

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

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

The description conveys clear context for when this tool is relevant: when real-time social sentiment and token momentum are needed. It does not explicitly mention alternatives or exclusion criteria, but the 'Real-Time' framing and momentum vector language provide adequate usage context given the sibling list.

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