onboarding_delete_wo_execute_plan_by_id

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

Annotations already carry the safety profile (destructiveHint=true, idempotentHint=true, readOnlyHint=false, openWorldHint=true), so the description needn't re-declare irreversibility. What it does add is the organization scoping constraint — the deletion applies only within the current org. It does not say whether an in-flight execution is cancelled or merely removed from records, which is the key behavioral unknown for this endpoint.

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 verb/resource leads, which is correct, but the first two lines are near-verbatim duplicates of each other (the second only appending "in the current organization") and the third line is a bare HTTP route that adds little for an agent. Roughly half the text is redundant rather than load-bearing.

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?

This is a destructive, open-world mutation with no output schema, so the description should carry the operational consequences. It leaves unstated whether the execution's history/resources are discarded, whether running workflows are terminated, and what a successful response indicates — gaps that matter when an agent is deciding whether to fire a delete.

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% with a single required `id` described as "The id of the plan (path)," so the baseline is 3. The description does not resolve the ambiguity between the schema's "id of the plan" and the endpoint's execute-plan/{id} (execution id); that clarification is exactly what would have earned a 4 or 5 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?

Specific verb + resource: "Delete the selected onboarding plan execution," which is meaningfully narrower than the sibling onboarding_delete_plan_by_id (a plan, not an execution). The scope "in the current organization" and the underlying endpoint DELETE /relocation/api/wo/execute-plan/{id} reinforce which object is affected. It stops short of stating the sibling distinction explicitly, but the resource noun is precise enough to pick the right tool.

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 statement of when to use this versus onboarding_delete_plan_by_id, onboarding_delete_blueprint_by_id, or onboarding_delete_deployment_by_id, nor of prerequisites (must the execution be in a terminal state? must it be yours?). The only usage-flavored phrase is the organizational scoping "in the current organization," which is a constraint rather than guidance on tool selection.

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