Skip to main content
Glama
Sign In
warden

warden

by alexar76
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Record an operator's approval of an MCP server

approve_mcp_server
DestructiveIdempotent

Stores an operator approval for the exact reviewed tool definitions and launch identity so later vetting treats them as approved and reports changes as drift; WARDEN gates still apply.

Instructions

Store an operator approval for exactly the tool definitions and launch identity the operator reviewed, so later vet_mcp_server calls treat them as approved and report any change as drift. The server must still pass every WARDEN gate; an approval cannot override a block.

When to use: after a human reviewed the output of status_mcp_server and agreed. Pass back the currentToolsHash, currentIdentityHash and previousRevision it returned; if the payload or the stored approval changed in the meantime, the call is refused and the review must be repeated.

When NOT to use: on your own initiative or to make a blocked server pass (the gates run again and the call fails); to remove an approval (revoke_mcp_server); to look at the stored state (status_mcp_server).

Behaviour: writes one file in the local state directory and replaces any earlier approval for this server id. Refused unless the operator started this process with WARDEN_ALLOW_PIN_CHANGES=1. No network; never starts the target server. Repeating the same call is refused because the revision it names is no longer current.

Returns { approved: true, pin }. Example: approve_mcp_server({ server, tools, reviewed_tools_hash: "", reviewed_identity_hash: "", previous_pin_revision: null }).

Input Schema

NameRequiredDescriptionDefault
toolsYesThe exact tools/list payload the operator reviewed. Its hash must equal reviewed_tools_hash.
serverYesIdentity of the MCP server being vetted — the host's McpServerRef, not a live connection. WARDEN never launches this command or fetches this URL.
server_infoNoOptional: the serverInfo object from the server's initialize result, unmodified ({ name, version }). Shown next to the review as the version the server reports, and stored with an approval; it is the server's own word, so it is never hashed or trusted.
reviewed_tools_hashYescurrentToolsHash from the status_mcp_server call the operator reviewed.
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.
reviewed_identity_hashYescurrentIdentityHash from the same status_mcp_server call.

Output Schema

NameRequiredDescriptionDefault
pinYesThe approval as stored, with approvalMode "operator".
approvedYesAlways true; any refusal is returned as an error instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.21.0
    • addedInput schema / properties / server_info
      Added value: +{
+  "additionalProperties": false,
+  "description": "Optional: the serverInfo object from the server's initialize result, unmodified ({ name, version }). Shown next to the review as the version the server reports, and stored with an approval; it is the server's own word, so it is never hashed or trusted.",
+  "properties": {
+    "name": {
+      "maxLength": 200,
+      "type": "string"
+    },
+    "version": {
+      "maxLength": 200,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. Changed8 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 / reviewed_identity_hash / description
      Previous value: -"currentIdentityHash returned by status_mcp_server for this exact launch identity."New value: +"currentIdentityHash from the same status_mcp_server call."
    • changedInput schema / properties / reviewed_tools_hash / description
      Previous value: -"currentToolsHash returned by status_mcp_server for this exact payload."New value: +"currentToolsHash from the status_mcp_server call the operator reviewed."
    • changedInput schema / properties / tools / description
      Previous value: -"Exact tools/list payload (1..256 tools). Each item is name + description + inputSchema from the server. Do not filter before vetting — blockedTools is the partition."New value: +"The exact tools/list payload the operator reviewed. Its hash must equal reviewed_tools_hash."
    • 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: +{
+  "approved": {
+    "const": true,
+    "description": "Always true; any refusal is returned as an error instead.",
+    "type": "boolean"
+  },
+  "pin": {
+    "description": "The approval as stored, with approvalMode \"operator\".",
+    "type": "object"
+  }
+}
    • addedOutput schema / required
      Added value: +[
+  "approved",
+  "pin"
+]
  3. Addedv0.16.0

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations: names what is overwritten (one file in the local state directory, replacing any earlier approval for this server id), the WARDEN_ALLOW_PIN_CHANGES=1 precondition, the no-network/no-launch guarantee, and the refusal conditions. The one muddy point is that it says repeating the same call is refused, which sits awkwardly beside idempotentHint=true and could confuse an agent deciding whether to retry — not a clean contradiction, but it costs a point.

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?

Front-loaded with the outcome, then cleanly sectioned into when-to-use, when-not-to-use, behaviour, returns, and a call example — easy to scan for a six-parameter tool. Minor redundancy: the 'approval cannot override a block' point is made in the opening and then again in the when-not-to-use list.

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 destructive, gate-checked write with a nested schema and an output schema, the description covers everything an agent needs to call it correctly: the prerequisite read, the verbatim hash hand-off, the environment precondition, the staleness refusal, and the side effects. Return values are left to the output schema, as appropriate.

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 the baseline is 3, but the description adds genuine semantics: it identifies which fields must be copied verbatim from the status_mcp_server response, explains that previous_pin_revision is null when no approval is stored, and states these values act as a concurrency guard so two reviewers cannot overwrite each other. That tie between parameters and the refusal rule is not in the schema.

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 (store an operator approval for tool definitions and launch identity) plus the downstream effect: later vet_mcp_server calls treat them as approved and report change as drift. It is immediately distinguishable from revoke_mcp_server (removing) and status_mcp_server (reading state), both of which it names.

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' gate (after a human reviewed status_mcp_server output and agreed) and an explicit 'When NOT to use' list covering self-initiated approval, trying to unblock a blocked server, removal, and inspection — each with the correct sibling named. The required hand-off of currentToolsHash/currentIdentityHash/previousRevision from the prior status call is spelled out as a precondition.

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