Skip to main content
Glama

Delete a secret

vault_delete
DestructiveIdempotent

Remove a secret from the vault, for good. Free.

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": {
      "name": "<name>"
    },
    "name": "vault_delete"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYese.g. "Shopify admin" or "SUPPLIER_API_KEY".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is carried structurally; the description reinforces permanence with "for good" but adds nothing about error behavior for a missing secret or whether any reference to the deleted secret breaks. The trailing "Free." gestures at a cost/quota trait not present in the annotations, though it is too terse to be actionable.

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

Conciseness4/5

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

Two short sentences, front-loaded with the destructive action. "Free." is a fragment whose meaning (no cost? no quota?) is not self-evident, which slightly undercuts an otherwise waste-free definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter destructive tool, the key facts (permanence, no read of return values needed since there is no output schema) are mostly covered by annotations. Missing are what happens on a nonexistent name and whether deletion breaks anything referencing the secret — meaningful gaps given destructiveness.

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?

There is a single required `name` parameter and schema description coverage is 100%, including a pattern and examples ("Shopify admin", "SUPPLIER_API_KEY"). The description adds no parameter meaning at all, so the baseline of 3 for high schema coverage 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 secret from the vault") with the permanence qualifier "for good", which separates it from vault_save's overwrite semantics. It does not name any sibling (vault_get, vault_list, vault_save, vault_generate_password), so differentiation is left to inference from the name.

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?

No explicit when-to-use or when-not-to-use guidance, and no alternative is named — an agent cannot tell from the text whether to delete and re-save a rotated secret or simply call vault_save. "For good" vaguely signals this is not the overwrite path, but that is all the guidance provided.

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