RNWY Trust Intelligence

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 that the signal is 'uncheatable' and 'time cannot be faked,' which hints at reliability but doesn't cover critical aspects like rate limits, error handling, data sources, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational 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?

The description is concise and front-loaded, with the core purpose stated first: 'Look up wallet age in days for any address.' The second sentence adds value by emphasizing uniqueness. Both sentences earn their place without redundancy, though it could be slightly more structured for 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?

Given the complexity (a lookup tool with no annotations and no output schema), the description is incomplete. It lacks details on what the output looks like (e.g., numeric days, timestamp), error cases, or any behavioral traits. Without annotations or an output schema, the description should provide more context to be fully helpful.

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

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

The schema description coverage is 100%, meaning the input schema already documents both parameters ('chain' and 'address') adequately. The description does not add any parameter-specific details beyond what's in the schema, such as examples or constraints. With high schema coverage, the baseline score is 3, 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 clearly states the tool's purpose: 'Look up wallet age in days for any address.' It specifies the verb ('look up'), resource ('wallet age'), and unit ('days'), making the function unambiguous. However, it does not differentiate from sibling tools like 'reviewer_wallet' or 'trust_check', which might also involve wallet analysis, so it doesn't reach a perfect score.

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 uncheatable signal; time cannot be faked,' which implies a unique value proposition but doesn't specify contexts, prerequisites, or exclusions. Without explicit when/when-not instructions or named alternatives, it offers minimal usage direction.

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 retrieved but lacks critical details: whether this is a read-only operation, if it requires authentication, rate limits, error handling, or data freshness. For a tool with 4 parameters and no 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, listing key metrics in the first sentence and protocols in the second. Every sentence adds value without redundancy. However, it could be slightly more structured by explicitly separating agent vs. address use cases.

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 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral traits like mutability or side effects. For a data retrieval tool with moderate complexity, this leaves the agent under-informed about how to interpret results or handle failures.

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 fully documents all 4 parameters. The description adds minimal value beyond the schema by hinting at usage contexts (e.g., 'Use with chain and registry for linked agent commerce data' and 'Use this for Virtuals ACP lookups'), but it doesn't provide additional syntax, format, or constraint details. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool retrieves commerce activity metrics (job count, unique counterparties, repeat client rate, total earnings) for agents or addresses, covering specific protocols. It uses specific verbs like 'covers' and identifies the resource as commerce data. However, it doesn't explicitly differentiate from sibling tools like 'compare_agents' or 'network_stats', which might also involve agent 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 description provides no guidance on when to use this tool versus alternatives like 'compare_agents' or 'network_stats'. It mentions the protocols covered (Olas Mechs and Virtuals ACP) but doesn't specify use cases, prerequisites, or exclusions. This leaves the agent with minimal context for 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?

With no annotations, the description carries full burden but provides minimal behavioral context. It mentions ranking by score and reviewer quality summaries, but doesn't disclose critical traits like required permissions, rate limits, data sources, or what 'trust' entails. This leaves significant gaps 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 a single, efficient sentence that front-loads key information (comparison scope, ranking, summaries) with zero wasted words. It appropriately sized 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 no annotations and no output schema, the description is incomplete. It lacks details on return values (e.g., format of rankings), error conditions, or behavioral constraints, making it inadequate for a tool with two parameters and trust-related operations.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific information beyond what the schema provides (e.g., format details for 'agents' or implications of 'threshold'), relying entirely on the structured fields.

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 performs a 'side-by-side trust comparison' of agents, specifying the verb ('compare') and resource ('agents'). It distinguishes from siblings like 'trust_check' by indicating multi-agent comparison with ranking and reviewer summaries, though it doesn't explicitly contrast with all 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?

