Skip to main content
Glama

TextKit

Delete automation

delete_automation
DestructiveIdempotent

Delete an automation.

Input Schema

NameRequiredDescriptionDefault
idYesAutomation id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.5/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered elsewhere; the description adds nothing on top. It does not say whether deletion is permanent, what happens to in-flight runs and historical run data, or what the response contains. With annotations carrying the weight, this is a pass, not a help.

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

Conciseness3/5

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

One short sentence with zero waste, but its brevity comes from under-specification rather than tight writing — the sentence conveys nothing an agent could not infer from the tool name alone.

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 mutation with no output schema and no annotation-level detail about side effects, the description should explain permanence, cascade effects on automation runs, and any required state. 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?

A single parameter with 100% schema description coverage already documents 'id'. The description provides no additional meaning (no id format, no indication of where to obtain the id), so the baseline 3 applies.

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

Purpose3/5

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

The sentence gives a verb ('Delete') and a resource ('automation'), but it is a verbatim restatement of the title and tool name, adding no scope detail. Because ~10 sibling benchmarks are also delete_<resource>, the resource word is what distinguishes it, so an agent can pick it out, but only barely.

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?

There is no guidance on when to use this versus alternatives such as pause_automation or update_automation, nor on prerequisites (e.g., whether an active automation must be paused or cancelled first). No mention of confirmation or irreversibility steps either.

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