Loading ToolBench
MCP protocol bridge middleware that forwards tool calls and resource requests to Lisp backends (Gendl, Emacs) over HTTP. Acts as a neutral middleware layer with stdio JSON-RPC transport.
This MCP server has 6 tools with mixed quality. Tool definitions exist and have basic schemas, but there are significant gaps in consistency, parameter clarity, and error handling guidance. Naming is generally acceptable (verb-first pattern respected), but descriptions are brief and some parameter documentation is minimal. Output schemas are not documented. Critical issue: the http_request tool accepts 'body' and 'content' as alternative parameters for the same thing, creating ambiguity. Error handling exists but lacks actionable recovery guidance. lisp_eval and ping_lisp are defined in test files (regression-tests/harness.js) rather than production source, suggesting incomplete tooling. Overall, this reads as a functional wrapper but not production-grade for agent integration.
Get documentation content from the backend server
List available documentation from the backend server
Send an HTTP request to the specified path
Evaluate Lisp code on the backend Lisp server
Search the Lisply corpus for definitions and documentation
Ping the backend Lisp server to check availability
http_request tool has parameter ambiguity: both 'body' and 'content' accepted as synonyms for request body. This forces LLMs to reason about which parameter to use and creates silent failure modes when both are supplied or one is omitted.
Output schemas are not documented for any tool. LLMs cannot determine what fields to expect in responses, forcing them to make assumptions about downstream tool compatibility and hindering composition.
Descriptions are generic and under 100 characters for most tools (ping_lisp, get_docs_list, get_docs). They lack context about when to use each tool, what problem they solve, or dependencies on other tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
lisp_eval and ping_lisp are defined in regression-tests/harness.js (test infrastructure) rather than production source code. Tool definitions should be in the main handler module for clarity and maintainability.
Error handling exists but provides minimal recovery guidance. Errors in toolCall.js catch blocks return generic messages like 'Error calling tool: X' without suggesting next steps or categorizing errors as retryable/fatal.
lisply_search 'limit' parameter lacks range constraints. No documentation of minimum/maximum values, allowing LLMs to request unbounded result sets.
http_request tool is inherently dangerous without clear security guidance. Headers parameter accepts any object, risking authorization header injection. No mention of rate limits, SSRF prevention, or content-type constraints.
get_docs 'id' parameter description is vague ('Document ID to retrieve') and provides examples ('claude-md', 'readme', 'yadd') in the description text.