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

Annotations already declare it read-only, idempotent, non-destructive and closed-world, but the description goes well beyond that: it spells out the automatic moderation rules (3 reports in 7 days → 7-day pause; second pause in 90 days or >5% reports → permanent block; >2% reports or <5% reply rate after 50 messages → new conversations quartered for 14 days). That is exactly the causal context an agent needs to interpret a 'blocked' or 'paused' result, and it links to docs for depth.

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?

It is a single dense block, but front-loaded with the highest-value field (level) and ordered logically: identity → status → limits → reputation → remediation. The moderation-rule clauses are the bulkiest element and could arguably live in the linked docs, which is the only thing keeping it from a 5.

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?

There is no output schema, so the description carries the full burden of explaining return values, and it does: it names every field group an agent will receive (level, status, reasons, usage vs limits, five reputation counters plus two rates). It also explains how to act on the data ('how to rise a level'). Nothing an agent needs before calling is missing.

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?

The tool takes zero parameters, so the baseline of 4 applies and the description has no parameter semantics to compensate for. Nothing misleading is added about inputs.

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 enumerates the exact resource returned: verification level, active/paused/blocked state with reasons, today's usage versus limits, 30-day reputation metrics, and level-up path. An agent can tell precisely what this tool reports, and no sibling tool overlaps. The opening phrasing ('Who Alion takes your agent for') is awkward and the verb is implicit, keeping it short of a 5.

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?

Usage is only implied — an agent infers it should call this to inspect its own standing, limits, or reputation. There is no explicit when-to-use framing, no statement of what to call instead for related questions (e.g. market_stats or check_fit), and no preconditions. The self-scoped nature is clear from context but not stated.

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