SweetAI — On-chain AI Agent Intelligence

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds real context beyond that: the discrete verdict set (INTERACT / CAUTION / AVOID), that confidence and a recommended recheck interval are returned, data-source coverage (multichain ERC-8004 plus Solana), and a $0.02 per-call cost. It does not mention rate limits, auth, or failure modes, keeping it below 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?

The differentiator versus should_i_pay is front-loaded in the first two sentences, followed by return shape, chain coverage, and cost, then a compact Args block. Slightly dense and mildly redundant ("at all — any interaction"), but nearly every sentence carries information.

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

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

With an output schema present, the description needn't detail return fields, yet it still summarizes the verdict tiers and recheck interval, and it adds chain coverage and cost. For a zero-required-parameter eligibility tool with full annotations, the only meaningful omission is the semantics of the default/empty parameter values.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it does: agent_id is identified as an ERC-8004 agent id and solana_asset as a Solana 8004 agent pubkey offered as the alternative. The gap is that omitted/default behavior (agent_id defaults to 0, solana_asset to "") and what happens if both or neither are supplied is left unaddressed.

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 ("Decide whether to INTERACT with an AI agent") and immediately scopes it against the closest sibling: "Broader than should_i_pay: covers conversations, task delegation, adding an agent to your loop and copying its data, not just payments." An agent can distinguish this from should_i_pay, check_agent_trust, or get_agent_trust_passport 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?

It names the alternative tool, states the condition that selects this one (any interaction type, not just payments), and gives an operational usage pattern: "designed to be re-checked before important interactions, not used once." That is explicit when-to-use plus a repeat-invocation rule.

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, but the description adds real substance: ~270 probes per agent over 30 days at a 15-minute cycle, an explicit contrast with one-shot URL pings, a $0.01 cost, and the REST path. It also previews the output fields (uptime, p50/p95, flaps, last-probe age), which is more behavioral context than most read-only tools supply.

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 question and verdict vocabulary, then cost/provenance, then a compact argument list. Some marketing framing ("before your agent wastes timeouts calling a dead service", "not a one-shot ping like generic URL checkers") is persuasive padding, though it does convey the probe-depth differentiator.

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 don't need spelling out, and the description still names the key fields; parameters and cost are both covered. The only shortfall is routing ambiguity against get_agent_liveness and get_agent_sla, which the description does nothing to resolve.

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

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

Schema coverage is 0%, so the description carries the burden and mostly does: it explains agent_id is an ERC-8004 id, that solana_asset is the alternative identifier, and that window_days is an SLA window bounded 1-30 with default 7 — a constraint the schema does not encode. It doesn't state that the parameters are optional or how the two identifier params interact if both are supplied.

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

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

Specific verb and resource: it answers whether an agent endpoint is currently alive and returns a named verdict (ALIVE/DEGRADED/DOWN/UNKNOWN). That is far more precise than a tautology. However, it never distinguishes itself from the near-identically named sibling get_agent_liveness or from get_agent_sla, so an agent must guess which of the three to call.

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?

