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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: no key is held, the operation is a read, the response is a page URL plus install lines, and signed operations are delegated elsewhere so keys stay local. The phrase 'posts an ask only as a pay link' is slightly ambiguous but is clarified by 'this connector holds no key: it reads,' so no annotation conflict.

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 valuable but redundant: the local-plugin requirement is stated twice ('Anything else that needs signing... is done in Claude Code' and 'Posting an ask, submitting work... need the local server'). Sentences are long and run-on, and the key output description is buried at the end rather than front-loaded.

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 two-parameter, zero-required routing tool with no output schema, the description covers what is returned, why the connector cannot sign, and where signed actions must go. An agent has enough to call it and to explain the result to a user; only the exact return shape is left implicit.

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% and the enum values are fully documented in the schema itself, so the description's enumeration of actions largely restates structured data. It does add the behavioral nuance that 'install' returns only the local server's install lines and that omitting action returns all, but that is marginal. 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 closing sentence states the concrete output: 'the site's page for the action and the install lines for the local plugin and package,' which tells an agent this is a routing/orientation tool. The opening sentence establishes the key constraint (read-only, pay-link-only posting) that distinguishes it from the mutating siblings. It is clear but the tool's actual function is stated last rather than first.

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?

It explicitly routes: post_ask with pay_by 'card' works here, while posting, submitting work, connecting accounts, sending earnings and status checks 'need the local server.' It also names the counterpart mechanism (Claude Code + asks.world plugin) and even says 'Call this and say so plainly to the user.' Missing only direct sibling tool names for the local-server paths.

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