Skip to main content
Glama

onboarding_delete_plan_by_id

DestructiveIdempotent

Deletes a selected onboarding plan by ID, removing the specified plan from the current organization via DELETE /relocation/onboarding/plan/{id}.

Instructions

Delete the selected onboarding plan Delete the selected onboarding plan in the current organization DELETE /relocation/onboarding/plan/{id}

Input Schema

NameRequiredDescriptionDefault
idYesThe id of the plan (path)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that: it never says the deletion is permanent, whether it cascades to resources/deployments under the plan, or what happens if the plan is in an executing state. The raw DELETE path merely duplicates the annotation title.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The same sentence appears twice in slightly different forms, then a raw HTTP path is appended — three statements conveying one fact. No front-loaded warning or scope detail earns the repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, organization-scoped delete with no output schema, the description should say what a successful delete returns or removes and what error conditions exist (unknown id, plan in use). None of that is present, leaving the agent to guess at consequences.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is a single required path parameter ('The id of the plan (path)'), so the schema carries the semantics. The description adds no information about where the id comes from (e.g. onboarding_get_plan_by_id) or format constraints, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Delete the selected onboarding plan") and the organization scope, which distinguishes it from the sibling deletes for deployments, resources, blueprints and WO-execute plans. It never names those siblings explicitly, so the differentiation relies on the reader inferring 'plan' vs 'deployment'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus onboarding_patch_plan_by_id, onboarding_delete_deployment_by_id or the other onboarding deletes, and no prerequisites such as plan state, required role, or whether dependent resources must be removed first. The only usage signal is the word 'selected'.

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

Deploy Server

Other Tools