Skip to main content
Glama

Delete a destination

delete_destination
DestructiveIdempotent

Remove a claimed URL. Refused while a task still points at it — delete the task first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "delete_destination"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesDestination id, as returned by register_destination.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so safety is covered structurally; the description adds genuinely new behavioral information — a referential-integrity precondition and the failure mode when a task still references the destination. It doesn't state what happens to the record after removal, but the key runtime behavior is disclosed.

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?

Two short sentences with zero waste: the action first, then the constraint and remedy. Nothing could be removed without losing meaning.

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 delete with full annotation coverage and no output schema, the description supplies exactly what's missing: what it removes and the blocking condition with a workaround. An agent can call it correctly and recover from the expected failure without further information.

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?

Schema description coverage is 100% and the schema itself defines 'id' as the destination id returned by register_destination, so the description needn't repeat it. The description adds no extra syntax or edge-case guidance about the id, so baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource: 'Remove a claimed URL', which maps to deleting a destination and clearly distinguishes it from list_destinations, register_destination, and verify_destination. The only small gap is that it says 'claimed URL' rather than explicitly naming the destination entity the agent sees in the tool name.

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?

Gives a concrete precondition ('refused while a task still points at it') and the remedy ('delete the task first'), which routes the agent to the right sibling when deletion fails. It doesn't cover cases like deleting an unverified or already-deleted destination, but the primary usage context is clear.

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.