Loading ToolBench
A lightweight JSON-RPC gateway that routes method calls to multiple stdio-based MCP services (filesystem, HTTP, vector search). Supports static token authentication and scope-based policy enforcement.
MicroMCP Gateway exposes 5 tools across three microservices (fs, http, vector). Tool definitions are minimally viable but lack depth required for robust LLM interaction. All tools have names and basic descriptions, but descriptions are terse (10-50 chars), parameter documentation is sparse, output schemas are undocumented, and error handling provides no recovery guidance. The naming convention is inconsistent (fs.listDir uses camelCase, others use dot notation). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences. Parameter validation is delegated to service implementations with minimal visibility. Security concerns around path traversal (fs.listDir, fs.readFileText) and URL allowlisting (http.fetchText) are not reflected in tool descriptions. The vector service operates statelessly on in-memory docs with no persistence semantics documented.
List directory contents with file/directory type information
Read text file contents
Fetch HTTP/HTTPS URL and return text response with status and headers
Add a text document to the in-memory vector index
Search the vector index for documents similar to a query using cosine similarity
No output schemas documented for any tool. LLMs cannot infer response structure, plan downstream calls, or know what fields to extract. This blocks tool chaining and forces exploratory calling.
Tool descriptions are too terse (10-75 chars vs baseline 194 chars). Insufficient context for LLM to decide when/why to call each tool. Missing WHEN to use, WHAT happens (especially for write tools), and prerequisites.
No tool annotations for side-effects. fs.listDir and fs.readFileText are read-only but unmarked; vector.addDocument is destructive/stateful but unmarked. LLM cannot determine retry-safety or confirmation requirements.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 25 | - | v1 |
No input validation constraints or error recovery guidance. fs.listDir and fs.readFileText accept arbitrary paths with no traversal warnings. http.fetchText allowlist is server-side only, client cannot see valid patterns. vector.search 'k' parameter unbounded.
Security: fs tools expose arbitrary filesystem access without path normalization or sandboxing hints. No mention of read-only mount assumptions. http.fetchText allowlist checked server-side, but LLM has no visibility into valid domains.
No error classification or recovery guidance. Service errors are generic: 'path is required', 'query required', 'Method not found'. LLM cannot distinguish retryable vs user-fixable vs fatal errors.
Parameter descriptions are minimal or absent. 'path' in fs.listDir says 'Directory path to list (defaults to current directory)', missing format constraints, no examples of valid paths, no warning about symlinks. 'url' in http.fetchText says 'must be allowlisted' but doesn't explain allowlist rules.
vector.addDocument operates on in-memory state with no persistence semantics documented. LLM cannot know documents are lost on restart, nor whether the operation is truly idempotent (re-adding same id). No size/quota limits stated.