Loading ToolBench
MCP server that audits other MCP servers. Run MCPWatch security scans from inside your Claude Code / agent loop with 10 OWASP MCP Top 10 checks.
Four well-named, read-only tools with clear descriptions (avg 180 chars, within baseline 194). All tools have complete input schemas with proper types and required fields. Naming follows verb_noun pattern (scan_*, get_*). However, parameter descriptions are sparse, most lack detail on format, constraints, or usage context. Output schemas are not documented in the tool definitions, forcing LLMs to infer response structure. Error handling is minimal; no recovery guidance or actionable error messages visible. Security posture is strong (read-only, no secrets in params), but composition could be tighter, scan_directory and scan_github_repo overlap significantly and could share a unified interface.
Return the URL of a live MCPWatch SVG grade badge for a GitHub repository. Drop this into any README to show the current MCPWatch grade.
Fetch the current MCPWatch leaderboard of public MCP servers ranked by security grade. Returns the most recently scanned set with per-repo grade, score, and finding count. Use this to pick a safe MCP server from a set of candidates.
Run the MCPWatch security scanner on a local directory. Returns a 0-100 score, A-F letter grade, and findings from the 10 OWASP MCP Top 10 checks (command injection, path traversal, SSRF, prompt injection via tool descriptions, unauthenticated mutations, secret leakage, over-permissive filesystem scopes, missing rate limits, outdated dependencies, missing input schema validation).
Fetch the latest MCPWatch scan result for a public GitHub repository from the live crawler. Use this when you want to audit an MCP server by its GitHub owner/repo name instead of cloning it locally. Returns the same grade + findings shape as scan_directory.
Output schemas not documented. Tool descriptions do not specify what fields are returned (e.g., scan_directory returns 'score, grade, findings' but this is not formally declared). LLMs cannot plan downstream operations without knowing response structure.
Parameter descriptions lack actionable constraints. 'path' is described as 'Absolute path to the directory to scan' but does not specify: must exist? must be readable? max depth? size limits? These details force LLMs to guess or fail at runtime.
No error handling guidance. If scan_directory fails (permission denied, path not found, timeout), the tool provides no recovery hint. Error responses should guide the LLM: 'Path not found. Verify the absolute path exists and is readable.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Overlapping tool responsibilities. scan_directory and scan_github_repo perform the same security audit but on different sources (local vs remote). Consider a unified scan() tool with a 'source' parameter (local_path | github_owner_repo) to reduce cognitive load and improve composability.
get_leaderboard limit parameter lacks bounds documentation. Schema declares min=1, max=100, but description does not explain the default (20) or why the cap exists. Add: 'Limit results to 1 - 100 entries (default: 20). Higher limits may timeout.'