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

With no annotations, the description itself bears the full burden of disclosing behavior. It does so thoroughly: it states the call is free, that warming_up activates on demand, that retrying does not help in misconfigured/quota_exceeded states, and that free tools remain available during quota issues. This gives the agent realistic failure semantics and consequences beyond a simple 'check status' summary.

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 description is front-loaded with a one-line summary, followed by a 'Free' note and a structured lifecycle-state list. Each bullet adds actionable information and there is no filler, so the length is justified by the number of states and their distinct implications.

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 status tool with an output schema, the description is complete: it defines all six lifecycle states, the consequences for subsequent paid/free tool calls, and the appropriate next action for each state. Return-value details are covered by the output schema, so nothing critical for correct invocation 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 single optional parameter, patron_npub, has 100% schema coverage, including its behavior and the upstream_oauth block it triggers. The main description adds no param-specific meaning, but because the schema already documents the parameter thoroughly, the baseline score of 3 is appropriate.

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 opens with a specific verb and resource ('Check operator readiness') and then enumerates six concrete lifecycle states, so an agent can tell this is a status/readiness probe. It does not explicitly differentiate itself from similarly named siblings like authority_operator_status or authority_service_status, so clarity is strong but not fully sibling-distinguished.

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?

The description gives state-specific next actions ('Proceed with tool calls', 'Try a tool call', 'Call register_operator first') and explains paid-vs-free tool implications for each state. It does not explicitly name alternative status tools or say when to prefer them, but the context and follow-up guidance are clear enough.

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