Loading ToolBench
An MCP server that injects tools from external MCP servers, provides native tools (clojure-eval, search_tools, handoff management), and manages governance/policy for tool execution
mcp-injector exhibits significant quality gaps across naming, descriptions, and security. Tool definitions are present but lack depth. Naming is inconsistent (verb-first for some tools like 'search_tools' and 'get_tool_schema', but non-verb names for 'handoff_start', 'handoff_read', 'checkpoint_status', 'prompt_template'). Descriptions are sparse and generic, most lack context about when to use the tool or what it returns. Parameter descriptions are minimal. Critical security issues: 'clojure-eval' executes arbitrary code with only 'safety tripwires' (undefined); 'exec' is a pass-through shell command executor with no filtering. Output schemas are completely undocumented in the source code provided. No error handling patterns visible. Tests exist but do not demonstrate schema validation or comprehensive error cases.
Returns real JVM telemetry including heap usage, heap max, heap usage percentage, and uptime
Executes Clojure code with safety tripwires and policy enforcement
Lists known research conventions available in the system
Executes shell commands (pass-through tool, not filtered by injector policy)
Retrieves the input schema for a specific tool by name
Reads back a completed handoff workspace with findings and status
Creates a workspace for a research handoff with validated slug, findings file, and status tracking
CRITICAL: 'clojure-eval' executes arbitrary Clojure code. Safety is described only as 'safety tripwires and policy enforcement' with no specification of what those mechanisms are, how they work, or how they prevent escape. This violates the principle that destructive operations must have clear, documented safeguards.
CRITICAL: 'exec' tool performs unfiltered pass-through shell execution. The description explicitly states '(pass-through tool, not filtered by injector policy)'. This permits arbitrary command execution with no sanitization against command injection or path traversal. An agent can delete files, modify system settings, or exfiltrate data.
No output schemas documented for any tool. Test code reveals return structures (e.g. checkpoint_status returns jvm object with heap_used_mb, heap_max_mb, heap_usage_pct, uptime_ms), but these are never formalized in tool definitions. LLMs cannot plan downstream tool chains or understand what data is available without documented return schemas.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
Retrieves a prompt template by name with optional variable substitution
Search tools by name or description across all registered MCP servers
Inconsistent naming convention. 'clojure-eval' uses hyphen; most others use underscore. 'search_tools' and 'get_tool_schema' follow verb_noun pattern; 'handoff_start', 'handoff_read', 'checkpoint_status', 'prompt_template', 'exec' do not. Non-verb names like 'checkpoint_status' and 'exec' violate the pattern that tool names should start with action verbs (get_, create_, update_, delete_, search_, list_).
Sparse parameter descriptions. Parameters like 'slug', 'context', 'question', 'limit', 'variables', 'cmd' lack detailed guidance. Example: 'slug' description says 'Workspace identifier (alphanumeric with hyphens, no path traversal allowed)' which hints at constraints, but does not specify minimum/maximum length, exact pattern, or examples of valid values. LLMs cannot reliably generate conformant input without examples or regex patterns.
No error handling or recovery guidance documented. Tests show error cases (invalid slugs, missing handoffs), but the tool definitions provide no guidance on what error codes the LLM should expect, whether errors are retryable, or what the agent should do next. A bare 'error' status with no context is not actionable.
Tool descriptions are too brief and lack context. Baselines indicate 50-200 characters for optimal LLM selection. Many descriptions here are under 100 characters and do not explain when to use the tool instead of alternatives. Example: 'checkpoint_status' description does not explain that it returns JVM metrics and when an agent should call it (e.g., to monitor resource usage). 'conventions_list' is 48 characters and provides no guidance.
Security: Slug validation is performed inside the tool (tests show rejection of '../', '.hidden', etc.), but input constraints are not formalized in the schema as a regex pattern. JSON Schema patterns and minLength/maxLength would allow clients to validate early and reduce server load.