RNWY — AI Agent Trust Intelligence

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about rate limits, authentication requirements, error conditions, data sources, or what constitutes a valid address beyond the schema's '0x...' hint. The 'uncheatable signal' claim adds some context about reliability but doesn't explain implementation details or limitations.

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 extremely concise and front-loaded: the first sentence states the complete purpose, and the second adds valuable context about reliability. Every word earns its place with zero wasted text. The two-sentence structure is efficient and immediately informative.

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 lookup tool with two parameters and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should ideally provide more behavioral context about what the age calculation represents (first transaction? creation date?), how it's computed, and what the return value looks like. The current description meets basic requirements but leaves gaps in operational understanding.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'address' generically but provides no additional syntax, format, or validation details. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Look up wallet age in days for any address.' It specifies both the verb ('look up') and the resource ('wallet age'), and distinguishes itself from siblings by emphasizing its unique value proposition: 'The uncheatable signal; time cannot be faked.' This makes it clear this tool provides a specific, reliable metric not available through other 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 provides no guidance on when to use this tool versus the seven sibling tools. While it hints at the tool's unique value ('uncheatable signal'), it doesn't explicitly state when this age lookup is appropriate versus using commerce_stats, network_stats, trust_check, or other alternatives. There's no mention of prerequisites, limitations, or comparative use cases.

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 implies a read-only operation by describing data retrieval, but does not disclose behavioral traits such as authentication requirements, rate limits, error conditions, or response format. The description lacks critical details needed for safe and effective use.

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 concise and front-loaded, listing key metrics in the first sentence and protocol coverage in the second. It avoids unnecessary words, though it could be slightly more structured (e.g., clarifying parameter relationships).

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 annotations and no output schema, the description is incomplete. It fails to explain return values, error handling, or behavioral constraints, leaving significant gaps for a tool with 4 parameters and complex data retrieval. More context is needed for effective agent use.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal value by hinting at usage contexts (e.g., 'Use with chain and registry for linked agent commerce data' is covered in schema), but does not provide additional semantics beyond what the schema offers. 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 retrieves commerce activity statistics (job count, unique counterparties, repeat client rate, total earnings) for agents or addresses, covering specific protocols. It specifies the resource (commerce activity) and scope (Olas Mechs and Virtuals ACP protocols), but does not explicitly differentiate from sibling tools like 'compare_agents' or 'network_stats'.

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 no guidance on when to use this tool versus alternatives like 'compare_agents' or 'network_stats'. It mentions coverage of specific protocols but does not indicate prerequisites, exclusions, or comparative contexts for tool selection among 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions ranking by score and reviewer quality summaries, which adds some context beyond the input schema. However, it lacks critical details such as what the scores represent, how ranking is determined, whether this is a read-only or mutating operation, potential rate limits, or authentication requirements. For a comparison tool with zero annotation coverage, this is insufficient.

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, efficient sentence that front-loads the core purpose. It avoids unnecessary words and gets straight to the point, though it could be slightly more structured by separating key components (e.g., comparison, ranking, summary). Every part of the sentence contributes to understanding the tool's function.

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 complexity of comparing multiple agents with ranking and summaries, the description is minimally adequate. No output schema exists, so the description doesn't explain return values, which is a gap. With no annotations and 100% schema coverage, the description provides basic purpose but lacks depth on behavior, output, or integration with sibling tools. It meets a bare minimum but leaves significant context uncovered.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('agents' and 'threshold') with descriptions and an example. The description adds no additional meaning or semantics beyond what the schema provides, such as explaining the format of 'chain:id pairs' or the implications of the threshold. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: performing a 'side-by-side trust comparison' of agents, ranking them by score, and providing reviewer quality summaries. It specifies the resource (agents) and scope (2-10 agents), making the verb+resource relationship explicit. However, it doesn't distinguish this tool from sibling tools like 'trust_check' or 'reviewer_analysis', which might have overlapping functionality.

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'trust_check' or 'reviewer_analysis', nor does it specify prerequisites, exclusions, or appropriate contexts. The only implied usage is from the purpose statement, but no explicit when/when-not instructions are given.

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 of behavioral disclosure. It describes what data is returned but doesn't cover critical aspects like whether this is a read-only operation, potential performance impacts, rate limits, authentication requirements, or data freshness. For a tool querying 150,000+ agents, this lack of operational context is a significant gap.

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, well-structured sentence that efficiently communicates the tool's scope and key metrics. It front-loads the purpose ('Network-wide statistics') and lists specific data points without unnecessary elaboration. Every word earns its place, making it highly concise and effective.

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 complexity of querying 150,000+ agents and the absence of both annotations and an output schema, the description is incomplete. It doesn't explain the format or structure of the returned statistics, potential limitations, or how the data is aggregated. For a statistical tool with no structured output documentation, this leaves too much undefined for reliable agent use.

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 has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't waste space discussing parameters, maintaining focus on the tool's purpose and output scope. This meets the baseline for parameterless tools.

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: to provide network-wide statistics across multiple dimensions (total agents by registry, chain distribution, commerce job counts, trust score tier distribution). It specifies the scope (150,000+ indexed agents) and distinguishes it from siblings like commerce_stats by covering broader network metrics rather than just commerce. However, it doesn't explicitly name a verb like 'retrieve' or 'get', though 'statistics' implies a read operation.

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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools like commerce_stats or compare_agents. The user must infer usage based on the statistical scope alone, which is insufficient for informed tool selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analyzing wallet ages and detecting sybil patterns, but doesn't specify what the output looks like (e.g., a report, scores, or clusters), whether it's read-only or mutative (implied read-only but not stated), or any constraints like rate limits or authentication needs. This leaves significant gaps for a tool performing analysis.

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

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