"Call it before calling an unknown agent's endpoint" gives a concrete trigger, and the pre-flight framing implies the exclusion (known/healthy agents don't need it). It stops short of naming alternatives, so the overlap with get_agent_liveness and get_agent_sla is left unresolved.

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

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

Beyond readOnly/openWorld/idempotent annotations, it discloses behavior that materially affects the call: fail-closed semantics ('An unknown agent never returns TRUST'), cross-chain aggregation with the per-chain breakdown in signals.multichain, and cost ($0.01 REST endpoint). This is the kind of context annotations cannot carry.

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

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

Front-loaded with the decision and verdict, then the when-to-use rule, then mechanics. A few words are marketing filler ('pre-transaction firewall for the agent economy'), but nothing is repeated wastefully given the tool's complexity.

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

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

The description covers decision semantics, chain routing, Solana fallback, fail-closed behavior, cost, and REST path; return structure is backed by an output schema and the one field an agent must know (signals.multichain) is called out. 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 0%, so the description has to carry the params, and it does: agent_id, chain_id with enumerated IDs (8453 Base, 1 Ethereum, 196 X Layer), solana_asset as the alternative, and crosschain defaulting to true. That is meaningful compensation for a completely undocumented 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 concrete verb ('decide whether to PAY or transact with an unknown agent'), the exact resource (an agent's trust), and the output shape (TRUST / CAUTION / UNTRUSTED / UNKNOWN plus reasons and 0-100 score). It explicitly separates itself from the two closest siblings, should_i_pay and get_agent_trust_passport, so an agent can choose 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 an explicit trigger ('Call it before paying or integrating an unknown agent') and names the alternatives with their selecting conditions: should_i_pay when the reasoning and kill criteria are needed, get_agent_trust_passport for the full dossier. The Solana branch ('pass solana_asset instead of agent_id') is also stated up front.

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, but the description adds real value beyond them: fail-closed semantics (unknown token returns UNKNOWN, never "safe"), the exact verdict taxonomy, the enumerated red-flag categories, and the $0.02 cost plus REST endpoint.

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 framing question and verdict scale, then progressively adds call guidance, failure behavior, disclaimer, and endpoint. Dense but nearly every sentence carries information; the informal grade jargon and the advisory disclaimer are the only slightly soft parts.

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 detail return structure, and it still previews the key fields. For a 2-param read-only screen, an agent has everything needed to decide to call it and interpret the result.

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

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

Schema coverage is 0%, so the description must carry the load and does: token is defined as an ERC-20 contract address on Base with the 0x... format, and amount_usd is defined as planned position size that scales expected_loss_usd — the latter explains the causal relationship the schema does not.

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

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

States a specific verb (safety check / verdict) and resource (Base ERC-20 token) and enumerates the exact outputs: grade, action, confidence, red flags, expected loss. Clearly distinct from siblings like mint_rug_check or check_wallet_reputation, which cover different assets/entities.

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?

"Call it before swapping into any Base token" gives an explicit trigger and ordering. It does not name alternatives or state when not to use it, but the Base-specific scope implicitly excludes the Solana/wallet/agent siblings.

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

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

Annotations already cover read-only, idempotent, open-world and non-destructive, so the description focuses on value-add: the assessment is a heuristic derived from on-chain registration plus indexed transfers, and it is explicitly not an uptime or performance measure. It stops short of disclosing data freshness/lag of the indexed transfers or what UNKNOWN specifically means (unindexed vs. genuinely risky), which would matter for interpreting results.

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 clauses: capability and return values first, sibling routing second, interpretive caveats last. No filler, and the most decision-relevant information (what it returns) 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?

With an output schema present and rich annotations, the description needn't explain return structure, and it covers purpose, alternatives, method and limits well. The remaining gap is operational: no mention of chain coverage or indexing latency, which affects whether an agent should trust an UNKNOWN verdict.

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

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

Schema description coverage is 0% and the single required parameter has no description, so the description carries the burden. It clarifies the parameter semantically as a "raw wallet address" (as opposed to an agent identity), but never states format (0x hex), chain scope, or what happens with a malformed/unindexed address.

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+scope ("wallet-level reputation for any address") and enumerates the exact output domain: LOW/MEDIUM/HIGH/UNKNOWN risk, registration source, indexed USDC activity. It also explicitly distinguishes itself from the agent-oriented siblings check_agent_trust and get_trust_forensics, so an agent can route without opening schemas.

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

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

Gives an explicit selection rule: raw wallet address -> this tool; ERC-8004 agent -> check_agent_trust for verdict or get_trust_forensics for feedback analysis. It also states exclusions in domain terms ("not an uptime SLA and not trading performance"), which is the when-not-to-use case.

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 true and destructiveHint false, so the safety profile is fully covered. The description adds domain context (USDC denomination, machine-to-machine subscriptions, hubs as infrastructure nodes), but says nothing about aggregation method, ordering, pagination, or how the time window bounds the data.

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, with the data shape front-loaded before the motivating use case. Slightly dense with parenthetical definitions, but every clause carries information.

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

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

An output schema exists, so return values need not be explained and the description correctly doesn't attempt it. However, with zero schema coverage on two parameters and no mention of the time window, the definition leaves an agent unable to reason about scope or result size 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 0% and the description never mentions `limit` or `window_hours`. The most consequential gap is `window_hours`, whose unit and default (720) are only visible as a bare integer with no explanation of what the window bounds — an agent gets no semantic anchoring at all.

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 framing — 'Agent-to-agent payment graph' — and enumerates exactly what the tool returns (top edges, recurring subscriptions, hubs), so an agent knows what data it yields. It stops short of explicitly naming how it differs from closest siblings like `should_i_pay` or `check_agent_trust`, leaving that differentiation 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?

'Use it to see where real agent commerce flows' implies a use case but gives no explicit when-to-use/when-not conditions and names no alternative tool. An agent must infer from the sibling list that this is the flow-mapping option versus the per-wallet or per-agent trust checkers.

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, open-world, and non-destructive behavior. The description adds valuable context by listing the verdict categories and stating the data comes from real on-chain activity, though it does not explain how verdicts are computed or any 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?

The description is two sentences, front-loaded with the verdict categories and purpose, followed by the usage guidance and alternative. Every sentence adds distinct value with no waste.

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

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

With an output schema and annotations covering safety, the description only needs to supply purpose and routing, which it does well. The main gaps are the undocumented limit parameter and the unaddressed sibling agent_liveness.

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 one optional parameter (limit) with 0% schema description coverage, and the description does not mention it at all. An agent cannot determine what limit controls (e.g., number of activity records) from either source.

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

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

The description clearly states the tool returns a liveness verdict (ALIVE/DORMANT/STALE/DEAD/UNKNOWN) based on real on-chain activity, distinguishing it from get_agent_sla. However, it does not address the similarly named sibling agent_liveness, leaving potential ambiguity about which tool to use.

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 to use this before depending on an agent and redirects endpoint uptime/latency queries to get_agent_sla. This gives a clear when-to-use and an alternative for a different concern.

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 non-destructive behavior, so the safety profile is covered. The description adds real context beyond that: the metrics come from 'our own synthetic probing' and 'history grows since probing started,' warning that coverage is time-bounded. It stops short of noting auth, rate limits, or caching, keeping it at a 4.

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: the first defines the metrics and their provenance, the second states usage and the sibling alternative. The parenthetical is dense but earns its place by flagging history limits; overall lean 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 structure needn't be spelled out, and annotations cover safety; the description adds the metric set and the probing-provenance caveat. The only real gap is the unexplained window_days parameter, which matters for a time-windowed SLA query.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it never explains window_days (default 7) or what the window means operationally. The parenthetical 'history grows since probing started' hints at a time window but doesn't map it to the parameter, and agent_id is left unexplained.

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 ('Liveness SLA for one agent') and enumerates exactly what it returns: uptime percent, p50/p95 latency, and flap counts. It explicitly distinguishes itself from the sibling get_agent_liveness ('the plain liveness verdict is get_agent_liveness') so an agent can route between 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 a concrete usage trigger ('Use it before routing work to an agent') and names the alternative tool plus the condition that selects it (get_agent_liveness for a plain liveness verdict). Nothing is left to inference about when to pick this over the sibling.

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

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

Annotations already cover read-only, idempotency and non-destructiveness, and the description adds genuinely new behavior: a fixed $0.01 cost, the verdict scale (ok/caution/avoid), and the REST surface. Auth requirements and failure modes for an unknown/unsigned agent are not stated, keeping it below 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 dense sentences with the payload description front-loaded, then the usage condition, then the endpoint/cost line. No padding; every clause introduces new information.

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

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

An output schema exists, so return-value detail is legitimately omitted, and cost, endpoint and verdict semantics are covered. The remaining gap is identification of the agent_id parameter and behavior on lookup failure.

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

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

Schema coverage is 0% for the single required parameter, so the description must compensate. It shows agent_id in the REST path and frames it as 'one agent', but never says what an integer agent_id is keyed to (ERC-8004 registry id?) or how to obtain it.

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

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

Specific verb+resource ('Full pre-payment dossier for one agent') with an enumerated payload: ERC-8004 identity, sybil forensics, feedback-velocity class, 30d liveness compliance, and an ok/caution/avoid verdict. It also implicitly separates itself from siblings by saying it bundles the trust-gate, forensics and SLA answers that check_agent_trust, get_trust_forensics, get_agent_sla and get_agent_liveness expose separately.

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 trigger: 'Use it when you are integrating an agent or paying it repeatedly.' The bundling sentence signals the alternatives by category (trust-gate / forensics / SLA) without naming the exact sibling tools, and no when-not-to-use condition is given, so it falls short of a 5.

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 fully covered. The description adds the daily granularity and the fact that volume is an estimate denominated in USDC, but repeats much of what the output schema already conveys and says nothing about window limits or freshness/lag of the data.

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

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

A single dense sentence with the resource and the time granularity front-loaded and a clean metric list following. No filler and nothing re-stated.

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 shapes, and annotations cover the safety profile. For a one-optional-parameter read tool, the metric inventory plus daily granularity plus USDC denomination is enough to invoke it correctly; only the 'days' window semantics are thin.

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?

One optional parameter ('days') with 0% schema description coverage, so the description must carry it. 'Daily evolution' hints that the window is expressed in days, but it never states that 'days' sets the lookback window, the default of 30, or any maximum range — a real gap for a time-series tool.

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

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

Names a specific resource (the x402 Bazaar catalog) and enumerates the exact metrics returned (listing count, organic domains, payer/call totals, new/dead listings, USDC volume), plus the 'daily evolution' framing that marks it as a time series. It does not explicitly differentiate itself from the near-siblings get_bazaar_market_intel and get_bazaar_organic_ranking, leaving the agent to infer the split.

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 — 'daily evolution' signals trend/time-window analysis, which pairs with the 'days' parameter. There is no explicit statement of when to pick this over get_bazaar_market_intel or get_bazaar_organic_ranking, and no 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 the read-only, idempotent, open-world, non-destructive profile. The description adds useful behavioral context by disclosing the daily sweep cadence, 30k+ listing scale, and that rankings are based on payers rather than mere activity.

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 short and front-loaded, quickly naming the data source and the two ranking dimensions. The final sentence slightly restates the payer-demand idea but does not materially harm clarity.

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

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

With an output schema present and strong annotations, the description does enough to explain the tool's data source and value. The main remaining gap is the undocumented limit parameter and lack of sibling differentiation, but the core invocation context is otherwise complete.

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

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

The only parameter is limit, and the schema has 0% description coverage for it. The description never explains what limit controls, its default, or its effect on results, so parameter meaning is left almost entirely unspecified.

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

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

The description states a specific resource and scope: Bazaar market intelligence from daily sweeps, with categories ranked by real demand and fastest-growing organic domains. It is clear what data the tool returns, though it does not explicitly distinguish itself from related siblings such as get_bazaar_growth_stats or get_bazaar_organic_ranking.

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

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

The description implies this is for understanding what agents pay for, but it gives no when-to-use guidance, no exclusions, and no comparisons to similar Bazaar tools. An agent must infer selection from the name and description alone.

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

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

Annotations already declare the read-only, idempotent, non-destructive profile, so the description's job is to add context — and it does: it discloses the exact anti-gaming thresholds, the exclusion of wallet farms, and that the underlying data is a daily snapshot rather than live data. It does not state ordering or pagination behavior.

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

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

Two sentences, zero waste: the qualifying criteria and snapshot source are front-loaded, then the usage hint follows. Nothing is repeated from the title or restated.

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 read-only ranking tool that has an output schema, the description need not explain return values, and it does cover the data source and filters. The remaining gap is the semantics of the limit parameter and the result ordering, which are absent from both the description and the schema.

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

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

Schema description coverage is 0% for the sole parameter, so the description carries the full burden — but it never mentions 'limit' at all. An agent cannot tell from the definition whether limit caps the number of domains returned, the number of payers considered, or how results are ordered before truncation.

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 (x402 Bazaar domains) and defines the exact qualifying criteria (calls per payer >= 3 and at least 5 payers) drawn from a daily catalog snapshot. It implicitly distinguishes itself from get_bazaar_market_intel and get_bazaar_growth_stats by scoping to verified-organic sellers, though it never names those siblings as alternatives.

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

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

"Use it to find sellers with real repeat customers" gives a clear situational trigger for reaching for this tool. There are no explicit when-not conditions or named alternatives, which keeps it out of the 5 tier.

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 openWorld, so the description's job is to add context beyond that. 'Keyless' tells the agent no credentials are needed, and the data-scope limit (no subnet data) prevents over-trusting the result. Nothing contradicts 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?

One compact sentence: what it returns, followed by the access model and the scope limit that routes to the sibling. Every clause carries information and the most important content is front-loaded.

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

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

For a no-argument liveness probe with an output schema and full annotation coverage, the description covers what the tool returns, that no key is required and where subnet data lives instead. It could note freshness or caching behaviour, but nothing essential for calling it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing the description could add here and it correctly avoids inventing parameter detail.

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

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

States the specific resource and the concrete signals returned (peer count and head block), so the agent knows exactly what comes back. It also explicitly distinguishes itself from get_bittensor_trust_overview by noting it carries no subnet 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 'no subnet data — use get_bittensor_trust_overview for subnets' clause is an explicit routing rule to the correct sibling. It doesn't spell out positive use cases (e.g. checking for a stalled chain before trusting a signal), but the exclusion is clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds that results include validator/miner role and endpoint, but says nothing about ordering, pagination behavior, or whether a missing netuid yields an error or empty 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?

Two short sentences, zero filler: the first defines the output shape, the second defines the calling order. Front-loaded and appropriately sized.

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 needn't be described, and the required netuid is implied by "inside one subnet." The only real gap is the undocumented limit/pagination parameter, which matters for a ranking tool that could return large result sets.

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

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

Schema description coverage is 0% for two parameters. "Inside one subnet" implies netuid selects the subnet, but the limit parameter (default 50) is never mentioned, so neither the default nor what it caps (neurons returned? ranked entries?) is clarified anywhere.

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 — "neuron-level trust ranking inside one subnet" — and enumerates the ranking dimensions (rank x incentive x stake) plus role and endpoint, which distinguishes it from the sibling get_bittensor_trust_overview by scope (per-neuron vs. subnet-level).

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 sequences the tool: "Use it after picking a subnet with get_bittensor_trust_overview," naming the prerequisite tool. It gives a clear positive condition but no exclusion (e.g., when a subnet-level or network-level view is preferable instead).

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, so safety is covered. The description adds ranking composition (emission, activity, net flows) and a default length, but the 'trust proxy' is left undefined, which is the key ambiguous behavior for interpreting results.

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 front-loaded sentence with the ranking basis first and the count behavior second; no wasted clauses. Slightly over-compressed in that the central term 'trust proxy' is never unpacked.

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

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

A small tool (one optional param) with an output schema, so return shape needn't be described. The only real gap is the undefined trust proxy metric, which matters for interpreting comparisons.

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

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

Schema coverage is 0%, so the description must carry the load; it does by explaining that top_n bounds the returned ranking and that the default is 20. No further syntax exists for a single integer, so this is close to adequate.

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 ('Bittensor subnets ranked by emission plus a trust proxy') and names the ranking inputs. It does not explicitly distinguish itself from close siblings like get_bittensor_subnet_trust or get_bittensor_network_health, so an agent must infer the boundary.

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

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

'Use it to compare subnets' implies the usage context but gives no when-not conditions and names no alternative among the many trust/Bittensor siblings. The usage signal is present but thin.

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 settle read-only, idempotent and non-destructive, so the low bar is met; the description goes further by disclosing that execution is paper with modeled fees while engine decisions are real, a caveat that materially changes how an agent should present the PnL numbers. It doesn't mention freshness/refresh cadence or rate limits, keeping it out of the top band.

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 what the tool returns before the caveats. Every sentence carries information except 'Not investment advice', which is arguably boilerplate but defensible for a financial signal tool.

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

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

With an output schema present, return-shape explanation is optional and the description supplies it anyway; with zero params and full annotation coverage, the remaining burden is light. The one real gap is signal freshness — whether the directional call is polling-live or a snapshot — which an agent would want before quoting it.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. No parameter-level caveats are needed or missing.

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

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

Specific verb-plus-resource: it returns the engine's directional BTC signal, the active position with levels/target/stop, and the live track record, sourced from 'our own live trading engine on Hyperliquid'. That provenance clause implicitly separates it from generic siblings like get_signals or get_trading_decision, though none are named outright.

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

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

The description never states when to prefer this over get_signals or get_trading_decision, nor any precondition or exclusion. The only usage-adjacent content is the 'Not investment advice' disclaimer, which does not help an agent choose between 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 annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds a meaningful data-availability caveat: Base public RPC has no mempool, so pending-transaction data is absent.

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

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

Two sentences, front-loaded with the metrics and then the important caveat. Every clause adds useful information with no repetition or filler.

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

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

For a zero-parameter read tool with an output schema and rich annotations, the description supplies purpose, metrics covered, and the key data limitation. Nothing call-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?

There are zero parameters, so there is no parameter semantics to disambiguate; the rubric baseline for 0 params is 4. The description appropriately avoids inventing parameter details that do not exist.

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

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

It opens with an exact resource and scope, 'Execution health on Base,' and enumerates RPC latency, agent activity, and gas trend. This clearly distinguishes it from network-health siblings such as get_bittensor_network_health and from token-safety tools.

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

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

The description implies use for Base execution-health diagnostics and notes one exclusion: no pending-transaction data. However, it does not explicitly say when to use this instead of siblings such as get_bittensor_network_health or get_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 readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds real context beyond that: the data provenance (own collector, ~1350 alerts/day) and the three possible ACO decisions (WATCH_ENTER / EXIT_IF_LONG / AVOID), which tells the agent this is a pre-computed signal feed rather than raw on-chain data. It does not mention rate limits, pagination, or behavior when no alerts match, keeping 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-loaded with the core purpose and data source, then a compact Args block — no wasted sentences. The '(1350+ alerts/day)' figure and the disclaimer are mildly promotional but arguably earn their place for a financial-signal tool.

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

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

An output schema exists, so return-value explanation is not required, and the description still names the key fields. Provenance, decision vocabulary, and both parameters with their ranges/enums are covered. Missing only the semantic meaning of the alert_type values and what an empty result looks like.

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

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

Schema description coverage is 0%, so the description carries the burden and largely succeeds: it gives the minutes lookback range (5-720), which the schema's bare integer does not, and enumerates the five alert_type values the schema omits entirely. What it does not do is explain what each alert_type means (ignition vs sudden_flow vs pre_pump), so an agent still guesses which filter to pick.

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

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

Specific verb+resource: 'Returns recent alerts' from a named pump.fun/Raydium behavioral collector, plus the exact fields returned (flow multiplier, smart-buyer count, per-alert decision). An agent knows precisely what data comes back. It does not explicitly differentiate from plausible siblings like get_signals, get_smart_money_feed or get_trading_decision, 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?

Usage is only implied by 'Live pump.fun detection alerts' — there is no statement of when to prefer this over get_signals / get_smart_money_feed / get_trading_decision, and no exclusions. The 'Not investment advice' line is a disclaimer, not routing guidance. An agent can infer the domain but must guess at boundaries with siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds the scope distinction (aggregate vs per-agent) but says nothing extra about freshness, sampling, or data sources beyond annotations, and itemizing returned fields is partly redundant with 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?

Two sentences: the first front-loads what is returned, the second handles routing to alternatives. No filler, no repetition of the title, and the most decision-relevant information comes first.

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?

Zero parameters, an output schema that documents return values, and annotations that carry the safety profile mean the description only needed to supply scope and routing — which it does. Nothing an agent needs before calling this zero-arg read is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the description misleads about inputs, and the absence of arguments is consistent with the empty schema.

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

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

States a specific verb and resource ('ERC-8004 ReputationRegistry aggregate') and enumerates the returned metrics: feedback count, agents with reputation, unique reviewers, average score. It also explicitly contrasts itself with the per-agent siblings get_trust_forensics and check_agent_trust, so an agent can pick it 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 a positive usage cue ('use it for market context') and a negative one plus alternatives ('per-agent answers come from get_trust_forensics or check_agent_trust'). The routing condition between aggregate and per-agent views 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 cover read-only, idempotent and non-destructive, and the description adds real context beyond them: results are delayed by a public delay, amounts are in raw token units with USD only for USDC, and payloads can be independently verified. It omits pagination/ordering behavior, which is the main missing trait.

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 clauses, front-loaded with the resource and its delay constraint, with no filler. Slightly telegraphic rather than fully structured, but nothing is wasted.

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

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

Output schema exists, so return shape needn't be described, and the unit/currency caveat is valuable. Still, for a filtered-list tool with two undocumented parameters and no note on ordering or result caps, an agent lacks enough to tune limit and min_confidence confidently.

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

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

Schema description coverage is 0% and neither parameter is explained in the description. Critically, min_confidence (default 0.7) has an undocumented scale and nothing indicates what limit counts or caps, so an agent must guess at both.

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 the specific resource (publicly published trading signals) and an important scope qualifier (the public delay is enforced), which distinguishes it from real-time feeds like get_smart_money_feed or get_pump_alerts. It doesn't explicitly name a sibling it displaces, 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?

Points to verify_signal_proof as the follow-up verification path, which is genuine routing guidance. However, it never says when to call this instead of other signal-adjacent siblings (get_btc_grid_signal, get_smart_money_feed, get_trading_decision), leaving the selection decision largely implicit.

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

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the safety profile is covered; the description adds genuinely new operational context — a ~60s polling cadence, the REST endpoint and its $0.02 cost, and a 'not investment advice' disclaimer. The recurring per-call price is exactly the kind of cost/rate information annotations cannot express. It does not mention rate limits or payload size limits beyond the alert cap.

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 identity and the polling cadence before payload detail; the args block is clean and scannable. Slightly dense with marketing phrasing ('one payload for a polling loop') but 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?

An output schema exists, so return values needn't be spelled out, yet the description usefully previews payload composition and the decision labels (WATCH_ENTER / EXIT_IF_LONG / STAND_ASIDE) an agent will need to interpret. Cost, cadence, and both parameter ranges are covered; only default values and empty-result handling are 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 0%, so the description carries the full burden and largely meets it: it documents both parameters with meaning plus valid ranges ('minutes: alert lookback window (5-720)', 'limit: max alerts in the feed (1-50)') that the schema lacks. It omits the defaults (60 and 15) and any behavioral note about what happens when the window contains no alerts.

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: a LIVE smart-money feed for Solana meme trading, and enumerates the payload contents (pump ignitions with SOL flow and unique-wallet counts, per-alert decisions, smart-buyer profiles, active whales). It is clearly the composite/aggregate view rather than a single-signal tool, though it never names the nearby single-purpose siblings (get_pump_alerts, get_top_smart_buyers, get_trading_decision) it bundles.

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 concrete usage context: 'designed to sit inside your trading decision loop (call every ~60s)', which tells the agent this is a polling tool and what cadence to expect. No explicit when-not guidance or named alternatives, so the agent must infer that narrower siblings exist for targeted queries.

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, so the safety profile is covered. The description adds that results are ordered by trust quality and that the tier filter is a >= comparison with an all-inclusive default, but says nothing about pagination, result size, or ordering direction.

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: the ranking/filter scope first, then the follow-up routing to check_agent_trust. No filler and nothing buried.

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 described. However, for a listing tool the missing pieces — how 'limit' behaves and whether higher tiers come first — are exactly what an agent needs to page and interpret results, and neither is 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 0%, so the description carries the burden; it partially compensates by explaining tier as a '>=' threshold with a default of all. The limit parameter (default 20) and any page-size/maximum behavior are left completely undocumented.

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 — lists Solana 8004 agents ranked/filtered by ATOM trust quality — and names the sibling (check_agent_trust) it is not meant to replace. The domain jargon ('8004 agents', 'ATOM trust quality') is unexplained, but the operation itself 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?

Explicitly prescribes the workflow: build a candidate list here, then drill into a single agent with check_agent_trust. That routes the agent away from the wrong sibling, though it doesn't state when the tool should be skipped entirely (e.g., when a specific agent is already known).

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, non-destructive behavior; the description adds domain behavior by stating which forensic signals it computes and what question it answers. It does not discuss data freshness, sourcing, or limits, preventing 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?

Two sentences, front-loaded with the forensic signals and ending with the decision it supports. There is no filler.

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

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

An output schema exists and annotations cover the safety profile, so return values and read-only semantics need not be in prose. However, for a tool with two undocumented inputs, the description is not complete enough to tell an agent how to configure `risk` and `limit`.

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

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

Schema description coverage is 0%, and the description never explains the `risk` or `limit` parameters. The phrase 'risk flags' refers to an output metric, not the input filter, so the description does not compensate for the undocumented 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 names a specific domain and concrete outputs (reviewer concentration, ghost-reviewer ratio, burst detection, risk flags) and frames the purpose as distinguishing earned from manufactured reputation. It does not explicitly distinguish itself from nearby tools such as get_trust_forensics or get_solana_trust_summary, so it is clear but not fully differentiated.

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

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

It gives a clear use case: checking whether a Solana agent's reputation is earned or manufactured. It lacks when-not guidance and does not name alternatives among the many trust/reputation siblings, so it provides context but no exclusions.

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

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

The annotations already establish that this is a read-only, idempotent, non-destructive, open-world operation. The description adds useful behavioral context by identifying the data source as 8004-Solana mainnet and scoping the result as an aggregate market overview rather than per-agent verdicts.

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 are used efficiently: the first states what the summary contains and the second routes the agent to alternatives. The scope is front-loaded 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 zero parameters, an output schema, and annotations covering safety, the description provides enough context to invoke the tool correctly. It explains the aggregate scope and points to sibling tools for the common adjacent use cases.

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?

This tool takes zero parameters, so there are no parameter semantics to explain. The baseline for a no-parameter tool applies, and the description correctly avoids inventing or discussing nonexistent inputs.

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 and scope: an 8004-Solana mainnet trust summary covering agents, feedbacks, and trust-tier distribution. It also distinguishes this market-overview tool from per-agent and forensic-analysis siblings, so an agent can select 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?

It explicitly says to use this for a market overview and redirects per-agent verdicts to check_agent_trust with solana_asset and feedback analysis to get_solana_forensics. Both when-to-use and alternatives are named directly.

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

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

Annotations already cover read-only, idempotent, and open-world behavior, so the description only needs to add context. It does so usefully by disclosing the scoring formula (winrate x volume) and the filtering semantics of min_score, which is genuine behavioral 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 compact sentences, front-loaded with the resource and scope, then the use case. No filler, though 'Who buys before the pump' is colorful rather than operational.

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 needn't be described. However, for a three-parameter discovery tool with zero schema coverage, the description should at least clarify the sort order and what min_trades/limit control to be fully actionable.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains min_score's meaning but says nothing about limit (result cap?) or min_trades (a trade-count floor that is central to how 'smart' is qualified), leaving two of three parameters undocumented.

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 the ranking basis ('Solana wallets with the best winrate x volume', filtered by smart_score >= min_score), which is far more informative than the title. It does not name or contrast with the closest sibling, get_smart_money_feed, so an agent must infer 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?

The phrase 'the source for copy-trading signals' implies the use case, and the threshold reference implies a discovery/ranking scenario. But there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as get_smart_money_feed or get_wallet_profile.

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?

Beyond annotations, the description discloses important behavioral context: decisions come from live engines, execution is paper-only, PnL is paper with modeled fees, and the output is not investment advice. That materially helps an agent interpret and trust 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?

The description is front-loaded with the main usage instruction and return meaning, then adds the paper-execution caveat and argument list. It is appropriately sized and every sentence adds useful information.

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

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

Given an existing output schema and informative annotations, the description is largely complete: it explains when to call, what verdicts look like, and the paper-execution caveat. The main remaining gap is lack of explicit sibling differentiation or alternatives.

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

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

Schema description coverage is 0%, and the only parameter is asset. The description compensates well by enumerating supported values: btc, eth, hype, sol, uni, zec, pine_btc. It does not mention the default behavior or case sensitivity, but the core semantics are supplied.

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 specific resource and output: an actionable execution verdict per asset from live Hyperliquid engines, with ENTER_LONG / ENTER_SHORT / WAIT and entry/exit details. It is not a tautology, but it does not explicitly distinguish this tool from potentially related siblings such as get_signals or get_btc_grid_signal.

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 a clear usage condition: 'Call it before entering crypto perps.' However, it does not state when not to use it or name alternative sibling tools for signal or execution checks.

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, so the description earns credit for adding semantic context the annotations can't: it defines what "volume" means (indexed USDC transfers, explicitly not PnL or AUM) and states the limit bounds. That metric definition is essential for interpreting results and is not recoverable from 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?

Three short sentences, front-loaded with the resource and ranking basis, then the disambiguation of "volume," then the parameter bound. Nothing is redundant and every sentence carries information.

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

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

An output schema exists, so return shape needn't be described; the description covers scope (Base), metric semantics, and parameter bounds. For a single-parameter read-only ranking tool, nothing an agent needs 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 0%, so the description must compensate. It does, by stating "Limit 1-20" — giving both the valid range and the notion of a bounded page size that the bare integer schema omits. It doesn't restate the default of 5, but the range is the missing key detail.

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

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

States a specific resource (on-chain AI agents on Base) and an explicit ranking basis (indexed USDC transfer volume and transaction count), which lets an agent distinguish it from sibling rankings like get_bazaar_organic_ranking or get_top_smart_buyers. No sibling is named directly, so it falls short of a 5.

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

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

"Use it to discover which agents actually move money" gives a positive usage cue, but there is no when-not guidance and no named alternative for adjacent needs (e.g., trust checks or Solana agent discovery). Usage is implied rather than fully routed.

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 annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds analytic context by naming the segmentation and detection methods behind the output, but says nothing about data freshness, chain scope, or cost/latency. Adequate given annotation coverage, not rich.

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

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

Three tight sentences with no filler: the core function comes first, then the decision framing, then the parameter hint and sibling redirect. The metric list is dense with domain jargon (ERC-8004, Herfindahl) but each term does real discriminating work rather than being decoration.

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 the description need not explain return values, and annotations carry the safety profile. What remains slightly incomplete is the undocumented limit parameter and the absence of any indication of data source or refresh cadence for an open-world forensics 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 coverage is 0% and the schema declares no enum, so 'Filter risk: high | medium | low' is genuinely valuable compensation — it supplies the allowed values the schema omits. However, the second parameter (limit, default 50) is never mentioned, leaving half the inputs undocumented.

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 combination — Sybil forensics on ERC-8004 feedback — and enumerates the concrete signals it computes (Herfindahl concentration, ghost-reviewer ratio, burst detection, vouch vs earned segmentation). It explicitly distinguishes itself from should_i_pay, though it does not separate itself from other trust/reputation siblings such as check_agent_trust or reputation_origin.

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 use case ('check whether an agent's feedback is bought') and routes the pay-or-not decision to should_i_pay, which is an explicit alternative. There are no explicit exclusions or preconditions beyond that, so it falls short of a full 5.

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/openWorld, so the safety profile is covered. The description adds genuinely new behavior context: the dataset size ('87k+ profiles') signals coverage limits, and 'pump.fun behavioral data' discloses the data provenance an agent needs to judge trust in the result. It omits freshness/staleness and what happens for an unindexed wallet.

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 dense sentences with zero filler: the payload list comes first, then scope, then the decision-support use case. Every clause carries information.

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

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

An output schema exists, so return values needn't be explained, and the description still summarizes the key fields plus dataset scope and intended use. The remaining gap is input-format and coverage-miss behavior, minor for a single-parameter read tool with full annotations.

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

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

Schema description coverage is 0% for the single 'wallet' parameter, so the description must carry the load. Saying 'for a Solana wallet' implies a Solana address is expected, but no format (base58) or indexing/validity caveat is given, which matters because only 87k wallets are covered.

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 ('Wallet intelligence profile for a Solana wallet') and enumerates the payload (winrate, type, smart_score, volume, average hold, serial-creator flag). It does not explicitly distinguish itself from adjacent siblings like check_wallet_reputation or get_solana_trust_summary, so the agent must infer the split.

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 concrete trigger: 'Use it before copying a trade to check who is behind it.' That is real usage context rather than a bare restatement. However, it names no exclusions and no alternative tool for wallet trust checks, leaving the sibling decision to the agent.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing the verdict taxonomy, the mapped action codes, the specific red flags and measured signals returned, the unknown-mint fallback ('never safe'), and the REST cost ($0.02). The failure-mode guarantee is exactly the kind of behavior an agent cannot infer from annotations or 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?

Decision question is front-loaded, then verdicts, then outputs, then the REST/cost footer — a sensible priority order with no filler. The parenthetical red-flag and signal lists are dense but each item is informative, so the length is earned rather than 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?

Even though an output schema exists, the description still tells the agent what verdicts and actions mean and how unknown mints are handled, plus the underlying REST route and price. For a single-parameter, read-only verdict tool, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 0%, so the description must carry the parameter; it does by describing 'mint' as a Solana token mint address, fixing the chain and identifier type. It stops short of format guidance (base58, case sensitivity) or example values, so not a 5.

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?

Opens with a decision-framed verb + resource ('Is this Solana token a rug or safe to buy?') and immediately states the deliverable (binary safety verdict SAFE / RISKY / RUG / UNKNOWN). The Solana qualifier plus the named alternatives (check_base_token_safety, get_solana_trust_summary) make it distinguishable from siblings without opening their 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?

Explicit trigger: 'call it before buying or paying for any Solana meme token,' which is a concrete pre-trade checkpoint. No explicit when-not or named sibling to use instead (e.g., for Base tokens or for wallet-level checks), so it stops short of a 5.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world, so the safety profile is free. The description adds genuinely useful context beyond that: the verdict categories returned, the underlying signals, the sybil-manufactured-ratings interpretation, and the $0.02 cost — cost is a real behavioral trait annotations cannot express.

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 question and the verdict vocabulary, then evidence, then the sybil rationale, then access details. Dense and mostly waste-free, though the 'Most Base ERC-8004 reviewer activity shows coordinated sybil behavior' line leans promotional and repeats the manufactured-ratings 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 isn't strictly needed, yet the description still pre-frames the verdict enum and evidence metrics. With only two simple parameters and full annotation coverage, the only missing piece is the identifier exclusivity/requiredness rule.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does define both parameters: agent_id as an ERC-8004 agent id and solana_asset as a Solana 8004 agent pubkey, framed as an 'alternative'. It doesn't spell out that exactly one is required (both schema fields are optional with default 0/""), which is the remaining gap.

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-like question (is reputation earned or bought) and the concrete output vocabulary (ORGANIC / BURST / FARM / MIXED / NONE) plus the evidence fields. It also explicitly positions itself against the sibling should_i_pay, so an agent can pick it 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?

States the triggering context clearly: it is 'the follow-up to should_i_pay that explains WHY a verdict is CAUTION', which tells the agent the sequencing and the alternative. It stops short of stating when not to use it (e.g. before any should_i_pay verdict exists) or that at least one identifier is 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 readOnly/idempotent/non-destructive, so the safety bar is met; the description adds material context the annotations cannot convey: a $0.01 call cost, the evidence basis (ERC-8004 feedbacks, sybil forensics, liveness SLA), the multichain scope including Solana, and the REST endpoint. That is a genuine value-add 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?

The decision, cost justification, and routing alternative are front-loaded and the Args list is compact. The "pay $0.01 to avoid paying a scammer $N" framing and the REST line are slightly promotional but still earn their space as cost/endpoint facts.

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, yet the description still names the decision enum and the expected-loss framing an agent needs to act. For a 3-parameter, zero-required decision tool, nothing material 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 0%, so the description carries the full burden, and its Args section does define all three parameters, including that solana_asset is a Solana alternative to agent_id. It stops short of stating mutual exclusivity/fallback behavior given both default to 0/"" and gives no bounds on amount_usd, so it is strong but not complete.

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 decision resource ("pre-payment decision for any A2A payment") with a concrete question form and concrete outputs (PAY / CAUTION / SKIP). It also explicitly distinguishes itself from the nearest sibling, agent_interact_gate, so an agent can route 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 an explicit trigger ("Call it before every payment to an unknown agent") and an explicit exclusion with the named alternative ("Use agent_interact_gate instead when the question is broader than payment"). Both when-to-use and when-not-to-use are covered.

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

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

Annotations already establish that this is a safe, read-only, idempotent operation. The description adds meaningful behavioral context beyond them: it verifies an ed25519 signature, returns validity plus a key ID, and clearly scopes the proof to origin and integrity rather than correctness or profitability.

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

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

Three short sentences, front-loaded with the action and result, followed by a precise caveat. Every sentence adds useful information 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?

Output schema covers the return value, annotations cover safety semantics, and the description usefully explains the proof's limits. The main gap is the opaque nested 'signed_payload' parameter: with no schema descriptions and no description detail, the definition is not fully complete for constructing a correct call.

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

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

There is one required parameter, 'signed_payload', but schema description coverage is 0% and the nested object allows arbitrary properties. The description says the payload is verified 'against its contents' but gives no indication of the expected structure, fields, or signing format, so an agent has little guidance on what to supply.

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 ('Verify an ed25519 Proof-of-Signal payload against its contents') and explicitly limits the meaning of the result: origin and integrity, not correctness or profitability. That caveat also separates it from sibling trust, reputation, and trading-decision 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 implied use case is checking authenticity of a signal payload, and the caveat hints that profitability or correctness requires other tools. However, it never says explicitly when to call this versus siblings like check_agent_trust or get_trading_decision, nor does it state 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?

Beyond the readOnly/idempotent annotations, it discloses that the endpoint is metered ($0.02), that it leverages a daily sweep of the entire x402 catalog (data freshness/coverage), and that an unknown seller returns UNKNOWN rather than erroring. It even explains the heuristic behind the labels (calls/payer ~1.0 vs >= 3), which is genuine behavioral context the annotations cannot express.

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 core verdict/usage information is front-loaded in the first two sentences, and the classification heuristic is compact. The trailing REST endpoint and price are useful but slightly disjoint from the MCP calling path, costing a bit of tightness.

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 enumerating return fields was optional, yet the description still orients the agent to the key signals. With only two optional params and full annotation coverage, the remaining gap is minor: no guidance on what happens if neither resource nor domain is provided.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it does supply meaning and examples for both resource (full x402 resource URL) and domain (bare host). It does not state precedence when both are supplied, nor that both being empty is invalid, which is the one gap.

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 concrete question and states exactly what the tool produces: a verdict across REAL/EMERGING/FARM/DEAD/UNKNOWN plus an action. It is clearly distinguished from the sibling should_i_pay by audience (x402 seller vs. agent), so an agent can route between them 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?

It gives an explicit trigger ('Call it before your agent pays an unknown x402 endpoint') and names the alternative with its own condition ('For an agent (not an x402 seller) use should_i_pay'). Both the when-to-use and the when-to-use-something-else are stated.

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