Skip to main content
Glama
Sign In
warden

warden

by alexar76
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Show the stored approval for one MCP server

status_mcp_server
Read-onlyIdempotent

Read a server's stored WARDEN approval, compare it with supplied tools/list payload and launch identity, and return hashes, revision, and field-level changes for approval or revocation review.

Instructions

Read the approval WARDEN has stored for one server id and compare it with the tools/list payload and launch identity you pass in. Returns the stored approval (or null), its revision, the hashes of what you passed, whether they differ, what changed field by field (words added and removed in descriptions, schema values before and after, changes made only of numbers marked), and whether this process may change approvals at all.

When to use: before an operator decides to approve or revoke a server, to see what changed since the last approval; show the operator reviewText. It is the only source of the values approve_mcp_server and revoke_mcp_server ask for (currentToolsHash, currentIdentityHash, previousRevision).

When NOT to use: deciding whether a server is safe to expose (vet_mcp_server runs every gate; this tool runs none). It does not scan descriptions and never blocks.

Behaviour: read-only. Reads one file from the local state directory (WARDEN_STATE_DIR, default ~/.local/state/warden/pins); writes nothing, no network, never starts the target server. Works whether or not WARDEN_ALLOW_PIN_CHANGES is set.

Returns structured JSON matching outputSchema. Example: status_mcp_server({ server: { id: "demo@0", name: "demo", transport: "stdio", command: "npx" }, tools: [{ name: "add", description: "Add two integers.", inputSchema: { type: "object" } }] }).

Input Schema

NameRequiredDescriptionDefault
toolsYesThe server's current tools/list payload, unmodified. Its hash is compared with the stored approval and returned as currentToolsHash.
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.

Output Schema

NameRequiredDescriptionDefault
originNoWhere a change came from: the versions the server reported and whether the launch command pins one.
changedYestrue when an approval is stored and the tools or the launch identity differ from it.
changesNoWhat changed since the stored approval, field by field; null when nothing is stored.
previousYesThe stored approval, or null when this server was never approved or was revoked.
serverIdYesThe server id that was looked up.
reviewTextNoThe same changes as plain lines for a person: where they came from (reported version, launch command), [-removed-] and {+added+} inside text, before → after for values, and which tools gain text about the user's approval or tool choice.
currentToolsYesThe tool definitions that were hashed, echoed for the operator's review.
currentToolsHashYesHash of the tools you passed; pass it as reviewed_tools_hash to approve exactly these definitions.
mutationsEnabledYesfalse means approve_mcp_server and revoke_mcp_server will refuse in this process.
previousRevisionYessha256 of the stored approval; pass it as previous_pin_revision. null when nothing is stored.
currentIdentityHashYesHash of the launch identity (transport, command, args, url, name); pass it as reviewed_identity_hash.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields 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"
+}
    • addedOutput schema / properties / origin
      Added value: +{
+  "description": "Where a change came from: the versions the server reported and whether the launch command pins one.",
+  "properties": {
+    "approvedVersion": {
+      "description": "serverInfo.version stored with the approval (the server's own word), or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "currentVersion": {
+      "description": "serverInfo.version you passed now, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "launch": {
+      "anyOf": [
+        {
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "For npx / uvx style launches: runner, ecosystem, package, requested version or range, and pinned (an exact version in the command). null for other launches."
+    }
+  },
+  "required": [
+    "approvedVersion",
+    "currentVersion",
+    "launch"
+  ],
+  "type": "object"
+}
    • changedOutput schema / properties / reviewText / description
      Previous value: -"The same changes as plain lines for a person: [-removed-] and {+added+} inside text, before → after for values."New value: +"The same changes as plain lines for a person: where they came from (reported version, launch command), [-removed-] and {+added+} inside text, before → after for values, and which tools gain text about the user's approval or tool choice."
  2. Changed5 schema fields changedv0.18.0
    • 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 server's current tools/list payload, unmodified. Its hash is compared with the stored approval and returned as currentToolsHash."
    • 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: +{
+  "changed": {
+    "description": "true when an approval is stored and the tools or the launch identity differ from it.",
+    "type": "boolean"
+  },
+  "changes": {
+    "anyOf": [
+      {
+        "properties": {
+          "added": {
+            "type": "integer"
+          },
+          "changed": {
+            "type": "integer"
+          },
+          "changes": {
+            "description": "Per tool: kind (added | removed | changed) and, for a changed tool, every changed value with its path, before, after and, for text, a word diff.",
+            "items": {
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "numbersOnly": {
+            "description": "Changed tools whose every change is digits, separators or whitespace. Still a change: a number can be a limit.",
+            "type": "integer"
+          },
+          "removed": {
+            "type": "integer"
+          }
+        },
+        "required": [
+          "added",
+          "removed",
+          "changed",
+          "numbersOnly",
+          "changes"
+        ],
+        "type": "object"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "description": "What changed since the stored approval, field by field; null when nothing is stored."
+  },
+  "currentIdentityHash": {
+    "description": "Hash of the launch identity (transport, command, args, url, name); pass it as reviewed_identity_hash.",
+    "type": "string"
+  },
+  "currentTools": {
+    "description": "The tool definitions that were hashed, echoed for the operator's review.",
+    "items": {
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "currentToolsHash": {
+    "description": "Hash of the tools you passed; pass it as reviewed_tools_hash to approve exactly these definitions.",
+    "type": "string"
+  },
+  "mutationsEnabled": {
+    "description": "false means approve_mcp_server and revoke_mcp_server will refuse in this process.",
+    "type": "boolean"
+  },
+  "previous": {
+    "anyOf": [
+      {
+        "description": "A stored approval: serverId, toolsHash, identityHash, approvalMode (operator | automatic), toolNames, the approved tool definitions and approvedAt.",
+        "type": "object"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "description": "The stored approval, or null when this server was never approved or was revoked."
+  },
+  "previousRevision": {
+    "description": "sha256 of the stored approval; pass it as previous_pin_revision. null when nothing is stored.",
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "reviewText": {
+    "description": "The same changes as plain lines for a person: [-removed-] and {+added+} inside text, before → after for values.",
+    "type": "string"
+  },
+  "serverId": {
+    "description": "The server id that was looked up.",
+    "type": "string"
+  }
+}
    • addedOutput schema / required
      Added value: +[
+  "serverId",
+  "previous",
+  "previousRevision",
+  "currentToolsHash",
+  "currentIdentityHash",
+  "changed",
+  "currentTools",
+  "mutationsEnabled"
+]
  3. Addedv0.16.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further: it names the exact file location (WARDEN_STATE_DIR, default ~/.local/state/warden/pins), states it writes nothing, makes no network call, never launches the target server, and works regardless of WARDEN_ALLOW_PIN_CHANGES. It also discloses the shape of the return (stored approval or null, revision, hashes, field-by-field diff) and whether the process can mutate approvals.

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 action, then organized into labelled When to use / When NOT to use / Behaviour sections plus a compact example. Every sentence carries a fact an agent could act on; nothing is restated from the schema or annotations without added detail.

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?

With an output schema present, the description does not need to enumerate return fields, and it still summarizes them at a level useful for routing. For a read-only comparison tool with nested parameters, it covers side effects, state location, downstream consumption, and exclusions completely.

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 meaning the schema does not: it explains that the tools payload and launch identity you pass are hashed into currentToolsHash/currentIdentityHash, which are the exact values approve/revoke require. A worked example call shows the intended shape concrete. It stops short of per-field guidance, which the schema already carries.

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 ("read the approval WARDEN has stored for one server id") plus what it is compared against. It explicitly distinguishes itself from vet_mcp_server, which is named as the tool that runs gates while this one runs none.

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?

Gives an explicit "When to use" (before approve/revoke decisions, to diff since last approval, show the operator reviewText) and an explicit "When NOT to use" naming vet_mcp_server. It also names the sibling tools whose inputs this tool supplies (currentToolsHash, currentIdentityHash, previousRevision).

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