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

With no annotations, the description carries the full burden and does reasonably well: it discloses the data provenance (ERC-8004 registry entries plus APEX Watchtower weekly uptime records) and a concrete rate limit (free, 200 calls/day). It stops short of stating read-only semantics outright, but the phrasing ('what other wallets have said', 'the registry's summary') makes a query operation unambiguous.

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, front-loaded with what is returned, then the provenance and the free-tier quota. Dense but every clause contributes; only the trailing 'Free, 200 calls a day' sits slightly apart from the core payload description.

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 one-parameter read tool with no output schema, the description compensates by enumerating the returned record fields and the included uptime data, which is exactly what an agent needs to judge relevance. What remains unspecified — response shape, ordering, behavior for an agent with zero entries — is minor.

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?

There is a single parameter with 100% schema description coverage ('the agent id in Arc's ERC-8004 registry'), so the schema already does the work and the description only restates the same idea. Baseline 3 applies; nothing like format, valid ranges, or what happens for an unknown id is added.

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+resource: it returns every ERC-8004 reputation entry for an Arc agent plus the registry's own summary. The parenthetical enumerates the fields returned (who gave it, value, tags, revocation), which is concrete. It stops short of naming which sibling to use instead (e.g. arc_trust_check, arc_verdict, arc_counterparty), so differentiation rests on the tool name alone.

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 context of use is implied — check an agent's on-chain reputation before interacting — but there is no explicit when-to-use, when-not-to-use, or named alternative among the many reputation-adjacent siblings. An agent must infer the boundary between this and arc_trust_check/arc_verdict itself.

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