reputation_get_summary

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

With no annotations, the description does carry real behavioral weight: it discloses that no wallet is required (read-only, unauthenticated) and specifies the return shape (average rating as an 18-decimal WAD string plus feedback count), which is valuable given there is no output schema. It does not cover edge behavior such as what is returned for an agent with zero feedback or an invalid agentId, so the disclosure is partial rather than complete.

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 content is front-loaded and tight: purpose, return format, and access requirement in two sentences. The trailing 'Tip' about earning_opportunities is off-topic for this tool and dilutes an otherwise clean definition.

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 single-parameter read tool with no output schema, the description supplies what the agent most needs: the data source, the return types and encoding, and the fact that no wallet is needed. The remaining gap (behavior for missing reputation data) is minor at this complexity level.

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% for the single agentId parameter, so the schema already documents it fully. The description adds no format, range, or sourcing detail for agentId beyond what the schema states, which is the expected baseline for a high-coverage single-parameter 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?

States a specific verb and resource ('Get aggregated reputation summary for an agent') and names the data source (ERC-8004 reputation registry), which is concrete. It does not explicitly distinguish itself from nearby siblings such as reputation_get_feedback_count or reputation_read_feedback, though 'aggregated summary' implies a rollup rather than raw records.

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?

There is no guidance on when to use this versus the other reputation_* tools (read_feedback, get_feedback_count, get_clients). The only directive is a tangential 'Tip' pointing at earning_opportunities, which is not an alternative for this purpose and does not help the agent choose a reputation tool.

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