agentrank

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

No annotations exist, so the description carries the full burden. It fully discloses the tool's behavioral traits: returns a 0-1000 AgentRank, verified flag, USDC settled, payer count, verdict; based on real on-chain USDC settlement on Base (sybil-resistant, not gameable); collusion-tested; scores recompute continuously; advises against caching. There is no contradiction with annotations.

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

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

The description is front-loaded with the core purpose, then provides detailed context on usage, output, and technical guarantees. Every sentence adds value, though it is somewhat lengthy. A slight reduction in the collusion-test details could improve conciseness without losing essential 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 the single parameter, no output schema, and no annotations, the description is remarkably complete. It covers purpose, usage, output details, data source, trustworthiness guarantees, and even includes statistical context and caching advice. No critical gaps are identified.

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

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

The description does not add meaning beyond the input schema for the single parameter 'query', which is already described clearly in the schema as 'A wallet address (0x...) or a domain (e.g. blockrun.ai)'. Schema coverage is 100%, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose ('Verify a counterparty before you pay it'), specifies what it checks (real, trustworthy, settlement-backed vs scam, ghost, rug), and details the output (AgentRank, verified flag, etc.). It distinguishes itself from siblings by mentioning use cases like settling x402 payments or trusting an agent, which aligns with the sibling context.

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 guidance is given on when to use the tool: 'Use before settling an x402 payment, extending credit, or trusting another agent.' It also provides context with statistics (78% are unverifiable ghosts). However, it does not explicitly state when NOT to use it or mention alternatives among siblings, which would improve the score.

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?

With no annotations, the description carries the behavioral burden. It adds that the classification is 'de-noised' and includes a 'provenance anchor' for verification, but does not disclose error handling, idempotency, or potential side effects. Barely adequate for a read-only classification.

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 covering purpose and value proposition. Some fluff (e.g., compute shortcut) but overall efficient. Could be more crisp.

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 simple one-parameter tool with no output schema, the description covers core function and usage but omits return format and error cases. Leaves the agent wondering about the exact response structure.

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

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

The single parameter 'address' is already well-described in the schema (0x + 40 hex). The description adds no further meaning, so baseline 3 is appropriate.

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

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

The description clearly states the tool classifies an x402 address into five categories (real service, buyer, rail, treasury sink, or dust). It uses a specific verb and resource, and the purpose 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 advises 'Use before paying any x402 address to avoid paying a rail, a treasury, or dust,' providing clear when-to-use guidance. Does not explicitly state alternatives, but the context of sibling tools implies differentiation.

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?

No annotations are provided, so the description carries the burden. It describes the returned data (reputation, classification, safety, rug-risk, recommendation, signed receipt) but does not disclose behavioral traits like read-only status, permissions required, or side effects. The detailed output description gives some behavioral insight, but omits important operational context.

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

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

The description is a single, dense paragraph that effectively front-loads the core purpose (first sentence) and then lists key outputs. It is concise with no wasted words, though it could benefit from slight structuring (e.g., bullet points) for readability.

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

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

Despite lacking an output schema, the description thoroughly explains all major outputs: reputation (AgentRank), census classification, counterparty safety, token rug-risk, pay/caution recommendation, and signed receipt. This provides complete context for a complex tool, covering what an agent needs to decide.

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

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

The single parameter 'query' is fully described in the schema as 'A wallet address (0x...) or domain to fully check.' With 100% schema coverage, the description adds no additional meaning beyond restating the purpose. Baseline 3 is appropriate.

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

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

The description clearly defines the tool as a comprehensive counterparty check combining reputation, census classification, safety, rug-risk, and recommendation. It uses specific terms like 'AgentRank 0-1000' and 'real USDC settled', and the phrase 'whole counterparty picture' distinguishes it from sibling tools which are more specific.

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

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

The description explicitly states 'before you pay' and 'one call to decide whether to trust or pay any x402 counterparty', indicating when to use it. While it does not explicitly mention when not to use it or name alternatives, the sibling tools (e.g., check_agent_trust, classify_x402_address) imply that this tool is for comprehensive assessment, leaving specific checks to others.

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?

No annotations are provided, so the description carries full burden. It discloses return values but does not mention side effects, authentication needs, or rate limits. Some behavioral aspects like whether the check is recorded are omitted.

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

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

The description is two sentences with no wasted words. It front-loads purpose and use case, then efficiently covers parameters and returns.

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

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

Given no output schema and annotations, the description explains purpose, use case, and returns fairly completely. Minor gaps exist, such as explaining the surcharge multiplier or whether checking has side effects.

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

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

Schema coverage is 100%, so description adds little beyond schema. It mentions caller and min_score but not require_verified. It provides usage context but no new details about parameter formats or constraints.

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's purpose as deciding whether to serve or refuse a calling agent based on reputation, using specific verbs and resource. It distinguishes from sibling 'check_agent_trust' by focusing on access control and turning away unwanted callers.

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 provides clear usage context, such as using it to screen callers before doing work. However, it does not explicitly state when not to use it or mention the sibling tool as an alternative.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the data is 'de-noised' and returns a snapshot of the economy. However, it lacks details on whether the tool is read-only, has caching, or rate limits. The description is adequate but not rich in behavioral context.

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 well-structured: it starts with a clear title-like phrase, then enumerates return fields, and ends with a usage hint. It is slightly verbose but every sentence adds value. No redundancy.

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

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

Given the tool has no output schema and no annotations, the description provides a good overview of the returned data. However, it could be more complete by specifying the format or size of the data (e.g., JSON object), or clarifying if the data is paginated. It is adequate but leaves some uncertainty.

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

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

The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters. It adds value by describing the output, which is more relevant than parameter details.

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 that the tool provides a 'de-noised census of the whole x402 agent-payment economy' and lists specific return fields (real-vs-dust ratio, role/flow breakdown, counts). This is a specific verb-resource combination that distinguishes it from sibling tools like check_agent_trust or classify_x402_address.

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

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

The description gives a clear usage context: 'Crawl this to ingest the live economy without re-crawling the ledger.' It implies this tool is a preferred alternative to ledger crawling. However, it does not explicitly state when not to use it or mention alternatives, but the context is strong enough to guide an agent.

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