Loading ToolBench
AWS Lambda-based MCP server for semantic and keyword-based document search, chunk retrieval, and project/document management via Admin REST API
The server provides 6 read-only tools with basic but incomplete definitions. All tools have names starting with action verbs (list_, get_, search_) which is good naming convention. However, descriptions are uniformly terse (17-56 characters), falling well below the 194-char baseline for production tools. Input schemas are present and use proper JSON Schema structure with types, but lack critical constraints like enums for constrained inputs (e.g., semanticSearch.limit has no bounds), and descriptions for most parameters are minimal. No output schemas are documented, making it difficult for LLMs to plan chained calls. Error handling is basic, the tools.js handler catches errors but returns generic messages ('Error executing tool: ...') without recovery guidance. The semantic_search tool lacks documentation of what 'semantic similarity' means or how to interpret results. No pagination, no rate-limiting guidance, and no per-tool permission declarations despite read-only claims.
Search documents using BM25 keyword-based ranking
Retrieve a specific document by ID
Search documents using semantic/vector similarity
Tool descriptions critically short (10-56 chars vs 194-char baseline). Examples: 'List all categories in a project' (32 chars) does not explain when to use this tool, what data structure is returned, or dependencies on other tools.
No output schemas documented. LLMs cannot predict what fields listTopics returns (array of strings? objects with id+name? nested structures?), forcing exploratory calls or assumption-based errors. See pattern:tool which mandates documented return types.
Parameter descriptions are trivial. 'projectId' described as 'Project ID' and 'query' described as 'Search query' violate the pattern:tool-description baseline of describing WHAT the param controls, WHEN it's needed, and any constraints. No guidance on projectId format (UUID? alphanumeric? case-sensitive?).
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 7 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
semanticSearch.limit parameter lacks bounds. No min/max declared in schema or description. Can an LLM pass limit=10000? limit=0? limit=-1? Unbounded numeric parameters invite abuse per pattern:constrained-input baseline.
Error handling returns generic text ('Error executing tool: <message>') without recovery guidance. Per pattern:recovery-guide, errors should indicate what to do next. E.g., if projectId is invalid, should the LLM call listProjects first? Should it try a different format?
No pagination support or result limits. listTopics and listDocuments have no limit/offset/page parameters. Per mxe:enforce-result-limits, tools returning lists should cap results (baseline 20-50) and accept pagination. Returning 1000 items wastes context and degrades LLM reasoning.
No tool-level permission declarations. All 6 tools claim risk=READ_ONLY but provide no scope/permission metadata (e.g., 'read:projects', 'read:documents'). Per pattern:scope-declaration, tools should declare required permissions for audit and least-privilege config.
semanticSearch lacks documentation of semantic similarity algorithm, embedding model, or ranking method. 'Search query' description does not explain the expected query format (natural language? keywords? structured syntax?) or how results are ranked/scored.