Skip to main content
Glama

Delete a recurring Autopilot plan

delete_autopilot_plan
Destructive

Delete a plan. The drafts it already made stay. Cannot be undone; confirm with the user first.

Input Schema

NameRequiredDescriptionDefault
planIdYesThe plan, from list_autopilot_plans.
workspaceIdNoDefaults to the workspace this connection is scoped to.
idempotencyKeyNoOptional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is partly covered. The description adds genuinely useful context beyond that: existing drafts survive the deletion, the action is irreversible, and user confirmation is required. It does not say what happens to future scheduled runs, which would have completed the picture.

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

Conciseness5/5

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

Three short sentences, front-loaded with the action, then the non-obvious side effect, then the safety prerequisite. No filler and every sentence carries information.

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

Completeness4/5

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

For a destructive tool with no output schema, the description covers irreversibility, the survival of existing drafts, and the confirmation requirement. The remaining gap is the effect on future/scheduled plan output and the relationship to deactivate_autopilot_plan.

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 all three parameters are documented in the schema, including idempotencyKey retry semantics. The description adds no parameter-level information, so the 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 (delete) and resource (a plan), and the title disambiguates it as an Autopilot plan. It is clearly distinguishable from delete_sequence/delete_automation by the plan resource, though the description body itself just says 'a plan' and relies on the title.

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

Usage Guidelines3/5

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

Gives one real usage rule: confirm with the user first before invoking. However, it never addresses the key alternative, deactivate_autopilot_plan (and update_autopilot_plan), so the agent gets no guidance on when deletion is preferable to merely deactivating.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources