Skip to main content
Glama
Sign In
warden

warden

by alexar76
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Delete the stored approval for an MCP server

revoke_mcp_server
DestructiveIdempotent

Delete the stored approval for one server id. Afterwards vet_mcp_server treats the server as never seen: its tools are unpinned again until someone approves them anew.

Instructions

Delete the stored approval for one server id. Afterwards vet_mcp_server treats the server as never seen: its tools are unpinned again until someone approves them anew.

When to use: an operator no longer trusts a server, or wants its next approval to start from a clean review. Take previousRevision from status_mcp_server first; the call is refused if the approval changed after that.

When NOT to use: to approve a changed server (approve_mcp_server replaces the old approval directly); to block a server for everyone (a revoked server is unpinned, not blocked — use a threat feed or policy for that); to inspect state (status_mcp_server).

Behaviour: deletes one file in the local state directory; cannot be undone except by approving again. Refused unless the operator started this process with WARDEN_ALLOW_PIN_CHANGES=1. Needs no tools payload. No network.

Returns { revoked: true, serverId }. Example: revoke_mcp_server({ server: { id: "demo@0", name: "demo", transport: "stdio", command: "npx" }, previous_pin_revision: "" }).

Input Schema

NameRequiredDescriptionDefault
serverYesServer whose approval to delete. Only id is used to find it; the other fields must still be valid.
previous_pin_revisionYesThe previousRevision value status_mcp_server returned when you reviewed this server (null when it reported no stored approval). The write is refused if the stored approval changed since then, so two reviewers cannot overwrite each other.

Output Schema

NameRequiredDescriptionDefault
revokedYesAlways true; any refusal is returned as an error instead.
serverIdYesThe server id whose approval was deleted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.18.0
    • changedInput schema / properties / previous_pin_revision / description
      Previous value: -"Previously reviewed previousRevision, or null if unpinned."New value: +"The previousRevision value status_mcp_server returned when you reviewed this server (null when it reported no stored approval). The write is refused if the stored approval changed since then, so two reviewers cannot overwrite each other."
    • changedInput schema / properties / server / description
      Previous value: -"Identity of the MCP server being vetted — the host's McpServerRef, not a live connection. WARDEN never launches this command or fetches this URL."New value: +"Server whose approval to delete. Only id is used to find it; the other fields must still be valid."
    • addedOutput schema / additionalProperties
      Added value: +false
    • removedOutput schema / description
      Removed value: -"Approval state, current hashes and previous snapshot; or approved/revoked confirmation."
    • addedOutput schema / properties
      Added value: +{
+  "revoked": {
+    "const": true,
+    "description": "Always true; any refusal is returned as an error instead.",
+    "type": "boolean"
+  },
+  "serverId": {
+    "description": "The server id whose approval was deleted.",
+    "type": "string"
+  }
+}
    • addedOutput schema / required
      Added value: +[
+  "revoked",
+  "serverId"
+]
  2. Addedv0.16.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations flag the operation as destructive and non-read-only, and the description goes well beyond that: it discloses that exactly one local state file is deleted, that the action is irreversible except by re-approval, that it requires WARDEN_ALLOW_PIN_CHANGES=1, that no network or tools payload is involved, and the response shape. This is rich context beyond the hints.

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?

Front-loaded with the core effect, then structured into When-to-use / When-NOT / Behaviour / Returns. Despite its length, each sentence carries distinct operational information with 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?

Covers prerequisites, preconditions, failure conditions (refused if the approval changed), reversibility, environment gating, and even the return value (redundant given the output schema, but harmless). Nothing an agent needs to call it safely 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?

Schema description coverage is 100%, so the previous_pin_revision concurrency semantics and every server field are already documented in the schema itself. The description largely restates these (including the example payload) rather than adding new meaning, so the 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 the stored approval for one server id') and immediately differentiates its effect from sibling tooling ('vet_mcp_server treats the server as never seen: its tools are unpinned again'). An agent can distinguish it from approve_mcp_server and status_mcp_server 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 'When to use' and 'When NOT to use' sections name the exact alternatives for each excluded case: approve_mcp_server for changed servers, threat feed/policy for blocking, status_mcp_server for inspection. It also prescribes the prerequisite step (take previousRevision from status_mcp_server first).

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

Deploy Server

Other Tools