reputation_read_all_feedback

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

With no annotations at all, the description carries the full burden and delivers real behavioral facts: 20 entries per page, an N+1 RPC-per-entry cost warning, and that no wallet/auth is required. It omits what an entry looks like and whether revoked entries are excluded by default in behavior terms, but the cost and auth disclosures are substantive.

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?

Purpose, page size, pagination mechanics and the cost warning are front-loaded and earn their place. The closing 'Tip: call earning_opportunities...' is unrelated promotional text that dilutes a tool definition and should be cut.

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 5-parameter read tool with no annotations and no output schema, the definition covers pagination and cost but leaves the returned entry shape and the effect of includeRevoked on results undescribed. The cursor/nextCursor inconsistency also leaves an agent unsure how to actually iterate pages.

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 coverage is 100%, so cursor, tag1/tag2, and includeRevoked are already documented and the baseline is 3. The description adds the page size and the existence of a next-page token, but it tells the agent to 'pass nextCursor from the previous response' while the schema's parameter is an integer 'cursor' index — a naming mismatch that could confuse an agent even though the schema remains authoritative.

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 ('Read all feedback entries for an agent') plus scope modifiers (tag filtering, pagination, includes revoked control). It implies the difference from the sibling reputation_read_feedback via the word 'all' but never names that sibling or states the distinction explicitly.

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?

Gives one conditional usage rule — use cursor pagination when an agent has a large feedback set, because of the N+1 cost — which is genuinely actionable. It does not route the agent to alternatives (e.g. reputation_read_feedback for a single entry, reputation_get_feedback_count for just a count), so selection among the reputation_* family is left to inference.

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