The description is appropriately sized and front-loaded, consisting of two concise sentences that directly state the tool's purpose and key functionality. Every sentence earns its place by specifying the analysis scope and the patterns detected, with zero waste or 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's complexity (analyzing multiple reviewers for patterns), lack of annotations, and no output schema, the description is minimally adequate but incomplete. It covers the purpose and high-level behavior but omits critical details like output format, error conditions, or performance characteristics, which are needed for effective use by an AI agent.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('id' as Agent ID, 'chain' as Chain slug). The description adds no additional meaning beyond what the schema provides, such as format examples or context for how these parameters influence the analysis. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('analyze', 'detects') and resources ('wallet ages of every reviewer who left feedback on an agent', 'sybil patterns like same-day wallet creation clusters'). It distinguishes itself from siblings like 'address_age' (which might analyze individual addresses) or 'reviewer_wallet' (which might focus on wallet details rather than age patterns) by emphasizing pattern detection across multiple reviewers.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing reviewer data), exclusions (e.g., not for single reviewers), or comparisons to siblings like 'compare_agents' (which might compare agents) or 'risk_terms' (which might assess different risks). Usage is implied only through the purpose statement.

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 of behavioral disclosure. It mentions the tool 'shows how this wallet behaves when reviewing agents,' implying it's a read-only analysis tool, but it doesn't specify whether it requires authentication, has rate limits, returns real-time or historical data, or what the output format looks like. For a tool with no annotations, this leaves significant behavioral gaps.

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, efficient sentence that front-loads key information ('behavior profile' with specific metrics). It avoids redundancy and waste, though it could be slightly more structured (e.g., by separating purpose from context). Overall, it's appropriately concise for 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?

Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on output format, behavioral constraints (e.g., data freshness, access limits), and differentiation from siblings. Without an output schema, the description should at least hint at what's returned (e.g., metrics, scores, lists), but it doesn't, leaving the agent with insufficient context for effective use.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (address, chain, summary) clearly. The description adds no additional meaning about parameters beyond what's in the schema—it doesn't explain how 'summary' affects the output or provide context for 'chain' and 'address' usage. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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 the tool provides a 'behavior profile' for a reviewer wallet with specific metrics (velocity, sweep patterns, score clustering, sybil signals) across the ERC-8004 ecosystem. This is more specific than just restating the name, but it doesn't clearly distinguish this tool from sibling tools like 'reviewer_analysis' or 'trust_check'—both of which could involve analyzing wallet behavior. The purpose is somewhat vague about what exactly the tool outputs versus its siblings.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'reviewer_analysis' or 'trust_check', nor does it specify prerequisites, contexts, or exclusions for usage. Without such information, an agent must infer usage based on tool names alone, which is insufficient for clear decision-making.

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 provided, the description carries full burden and does well by disclosing what the tool returns (risk tier, raw trust signals, data coverage, methodology reference) and linking to full methodology. However, it doesn't mention rate limits, authentication needs, or potential limitations of the risk assessment.

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 efficiently structured with two sentences: one explaining what it returns and its purpose, and another specifying target users and providing methodology reference. Every sentence adds value with zero wasted words.

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

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

For a tool with no annotations and no output schema, the description does well by explaining what information is returned and providing a methodology link. However, it could be more complete by detailing the format of returned data or potential error conditions, given the complexity of risk assessment.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.

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

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

The description clearly states the tool's purpose with specific verbs ('Returns risk tier...') and resources ('counterparty risk intelligence for any agent'), distinguishing it from siblings like 'trust_check' or 'compare_agents' by focusing on comprehensive risk assessment rather than simple verification or comparison.

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

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

Explicitly states when to use this tool: 'Designed for marketplace operators and escrow providers setting transaction parameters before a deal.' This provides clear context and distinguishes it from siblings that might serve different purposes like checking address age or commerce stats.

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 of behavioral disclosure. It mentions the output ('Returns score, tier, badges, and reasoning') but lacks details on permissions, rate limits, error handling, or whether this is a read-only or mutating operation. For a trust assessment tool with zero annotation coverage, this is a significant gap in transparency.

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 concise and front-loaded, stating the core purpose in the first clause. Both sentences are relevant, with the second adding output details. However, it could be slightly more structured by explicitly separating purpose from output or usage context.

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

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

Given the complexity of a trust assessment tool with 4 parameters and no annotations or output schema, the description is moderately complete. It covers the purpose and output but lacks behavioral details, usage guidelines, and deeper parameter context. Without an output schema, it should ideally explain more about the return values like score ranges or badge types.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal value beyond the schema: it implies the tool uses 'id' and 'chain' for the verdict and mentions registries, but doesn't explain parameter interactions or semantics like how 'threshold' affects the pass/fail outcome. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Pass/fail trust verdict for any AI agent across ERC-8004, Olas, or Virtuals registries.' It specifies the verb ('Pass/fail trust verdict'), resource ('AI agent'), and scope ('across ERC-8004, Olas, or Virtuals registries'). However, it doesn't explicitly differentiate from sibling tools like 'compare_agents' or 'risk_terms', which might involve similar trust or risk assessments.

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 no guidance on when to use this tool versus alternatives. It mentions the registries covered but doesn't specify use cases, prerequisites, or exclusions. For example, it doesn't clarify if this is for initial screening, ongoing monitoring, or comparison with other tools like 'compare_agents' or 'risk_terms'.

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