No guidance is provided on when to use this tool versus alternatives like 'trust_check' or 'reviewer_analysis'. The description implies usage for comparing 2-10 agents, but lacks explicit context, prerequisites, or exclusions for 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 must fully convey behavior. It explicitly states the tool returns 'agents owned, trust scores, sybil signals, wallet intelligence, and MCP servers' – a comprehensive set of behavioral traits. However, it does not mention data freshness, caching, or error behavior (e.g., invalid address).

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

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

The description is a single, dense sentence that front-loads the key purpose ('Full operator footprint') and lists returned data types. Every word is necessary; no wasted space.

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 only one parameter and no output schema, the description provides sufficient context for an agent to understand what is returned. However, it could be improved by noting the tool's read-only nature (no side effects) or response format.

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 defines the single parameter. The description does not add meaning beyond the schema (e.g., format validation, address type). Baseline 3 is appropriate given full schema coverage.

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

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

The description uses specific verb 'footprint' and clearly identifies the resource as 'any wallet address'. It enumerates the exact categories of data returned (agents owned, trust scores, sybil signals, wallet intelligence, MCP servers), distinguishing it from sibling tools like 'address_age' or 'trust_check'.

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

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

The description implies usage for getting a comprehensive operator profile but does not explicitly state when to use this tool versus alternatives. Sibling names like 'trust_check' or 'address_age' suggest more specific queries, but no guidance is provided on when to prefer this tool.

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 provided, so description carries full burden. It discloses the signing algorithm (ES256), verifiability via JWKS endpoint with specific kid, and what is returned (risk score, threat findings, signed envelope). This is decent but lacks details like rate limits, authentication needs, or size constraints.

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, each packed with meaningful information. No filler, no repetition. Front-loaded with the key action and output.

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 simple schema (1 param) and no output schema, the description adequately explains the purpose and output. However, it could mention what threat findings look like or typical 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?

Schema description coverage is 100%, so the schema already documents the canonical_id parameter. The description adds no further detail about the parameter beyond what the schema provides, 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?

Description clearly states what the tool does: it produces an ES256-signed attestation for any MCP server, returning risk score, threat findings, and a signed envelope. This distinguishes it from sibling tools which focus on addresses, commerce, agents, etc.

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

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

No explicit guidance on when to use this tool vs alternatives. The description implies it's for getting a signed attestation with security findings, but doesn't say when one might prefer e.g. entity or risk_terms over this.

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 rate limits, authentication requirements, or data freshness. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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?

The description is a single, efficient sentence that front-loads the purpose ('Network-wide statistics') and lists key metrics. There's no wasted text, though it could be slightly more structured (e.g., bullet points) for clarity. Every part of the sentence contributes to understanding the tool's scope.

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 (providing aggregated statistics across a large dataset) and lack of annotations or output schema, the description is moderately complete. It specifies the metrics and scale but doesn't explain the return format, data sources, or update frequency. This is adequate for a read-only stats tool but leaves room for improvement in contextual details.

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, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately focuses on the tool's purpose and output. A baseline of 4 is applied for zero-parameter 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 provides 'Network-wide statistics' and enumerates specific metrics (total agents by registry, chain distribution, commerce job counts, trust score tier distribution) with a scope of '150,000+ indexed agents.' This is a specific verb+resource combination, though it doesn't explicitly differentiate from sibling tools like 'commerce_stats' or 'trust_check'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'commerce_stats' or 'trust_check' for comparison, nor does it specify contexts or exclusions for usage. The agent must infer usage from the tool 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the analysis purpose but doesn't describe what the tool returns (e.g., structured data, risk scores, visualizations), whether it requires specific permissions, rate limits, or computational intensity. The phrase 'detects sybil patterns' implies some algorithmic processing, but details are lacking.

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 in two sentences: the first states the core analysis, and the second specifies the detection focus. Every word earns its place with zero waste, making it easy to parse and understand quickly.

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 sybil detection analysis, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of reviewers with ages, risk scores, or pattern flags), how results are formatted, or any behavioral constraints. For a tool with algorithmic detection, more context is needed 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 both parameters ('id' as Agent ID, 'chain' as Chain slug). The description adds no additional parameter semantics beyond what's in the schema, such as format examples for 'id' or valid chain values. Baseline 3 is appropriate when 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', 'sybil patterns like same-day wallet creation clusters'). It distinguishes from siblings by focusing on reviewer analysis for sybil detection rather than general address age, commerce stats, or network analysis.

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 'address_age', 'reviewer_wallet', or 'trust_check'. It doesn't mention prerequisites, exclusions, or specific contexts where this analysis is most appropriate, leaving the agent to guess based on tool names 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool 'shows' behavior profile but doesn't specify if this is a read-only operation, requires authentication, has rate limits, or what the output format looks like. This is inadequate for a tool that likely involves data retrieval and 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 a single, efficient sentence that front-loads key information about behavior profile and metrics. It avoids unnecessary words, though it could be slightly more structured by explicitly stating the action verb.

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 analyzing wallet behavior across an ecosystem, the description is incomplete. With no annotations and no output schema, it fails to disclose critical behavioral traits (e.g., read-only status, data freshness, error handling) and doesn't explain the return values, making it hard for an agent to use effectively.

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). The description doesn't add any meaning beyond what's in the schema, such as explaining how 'summary' affects the output or providing examples. 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 states the tool provides 'behavior profile' for a reviewer wallet with specific metrics (velocity, sweep patterns, etc.), which gives a general purpose. However, it doesn't specify the exact action verb (e.g., 'retrieve', 'analyze', 'fetch') and doesn't clearly differentiate from sibling tools like 'reviewer_analysis' or 'trust_check', leaving some ambiguity about its unique function.

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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or compare to siblings like 'reviewer_analysis', leaving the agent to guess based on tool names 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?

With no annotations provided, the description carries the full burden. It discloses the tool's behavioral traits: it returns risk intelligence data (not a mutation), includes a methodology reference URL, and targets specific users. However, it doesn't mention rate limits, authentication needs, or potential errors.

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: it starts with the core purpose, lists outputs, specifies target users, and ends with a methodology link. Every sentence adds value without 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 no annotations and no output schema, the description is moderately complete. It explains the tool's purpose, outputs, and use case but lacks details on return format, error handling, or behavioral constraints. For a risk assessment tool with 3 parameters, it's adequate but has gaps.

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 doesn't add specific meaning beyond what the schema provides, such as explaining how agent_id and chain interact or the implications of registry choice. Baseline 3 is appropriate when 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: 'Counterparty risk intelligence for any agent' with specific outputs (risk tier, raw trust signals, data coverage, methodology reference). It distinguishes from siblings by focusing on risk assessment rather than age, commerce, comparison, network, reviewer, or trust checks.

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 context: 'Designed for marketplace operators and escrow providers setting transaction parameters before a deal.' This indicates when to use it (pre-deal risk assessment) but doesn't explicitly state when not to use it or name alternatives 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns 'score, tier, badges, and reasoning', which gives some output context, but lacks critical details like whether this is a read-only operation, if it requires authentication, rate limits, or error handling. For a tool assessing trust with potential security implications, 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 highly concise and front-loaded, consisting of a single sentence that efficiently conveys the core purpose and output. Every word earns its place, with no redundant or vague phrasing.

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 trust assessment across multiple registries, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, performance, or error cases, and while it lists output fields, it doesn't define their meaning or format. This leaves significant gaps for an AI agent to use the tool effectively.

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

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

The schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond implying the tool uses 'id' and 'chain' for the verdict, but it doesn't explain parameter interactions or default behaviors (e.g., default registry). 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 action (pass/fail verdict), target (AI agents), and scope (three registries). However, it doesn't explicitly differentiate from sibling tools like 'compare_agents' or 'risk_terms', which might have overlapping trust assessment functions.

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, context for selecting registries, or how it differs from sibling tools such as 'compare_agents' or 'risk_terms'. The agent must infer usage from the purpose alone.

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