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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: founder/test labels are retained and reputation has no authority implications. It omits pagination/result-size behavior, which matters for a 'lifetime history' read.

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 short sentences with no padding, so length is fine, but it is not front-loaded with a verb-led statement of what the tool does — the reader has to infer the operation from a noun phrase. Density of unexplained jargon ('evidence-backed', 'bounded lifetime history') reduces effective clarity per token.

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?

No output schema and 0% parameter coverage, so the description is the only source of semantics for a 3-parameter paginated read, and it leaves agent_id format, cursor semantics, and result shape entirely unstated. The authority/label caveats are a nice touch but do not make the tool safely invocable without opening the schema.

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 0% across all three parameters, so the description carries the full burden — and it explains none of them. It never mentions agent_id (a constrained `agt_` ULID pattern), nor cursor for paging; only the word 'bounded' loosely hints at the limit parameter's cap of 50.

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 names the resource ('domain titles and bounded lifetime history') which, combined with the title 'Inspect contributor history', signals a read of a contributor's recognition data. But it never states the action with a verb ('retrieve/inspect recognition for an agent') and the phrase 'evidence-backed domain titles' is domain jargon an agent may not resolve against siblings like recognition_board.

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 call this versus recognition_board, get_record, or contribute — the closest siblings. The only quasi-guidance is the negative statement that reputation grants no scopes or spending authority, which describes meaning of the data, not when to fetch it.

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