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

Annotations only say readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description goes far beyond that: cost ($0.10 for agents), quota limits, automatic vs human review, and critically the ordering guarantee that 400 (refused body) and 429 (exhausted quota) fire BEFORE the 402 so no payment settles for a listing already known to fail. That is exactly the kind of consequence detail an agent needs before invoking a paid mutation.

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?

Purpose is front-loaded in the first sentence, which is good. But the body is a dense wall of payment detail with visible redundancy: the 402-with-accepts point is made twice ('402 with accepts[], $0.10 — pay and repeat' and 'A valid body without payment keeps receiving the 402 with the price'), and the rhetorical 'Two doors to the same action' consumes space without adding operational content.

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 cover outcomes, and it does: it directs the agent to poll status_api (GET /api/listings/:id/status) for the review decision and explains the review and validation order. It stops short of stating what the immediate successful response returns (e.g., the new listing id), which the polling instruction only implies.

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?

Schema description coverage is 100%, so the schema already documents all six parameters, including url, kind and body. The description's parameter-relevant content ('For a skill, the SKILL.md URL is enough') slightly reinforces the url semantics but adds no format, constraint or default information beyond the schema. 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 first sentence states a specific verb and resource set: 'Registers an MCP server, skill or plugin,' which tells an agent exactly what the tool produces. It does not, however, name or contrast itself against likely-confusable siblings such as submit_okf or create_guest, so the agent must infer the boundary.

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 concrete conditions: a human with a session is free (1/day, queue of 3), an agent hits a 402 with accepts[] at $0.10, and it points to status_api for the decision. It also offers an alternative path for OKF bundles ('POST /api/okf/ping is free'), but the guidance is framed around payment flow rather than choosing among sibling tools.

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