Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
vet_mcp_serverA

Run WARDEN's ordered gate chain (static-scan → threat-feed → origin → pinning) over a server identity plus its advertised tools/list payload and return a recordable verdict (allow/block, 0..1 product score, findings, allowedTools/blockedTools, ruleset digest).

When to use: you have a complete server record and want the same decision a host should make before any of those tool definitions reach the model. Prefer this over calling the four gates yourself.

When NOT to use: inspecting descriptions only (call static_scan_tools — no origin/pinning); splitting tools by operator glob (classify_sensitive_tools); checking one outbound URL (check_egress_url); producing RFC 8785 bytes (canonicalize_json).

Behaviour: local, deterministic, no network. This stdio process uses the built-in 11-record threat floor (it does not fetch a signed feed) and a durable local pin store. First contact is TOOL_DEF_UNPINNED/advisory until explicitly approved. Origin defaults to allowUnknownServers=true so catalog-discovered servers are not fail-closed. Override policy when you need the host's real knobs. Does not connect to, start, or approve the target server.

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

static_scan_toolsA

Run only the static-scan gate (ruleset v12, 35 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" } }] }).

classify_sensitive_toolsA

Split advertised tool names into sensitive vs safe using the operator's case-insensitive * globs (the same policy.sensitiveToolPatterns a host would use). Sensitive tools stay advertised; they require per-call approval — this tool does not run them.

When to use: show the user which names will need confirmation before they approve a server, or to preview a glob set. This is policy over identifiers, not an injection scan.

When NOT to use: scanning descriptions for poisoning (static_scan_tools or vet_mcp_server); checking whether a URL is allowed out (check_egress_url).

Behaviour: local glob match, no network. An empty patterns array marks every tool safe. Patterns match the whole name; "delete" hits create_delete_repo. Does not call Warden.vet and does not persist anything.

Returns { sensitive, safe }. Example: classify_sensitive_tools({ tools: [{ name: "delete_repo", description: "Delete a repository.", inputSchema: { type: "object" } }], patterns: ["delete"] }).

check_egress_urlA

Ask EgressGuard whether a URL's hostname is on an operator allowlist. A tool reaching a host you never listed is the classic phone-home tell. Empty allowlist blocks everything (fail-closed), not everything-allowed.

When to use: a tool is about to fetch/post and you want the same check a host should wrap around that request. Hostnames match case-insensitively; "*.example.com" matches subdomains, not the apex.

When NOT to use: vetting tool definitions (vet_mcp_server / static_scan_tools); canonicalizing JSON (canonicalize_json). This does not fetch the URL and does not inspect tool text.

Behaviour: local URL parse + hostname match. Unparseable URLs are refused. No DNS, no HTTP. Idempotent.

Returns { allowed, host?, reason? }. Example: check_egress_url({ url: "https://api.github.com/repos", allowlist: ["api.github.com", "*.internal.example.com"] }).

canonicalize_jsonA

Return the RFC 8785 JSON Canonicalization Scheme serialization WARDEN uses for threat-feed signatures and tool-def pins, so another implementation can byte-check against it. Integers only inside ±(2^53−1); lone surrogates and non-integers are refused with a reason code, not escaped.

When to use: you are publishing or verifying a signed threat feed, hashing tool defs, or comparing two JSON documents that must agree regardless of key order. Subpath @aimarket/warden/jcs is the same function.

When NOT to use: scanning tool defs (static_scan_tools); pretty-printing for humans (this output is for bytes, not display).

Behaviour: local, no network. Pass either a parsed JSON value or a JSON string (string is parsed with parseJsonStrict first). Failure returns isError with CanonicalizationCode — it does not emit partial bytes.

Returns { canonical } or an error. Example: canonicalize_json({ value: { b: 1, a: 2 } }) → {"a":2,"b":1}.

list_scan_rulesA

Return the in-force static-scan ruleset: version, digest, and every rule's code, severity, tier (block vs advise), surfaces (name / description / inputSchema / title / outputSchema / annotations / metadata), optional regex source, and named guards. A recorded verdict is only reproducible together with this identity.

When to use: explain a finding code, confirm you are on ruleset v12, or re-run a scan with the same table. include_source=true adds the regex source and flags for an independent re-implementation.

When NOT to use: evaluating a live tools/list (static_scan_tools or vet_mcp_server — those apply the table). This tool does not scan anything.

Behaviour: local snapshot of the compiled rule table, no network, no mutation. Digest is sha256 over the RFC 8785 form of {version, fold, rules} (each rule carries its raw flag).

Returns the ruleset object. Example: list_scan_rules({ include_source: false }).

status_mcp_serverA

When to use: status a local server approval after operator review. status_mcp_server returns the current hashes and previous snapshot for comparison. When NOT to use: ordinary scanning; use vet_mcp_server. Approve/revoke require WARDEN_ALLOW_PIN_CHANGES=1 set by the operator before process startup. Approval requires the exact reviewed tool and identity hashes plus previous_pin_revision (null for first approval); it never starts the target server.

approve_mcp_serverA

When to use: approve a local server approval after operator review. status_mcp_server returns the current hashes and previous snapshot for comparison. When NOT to use: ordinary scanning; use vet_mcp_server. Approve/revoke require WARDEN_ALLOW_PIN_CHANGES=1 set by the operator before process startup. Approval requires the exact reviewed tool and identity hashes plus previous_pin_revision (null for first approval); it never starts the target server.

revoke_mcp_serverA

When to use: revoke a local server approval after operator review. status_mcp_server returns the current hashes and previous snapshot for comparison. When NOT to use: ordinary scanning; use vet_mcp_server. Approve/revoke require WARDEN_ALLOW_PIN_CHANGES=1 set by the operator before process startup. Approval requires the exact reviewed tool and identity hashes plus previous_pin_revision (null for first approval); it never starts the target server.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 9 tools

Disambiguation4/5

Most tools have sharply distinct purposes, and the descriptions explicitly cross-reference when to use each vs alternatives (e.g. vet_mcp_server vs static_scan_tools vs list_scan_rules). The exception is the approval trio (status_mcp_server / approve_mcp_server / revoke_mcp_server), whose descriptions are near-identical copy-paste text that even mislabels itself as 'status a local server approval', leaving boundary clarity to the names alone.

Naming Consistency5/5

All nine tools use consistent snake_case verb_noun/verb_object patterns (check_egress_url, static_scan_tools, list_scan_rules, approve_mcp_server). No mixed conventions or arbitrary casing.

Tool Count5/5

Nine tools is well within the ideal range and each maps to a distinct stage of an MCP vetting workflow (scan, classify, vet, canonicalize, egress, rules, approval lifecycle). Nothing feels padded or missing at the count level.

Completeness4/5

The surface covers the core vetting lifecycle: granular vs full scanning, sensitive-tool classification, rule introspection, JSON canonicalization for signatures, egress allowlisting, and approval status/approve/revoke. Minor gaps remain (no direct tool to list existing pins or manage the threat feed), but agents can work around them.

Maintenance

ActivityActive
ResponsivenessNo issues