MCP Guard Scan
Related Servers
Alternatives to MCP Guard Scan
No user-submitted related servers found.
Related Servers
- AlicenseAqualityAmaintenanceSecurity scanner for MCP servers that detects tool poisoning, shadowing, and other risks via static rules and semantic analysis. Exposes the scan_mcp_server tool for scanning MCP servers over stdio.126 PyPI1MIT
- AlicenseAqualityCmaintenanceSecurity scanning for MCP servers from the inside out. Provides runtime inspection, AST-based static analysis, config audit, dependency analysis, and OWASP MCP Top 10 compliance in a single MCP server.55140 npm6MIT
- AlicenseNot gradedqualityBmaintenanceSecurity scanner for MCP servers. Detects prompt injection, command injection, auth bypass, and excessive permissions across tools, resources, and prompts.19 npm3MIT
- AlicenseAqualityAmaintenanceSecurity for the MCP servers you use: detects tool poisoning, rug pulls, shadowing, secrets and supply-chain risk (OWASP MCP Top 10), with runtime guards and approved-server policy. Runs locally.17111 npmMIT
- AlicenseNot gradedqualityDmaintenanceSecurity auditor for MCP servers that enumerates tools, resources, and prompts, scans for injection patterns, classifies risk levels, and produces a scored report (0-100, grades A-F).16 PyPI2MIT
- AlicenseNot gradedqualityDmaintenanceScans MCP servers for security vulnerabilities, prompt injection, and tool poisoning, providing risk scores and protection.4MIT
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.