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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely useful behavior beyond them: free, keyless, nothing to sign, no charges have ever occurred, and the response enumerates why the lane is not live. That tells the agent to expect a negative/empty answer rather than a populated record, which annotations cannot convey. It stops short of describing the response shape or error behavior.

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 first sentence is well-placed, but the remainder is padded with unrelated copy: "It buys no token. It promises no return. Standing is earned by the work, never by the payment. Cancel any time; what was funded stays funded." None of that helps an agent decide or invoke, and "Cancel any time" is especially confusing for a read-only lookup. Roughly half the text could be deleted with no loss.

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?

An output schema exists, so return-format gaps are forgivable, and the annotations plus the "keyless/free/no subscription" notes cover the operational essentials. What's missing is a clear statement of what the agent should do with a permanently negative answer and how this differs from the quote sibling. The unrelated place-standing material adds length without filling that gap.

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?

Only one parameter with 100% schema description coverage, so the schema already explains the 0x… wallet format and its public nature. The description's "Given a wallet" restates the schema without adding format, validation, or examples. Baseline 3 is the correct ceiling here.

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 opening sentence gives a specific verb and resource ("returns its regenerative provisioning subscription state"), which is usable. But it immediately undercuts itself with "There is no subscription store and nothing has ever been charged," blurring whether this is a real status lookup or a stub that always answers negatively. The last half of the description drifts into place-standing and payment philosophy that has nothing to do with what the tool returns.

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 explicit statement of when to call this rather than regen_provisioning_subscription_quote or net_subscription_status, both of which sit right next to it in the sibling list. The only routing hint is incidental ("Standing belongs to a PLACE and is read free at GET /labor/standing?place="), which redirects to a different concept rather than helping choose this tool. An agent must infer usage from the name alone.

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