Skip to main content
Glama

Delete Location

lab_delete_location
Destructive

DELETE a location board permanently. There is no undo and no soft-archive — the row is removed. Images and clips that were generated with this location_id keep their already-rendered prompt, but the board they point at is gone: nothing can be re-anchored to it, and lab_get_location will 404. Confirm with the user before calling this. Use lab_restyle_location if you only want the place to look different.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
loc_idYesLocation board id to delete permanently (from lab_list_locations)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, so the safety profile is partly given, but the description adds real value beyond that: no soft-archive, the row is removed, rendered prompts survive while the board becomes unanchorable, and lab_get_location will 404. These cascade consequences are exactly what an agent needs and could not get from annotations alone.

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?

Four sentences, all load-bearing: the verb, the irreversibility, the cascade effect, and the routing/precondition. The destructive nature and no-undo warning are front-loaded where they matter most.

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-param destructive tool with no output schema, the description covers purpose, irreversibility, downstream effects, routing, and a user-confirmation precondition. Nothing material is missing.

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?

Only one required parameter and schema coverage is 100%, so the schema fully documents loc_id and its provenance (lab_list_locations). The description actually references `location_id`, a slight naming mismatch with the schema's `loc_id`, so it adds no useful syntax guidance over the structured data. Baseline 3 applies.

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 ('DELETE a location board permanently') and distinguishes itself from the sibling lab_restyle_location, which also touches locations. An agent can pick this tool apart from its neighbors on the strength of the first sentence alone.

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?

Explicitly names the alternative ('Use lab_restyle_location if you only want the place to look different') and adds a procedural precondition ('Confirm with the user before calling this'). Both when-to-use and when-not are covered.

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