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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful context the annotations cannot: the data is public, is computed only against reviewed and non-void resolutions, and yields no score for empty samples — which tells the agent to expect gaps rather than errors.

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, zero waste, with the content of the return value front-loaded before the empty-sample caveat. It is a noun-phrase fragment rather than a full clause, but nothing is padded.

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?

With no output schema, the description must carry the return-value burden, and it does enumerate the three things returned. The remaining gap is pagination: an 'after' cursor exists but nothing says results are paged, which matters for a low-complexity single-param read tool.

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 one parameter ('after', a member offset cursor) with 100% schema description coverage, so the schema already carries the semantics. The description adds nothing about pagination or cursor behavior, which is the baseline-3 outcome when the schema does the heavy lifting.

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 concrete outputs — Brier scores, sample sizes, reliability bands — and the data domain (reviewed, non-void resolutions), so an agent knows this is a calibration/accuracy read. It never differentiates itself from nearby siblings like morrowkin_get_claim_predictions or morrowkin_get_contribution_credits, which also return member-scoped metrics.

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 when-to-use guidance, no prerequisite, and no named alternative among the ~40 siblings. The one caveat (empty samples have no score) describes output behavior, not when an agent should pick this tool over another.

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