Loading ToolBench
MCP server for running source code security reviews with an LLM
Server has 7 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly short), and input schemas are present with type definitions. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool or WHAT happens. Parameters lack detailed constraints (enums, ranges, formats). Output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages. The `report_done` tool accepts arrays without pagination or size limits. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, DESTRUCTIVE). Tool composition is reasonable (single responsibility), but descriptions do not explain dependencies or prerequisites.
Get the next security review task to execute
Load a security review plan from a file path
Pause the current security review
Report completion of a security review task with findings
Reset the security review to initial state
Resume a paused security review
Get the current status of the security review
Descriptions are too short (20-50 chars) and lack LLM-optimized guidance. 'Get the next security review task to execute' does not explain WHEN to call it, what state it requires, or what the response contains. Descriptions should be 50-200 chars and answer: What? When? Prerequisites?
No output schemas documented. LLMs cannot plan downstream calls or extract required fields (e.g., task_id from get_task, or status fields from status). Every tool should document its return type and key fields.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. 'reset' is DESTRUCTIVE and 'pause'/'resume' are WRITE operations, these should be annotated so LLMs understand side effects and retry safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Parameter descriptions lack constraints. 'outcome' in report_done accepts 'FINDING, CORROBORATION, or NO FINDINGS' but is not declared as an enum. 'finding_ids' and 'evidence' are arrays with no size limits or format guidance. LLMs need explicit enums and constraints.
Error handling is minimal. No recovery guidance, no actionable error messages, no categorization (retryable vs fatal). If load_plan fails, the LLM has no guidance on what to try next.