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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this by stating the tool runs nothing, so the agent knows calling it is a harmless no-op. The remaining gap is whether the conversation_id still needs to be passed to a tool that does nothing, which is not addressed.

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?

One front-loaded sentence that leads with the deprecation status before the migration instructions. No wasted wording and the most important fact comes first.

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 retired stub with no output schema and one fully documented parameter, the description supplies everything needed: that it is inert and the exact replacement workflow. Only the handling of conversation_id on a no-op call 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 coverage is 100% for the single conversation_id parameter, with a lengthy schema description covering propagation rules and omission on the first call. The tool description adds nothing about parameters, 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 opens with 'Retired, runs nothing,' immediately establishing that the tool is a non-functional stub rather than the payment-source update its name implies. It then names the exact replacements (well_update_task and well_create_browser_task), so an agent can distinguish it from siblings without inspecting any schema.

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 gives an explicit sequence: stop the task via well_update_task with status "cancelled", then on the person's confirmation restart with well_create_browser_task and browser.payment_source. It even pre-empts a likely wrong sibling choice by saying 'not well_create_task'.

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