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

Annotations already mark this as destructive, idempotent, and open-world, so the bar is lower. The description adds useful behavioral detail: it stops Convika from serving that exact path after the route map updates, and it describes the main_domain_path refusal case.

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 the core action and confirmation requirement, and the additional workflow notes are relevant. Some sentences, especially the main_domain_path explanation, are dense but still earn their place.

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 destructive one-parameter tool whose annotations already cover safety traits, the description provides the missing operational context: confirmation, exact effect, route-map timing, special main_domain_path handling, and legacy replacement workflow.

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 single routeId parameter is already documented as coming from list_domain_routes. The description does not add further routeId semantics beyond the schema, so 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 states a specific verb and resource: disabling one custom-domain route. It is clearly distinct from list_domain_routes and enable_domain_route, and the special legacy-path workflow reinforces the exact scope.

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 a strong prerequisite: use only after explicit user confirmation. It also explains the main_domain_path exception and the legacy frozen path replacement sequence, though it does not explicitly mention enable_domain_route as the reversal alternative.

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