Loading ToolBench
Security audit for MCP servers and agent tool-chains. Read-only: never executes the code it scans.
Three well-defined audit tools with complete schemas, clear descriptions, and proper annotations. All tools are read-only with explicit destructiveHint:false and readOnlyHint:true. Descriptions are detailed (150-250 chars) and explain scope clearly. Input schemas use proper JSON Schema with enums and type constraints. However, output schemas are not documented, LLMs cannot predict what fields to expect from scan results. Parameter descriptions are adequate but could be more prescriptive about format/constraints. No error handling guidance visible in tool definitions.
Return the reasoning behind one of the seven rules: what it detects, why it matters, the audit it came from, and what it deliberately does not fire on. Offline and read-only.
Audit a public GitHub repository's MCP tool definitions and return structured findings. Extracts tools from TypeScript, JavaScript, Python and Go source, then applies seven rules covering unguarded destructive operations, annotation mismatches, injection surface in tool descriptions, hidden instructions aimed at automated systems, personal data in parameters, credentials in parameters, and unbounded scope. Read-only: clones nothing, executes nothing, and never calls tools/call on the audited server. Operates only on the repository named in the argument.
Audit a tools/list response that you already have, without any network access. Accepts the JSON-RPC result object, a bare list of tool definitions, or the tools array itself. Use this to check a server you are already connected to. Read-only and offline.
Output schemas not documented. LLMs cannot predict the structure of scan findings (fields, types, nesting). This forces agents to guess at response shape and risks misinterpreting results.
Parameter 'manifest' in scan_tool_manifest lacks format guidance. Description says 'A tools/list result, or {"tools": [...]}' but does not specify whether nested tool objects must have 'inputSchema', 'annotations', etc., or what happens if they are malformed.
No error handling guidance in tool descriptions. If scan_repository fails (e.g., invalid GitHub URL, repo not found, network timeout), the description does not tell the LLM what to do next or how to recover.
Parameter 'min_severity' defaults to 'low' per description, but no explicit default value is set in the schema. LLMs may not infer the default and pass the parameter unnecessarily.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |