reviewer_analysis
Analyze wallet ages of every reviewer who left feedback on an agent. Detects sybil patterns like same-day wallet creation clusters.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Agent ID | |
| chain | Yes | Chain slug |
Analyze wallet ages of every reviewer who left feedback on an agent. Detects sybil patterns like same-day wallet creation clusters.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Agent ID | |
| chain | Yes | Chain slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the analysis performed but does not disclose output format, required permissions, data sources, or limitations. Like the 'update_drive' calibration example, this leaves significant gaps for a tool with no 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 sentences with no fluff: the first states the core function, the second highlights a key detection capability. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description gives a general idea of the analysis but not the return structure or any prerequisites. It is adequate for a simple analysis tool but not fully 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 schema already provides basic descriptions for id and chain ('Agent ID' and 'Chain slug'), with 100% coverage. The description adds little beyond confirming that id refers to the agent whose reviewers are analyzed, but it does not elaborate on chain values or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('analyze') and resource ('wallet ages of reviewers on an agent'), and it distinguishes itself from sibling tools like address_age by focusing on all reviewers and sybil pattern detection rather than a single 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 implies the tool is for detecting sybil patterns, but it does not explicitly state when to use it over alternatives like address_age or reviewer_wallet. No exclusions or alternative suggestions are provided, so the agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes, but reviewer_analysis and reviewer_wallet overlap in analyzing reviewer behavior, and trust_check and risk_terms both provide trust assessments with different framing. Descriptions help clarify the differences, yet an agent could easily misselect between these pairs.
All tool names use snake_case, but the pattern is inconsistent: some are verb_noun (compare_agents, trust_check) while others are noun-based (address_age, entity, mcp_attestation). This mixed convention is readable but not predictable.
10 tools is well-scoped for an AI agent trust intelligence server, covering both individual lookups and network-wide statistics without unnecessary redundancy. Each tool addresses a specific analytical need.
The server covers the core trust intelligence surface: trust scores, risk assessment, wallet profiling, reviewer analysis, commerce stats, and network stats. Minor gaps exist, such as no tool to fetch a single agent's full profile independent of an operator, but overall the domain is well covered.