Skip to main content
Glama

delete_recipe

DestructiveIdempotent

Permanently delete a recipe you saved, with its version history and track record, using the edit_key from its first save. Use this to withdraw a recipe that's wrong or no longer needed; to change one, publish a new version with save_recipe and the same key instead. Other agents can no longer run it. Recipes that repaired it stay published and are listed in the reply. The name is retired, never reused, so anyone who refers to it gets a clear 'deleted' error rather than a different pipeline. Built-in recipes can't be deleted; a wrong key, or a name that doesn't match exactly, returns an error and changes nothing.

Input Schema

NameRequiredDescriptionDefault
nameYesThe recipe's name.
edit_keyYesThe edit key returned when you first saved it.

Output Schema

NameRequiredDescriptionDefault
deletedYesThe recipe that was removed.
still_availableNoRecipes that repaired it; they stay published.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, but the description goes well beyond them: it discloses that version history and track record are destroyed, other agents can no longer run it, repaired recipes stay published and are listed in the reply, the name is permanently retired, built-in recipes are protected, and a wrong key or mismatched name errors without side effects.

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?

The core action and key requirement are front-loaded in the first sentence, and each following sentence carries distinct behavioral information (mutation alternative, downstream effects, name retirement, built-in protection, failure behavior) with no filler.

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?

For a destructive, no-output-reliance tool with an output schema present, the description covers everything an agent needs: consequences, sibling routing, edge cases, and even the partial return content. No relevant decision factor is missing.

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

Parameters4/5

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

Schema coverage is 100%, so both parameters are already documented and the baseline is 3. The description adds genuine meaning on top: edit_key is clarified as the key from the first save, and name must match exactly or the call fails, which refines how each argument must be supplied.

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?

States a specific verb and resource ("Permanently delete a recipe you saved") plus the exact mechanism ("using the edit_key from its first save"). It explicitly distinguishes itself from the sibling save_recipe by naming it and describing the alternative path for modifications.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ("withdraw a recipe that's wrong or no longer needed") and when-not, routing the agent to save_recipe with the same key to change a recipe instead. Nothing is left to inference about choosing between the two.

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