Skip to main content
Glama

Delete a schedule

schedule_delete

Permanently delete a schedule while preserving generated invoices and history. Recreating the schedule creates a new ID, so previous periods become unbilled.

Instructions

Delete one schedule permanently. Invoices already generated stay in the invoice server and the history is kept. Re-creating it gives a NEW id, so its old periods count as unbilled. schedule_pause is reversible.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesSchedule id, or a client name. Deletion is permanent; re-creating the same schedule afterwards gives it a NEW id, so its old periods count as unbilled again

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.20.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden of behavioral disclosure, and it succeeds: it states permanence, that invoices and history survive, that re-creating a schedule gets a new id, and that old periods become unbilled. This is unusually detailed and highly useful for a destructive operation.

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 tight sentences, with the core action front-loaded and every following sentence adding relevant behavioral or alternative-tool context. There is no filler or repetition.

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

Completeness5/5

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

This is a simple one-parameter destructive tool with no annotations and no output schema. The description covers the deletion action, downstream invoicing/history effects, re-creation implications, and a reversible alternative, leaving no significant gap for an agent deciding whether and how to call it.

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?

The schema provides 100% parameter documentation, including that id can be a schedule id or client name and reiterates the new-id consequence. The description does not need to add parameter-level meaning because the schema already covers it thoroughly.

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

Purpose5/5

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

The description opens with a precise verb and resource: 'Delete one schedule permanently.' It clearly distinguishes this tool from its reversible sibling by noting that schedule_pause is reversible, and it explains the permanent consequences of deletion.

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

Usage Guidelines4/5

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

The description implies when to choose deletion over pausing by stating 'schedule_pause is reversible,' which gives an agent enough context to prefer pause when reversibility matters. It does not explicitly phrase a full 'use this when...' rule, so it misses the top score.

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