Skip to main content
Glama
Sign In
warden

warden

by alexar76
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Static-scan MCP tool definitions for injection and exfil

static_scan_tools
Read-onlyIdempotent

Run only the static-scan gate (ruleset v14, 36 signatures with context guards, text folded first) over every advertised tool field: name, description, input schema, title, output schema, annotations and extension metadata.

Instructions

Run only the static-scan gate (ruleset v14, 36 signatures with context guards, text folded first) over every advertised tool field: name, description, input schema, title, output schema, annotations and extension metadata. Returns findings, a 0..1 gate score, and the published ruleset digest.

When to use: you have a tools/list dump and want injection / credential / hidden-Unicode hits without origin, pinning, or the threat feed. Cheaper and narrower than vet_mcp_server.

When NOT to use: you need the full host decision (vet_mcp_server); you want operator glob classification (classify_sensitive_tools); you want the published rule table itself (list_scan_rules).

Behaviour: local regex+guard evaluation, no network, no mutation. Advisory-tier hits are reported with advisory=true and do not reduce the score. Does not launch servers or send tool output to a model.

Returns structured JSON matching outputSchema. Example: static_scan_tools({ tools: [{ name: "add", description: "Add two integers.", inputSchema: { type: "object" } }] }).

Input Schema

NameRequiredDescriptionDefault
toolsYestools/list items to scan (1..256). Same shape as vet_mcp_server.tools.

Output Schema

NameRequiredDescriptionDefault
scoreYesstatic-scan gate contribution: 1 minus the penalty for the worst non-advisory severity. Advisory hits do not change this number.
rulesetYes
findingsYesHits from the 36-rule table, including advisory-only codes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.18.0
    • changedOutput schema / properties / findings / description
      Previous value: -"Hits from the 25-rule table, including advisory-only codes."New value: +"Hits from the 36-rule table, including advisory-only codes."
  2. Changed5 schema fields changedv0.16.0
    • changedInput schema / properties / tools / items / additionalProperties
      Previous value: -falseNew value: +true
    • addedInput schema / properties / tools / items / properties / annotations
      Added value: +{
+  "description": "Advertised hints; untrusted metadata, never authorization.",
+  "type": "object"
+}
    • addedInput schema / properties / tools / items / properties / outputSchema
      Added value: +{
+  "description": "Unmodified output schema, including nested descriptions; scanned and pinned.",
+  "type": "object"
+}
    • addedInput schema / properties / tools / items / properties / title
      Added value: +{
+  "description": "Unmodified advertised tool title; scanned and pinned.",
+  "type": "string"
+}
    • changedOutput schema / properties / ruleset / properties / version / description
      Previous value: -"Monotonic static-scan ruleset version (currently \"4\")."New value: +"Monotonic static-scan ruleset version (currently \"12\")."
  3. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), and the description still adds real context beyond them: local regex+guard evaluation with no network and no mutation, advisory-tier hits flagged advisory=true and excluded from the score, no server launch and no tool output sent to a model. That is exactly the extra behavioral surface annotations cannot express.

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 purpose followed by clearly labelled When to use / When NOT to use / Behaviour / Returns blocks; every line is substantive. It runs longer than strictly necessary, but the structure makes scanning cheap and no sentence is 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?

An output schema exists, so return values need not be detailed, and the description still points to it ('structured JSON matching outputSchema') plus the ruleset digest. For a single-parameter, read-only scan tool this covers everything an agent needs to call it correctly.

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% and the nested field descriptions are thorough, so the schema carries most of the burden. The description still adds value by enumerating the scanned surface (name, description, input schema, title, output schema, annotations, extension metadata), noting text is folded first, and supplying a concrete example invocation.

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 (run the static-scan gate) plus concrete scope: ruleset v14, 36 signatures, applied to every advertised tool field. It explicitly separates itself from vet_mcp_server, classify_sensitive_tools and list_scan_rules, so an agent can pick it without opening sibling schemas.

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 explicit when-to-use ('you have a tools/list dump and want injection / credential / hidden-Unicode hits without origin, pinning, or the threat feed') and when-not-to-use with three named alternatives mapped to their distinct conditions. Nothing is left to inference.

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