Does an agent's rank rest on demand outside its own operator set (free)

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld=false, so the safety profile is covered. The description does add behavioral substance beyond that: it pins the metric to versioned definitions (rank.independence.v1, rank.inflation.v1, cluster.ratio.v1), states the 30-day window, the three-operator-set threshold, the three-hop cap, and the 50-link bound. It never states units, error behavior, or how a missing/invalid agent is handled, so it is solid but incomplete.

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?

The content is front-loaded with the main return value, which is good, but it is delivered as one massive run-on sentence with deeply nested parentheticals that make the scoring rule hard to parse. No sentence is wasted, yet the packaging actively hinders readability.

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 correctly carries the burden of enumerating return fields, and it does list them. But it neither explains the '(free)' pricing signal nor the distinction between the published and cluster-aware L9 counts in a way an agent can act on, leaving meaningful gaps for a metric this opaque.

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 coverage, and the schema already documents that it accepts an agent token id, slug, or bound wallet. The description adds nothing about the 'agent' argument beyond what the schema provides, so the baseline 3 applies.

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 states the exact outputs (independence score, path, L9 counterparty counts, inflation ratio, operator set size) for a single agent, which identifies the resource well. However, no verb is used ('For one ranked agent: its independence score...') and it never distinguishes this from close siblings such as agent_stability or ranked_agents. The purpose is discernible but not crisply stated.

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, when-not-to-use, or alternative routing anywhere in the text. The title's '(free)' hints at a cost dimension but the description never tells the agent when to call this versus agent_stability or ranked_agents. An agent must infer usage entirely.

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