MCP Guard Scan
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | pino level for the logs on stderr (default `warn`). | warn |
| MCP_GUARD_ALLOW_STDIO | No | Set to `1` to add the `scan_stdio_server` tool. Scanning a stdio server runs its code. | |
| MCP_GUARD_ALLOW_PRIVATE_NETWORK | No | Set to `1` to let `scan_server` reach local and private addresses, and plain `http://`. |
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_tools_exportA | Run every static mcp-guard rule over a tools/list result you already have: { "tools": [...] }, a bare array of tools, or { "servers": [{ "name", "tools" }] } to also check shadowing between servers. Nothing is started or contacted. Returns a Markdown report and the findings. |
| scan_serverA | Connect to a Streamable HTTP MCP endpoint, list its tools, resources and prompts, run every static rule and check the transport (TLS, auth, CORS, session handling). The scanned server's tools are never called. Only public https endpoints; local and private addresses are refused unless the server runs with MCP_GUARD_ALLOW_PRIVATE_NETWORK=1. |
| list_rulesA | List every MCPG rule with its category, default severity and whether it is static or needs the CLI's --probe mode. |
| explain_ruleA | Explain one rule, e.g. MCPG-002: what it detects, a bad and a good example, how to fix it and references. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
The two scan tools are clearly separated by input source: scan_tools_export operates offline on a pasted/exported tools list, while scan_server connects to a live HTTP endpoint and additionally checks transport. list_rules vs explain_rule is a clean list/detail split. No two tools can plausibly be mistaken for one another.
All four names follow the same snake_case verb_noun convention (scan_tools_export, scan_server, list_rules, explain_rule), with unambiguous verbs (scan/list/explain). scan_tools_export is a slightly longer object phrase but is still the same pattern.
Four tools is well-scoped for a scanning server: one offline scan, one live scan, one rule catalog, one rule detail view. Nothing feels padded or redundant, and the split between static and live scanning justifies the two scan entry points.
The lifecycle is covered: discover rules, understand a rule, scan imported data, scan a live server. Minor gaps remain, such as filtering rules by category/severity in list_rules, machine-readable (e.g. JSON/SARIF) finding output, or scanning non-tool surfaces (prompts/resources) from an export; agents can work around these.