Loading ToolBench
An Elixir-based MCP server implementation with tools, prompts, and resources support
Two tools with minimal but visible definitions. Both have names, descriptions, and input schemas present in the source code. However, descriptions are extremely brief (10-22 chars), input schemas lack parameter descriptions entirely, output schemas are undocumented, and error handling is minimal. The 'query' tool exposes potential SQL injection risks without validation guidance. Overall, this is a bare-bones implementation suitable only for testing, not production use.
Returns provided text
Run a read-only SQL query
Descriptions are critically short (10-22 chars), below the 34-char p10 baseline. 'Run a read-only SQL query' (27 chars) and 'Returns provided text' (21 chars) lack context about WHEN to use each tool, what they return, and any prerequisites.
Input schemas have NO parameter descriptions. The 'sql' param in 'query' tool lacks any explanation of expected format, constraints, or whether dynamic SQL is supported. The 'text' param in 'echo' is similarly undocumented. LLMs cannot infer parameter intent from names alone.
Output schemas are completely undocumented. Tools return responses but no schema is defined in ToolsController listing or elsewhere. Caller must reverse-engineer output structure. E.g., 'query' returns JSON-encoded text, but LLMs don't know the shape of query_result objects or how to extract fields.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
'query' tool description claims 'read-only' but no validation enforces it. LLMs could pass DROP TABLE or INSERT statements; tool relies on caller honesty. No input sanitization against SQL injection visible in call_tool/3. Per pattern:tool-gateway, all agent input is untrusted.
Error handling returns plain text in a 'text' field with isError=true. No recovery guidance. E.g., 'invalid arguments - `sql` is missing' tells the LLM nothing about what sql format is expected or how to proceed. Per pattern:recovery-guide, errors must guide the agent.
No pagination or result limits. 'query' tool returns hardcoded mock result [%{name, age}] but no cap on real result count, no limit parameter, no offset/cursor. Per pattern:paginated-result, tools returning lists should support pagination.
Parameter naming lacks type suffix. 'sql' param does not clarify if it is a string, whether it should be a prepared statement, or if parameterized queries are supported. Per naming baseline, suffix ambiguous params with type: 'sql_string', 'sql_prepared', etc.