Skip to main content
Glama

Delete layer template forever

purge_layer_template
DestructiveIdempotent

Permanently remove a layer template that has already been deleted; deletion must happen first. Use this to drop the template row without touching media files.

Instructions

Permanently remove an already-deleted layer template (find it with list_deleted). Templates hold no media files; this only drops the row. A template that is not deleted is refused: call delete_layer_template first. Returns { ok, message }.

Input Schema

NameRequiredDescriptionDefault
templateIdYesLayer template id (list_layer_templates)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.26.3

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare destructiveHint and idempotentHint, so the bar is lower, yet the description still adds real context: the action is irreversible, templates hold no media files and only the row is dropped, and non-deleted targets are refused. It also states the return shape { ok, message }. Slightly short of 5 only because it doesn't say what happens to any references or downstream state after the row disappears.

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: effect, scope-of-damage, precondition, return value — each load-bearing, with the find-it hint attached to the operation it modifies. 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 single-parameter destructive tool with no output schema, everything an agent needs is present: how to find the target, the sequencing requirement, the blast radius, the refusal behavior, and the return payload.

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 baseline is 3. The description earns an extra point because the schema's own hint for templateId points to list_layer_templates, which lists non-deleted templates that this tool would refuse; the description corrects that by directing the agent to list_deleted instead.

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 (permanently remove) and resource (an already-deleted layer template), and immediately distinguishes itself from delete_layer_template, the sibling that performs the soft delete. Against a large sibling set containing delete_/purge_/restore_ variants, an agent can pick this one without opening a schema.

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?

Explicit preconditions and routing: locate the record with list_deleted, and if the template is not yet deleted the call is refused so delete_layer_template must be run first. This is exactly the when/when-not/alternative triad the dimension asks for.

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