Loading ToolBench
A TypeScript MCP server for document management and semantic search with embeddings
This server has 8 tools with acceptable naming conventions (all verb_noun format) and mostly present descriptions. However, there are critical gaps in schema completeness, parameter documentation, and output schema definition. Several tools have descriptions that are adequate but lack depth regarding when to use them vs alternatives. The most severe issue is the absence of documented output schemas for any tool, LLMs cannot reason about downstream chaining or extract the right data fields. Additionally, the code sample is truncated (search_documents tool implementation cuts off at 'searchRes'), preventing full verification of actual behavior and return types. Parameter descriptions exist but many lack constraint detail (ranges, enums, formats). Error handling guidance is minimal, most errors throw generic messages without recovery hints.
Add a new document to the knowledge base
Delete a document from the collection
Returns a window of parent content sections around a central parent_index. Use parent_index values from search results. Always tell the user if result is truncated because of length.
Use this tool only when user explicitly requests it. Retrieve a specific document by ID. Always tell the user if result is truncated because of length. for example if you recive a message like this in the response: 'Tool response was too long and was truncated'
List all documents in the knowledge base
Search for relevant chunks across ALL documents in the knowledge base using semantic similarity (hybrid: full-text + vector). Useful for cross-document search when you don't know which document contains the answer.
NO OUTPUT SCHEMAS DOCUMENTED for any tool. LLMs cannot reason about chaining or field extraction. For example, does add_document return {id, title, ...}? Does search_documents return {chunks: [{id, text, score, ...}], total_count, ...}? Code sample is truncated and doesn't show actual return types.
Parameter constraints missing: 'limit' parameters (search_documents, search_all_documents) lack documented defaults and min/max bounds. 'before'/'after' in get_context_window have no numeric constraints. This invites LLM hallucination (e.g. passing limit=999999) and API abuse.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Search for chunks within a specific document using semantic similarity. Always tell the user if result is truncated because of length. for example if you recive a message like this in the response: 'Tool response was too long and was truncated'
Search within a document using Gemini AI for advanced semantic analysis and content extraction.
Insufficient error guidance. Most descriptions do not tell LLMs what to do on failure. E.g., search_documents code shows it throws 'Document not found' error, but description doesn't say 'try list_documents first'. delete_document shows confirmation logic in code but not documented. add_document has no mention of what happens on title collision.
Unclear differentiation between similar tools (search_documents vs search_all_documents vs search_documents_with_ai). Descriptions explain WHAT each does but lack guidance on LLM decision logic: When do I use standard semantic search vs Gemini? Cost/latency tradeoff? All three overlap conceptually.
Metadata parameter in add_document uses passthrough().optional() with no constraint or example. LLMs have no idea what keys/values are valid or required. This is under-specified.
search_documents description explicitly tells user 'Always tell the user if result is truncated because of length', but this is LLM instruction embedded in tool description. This should be LLM system prompt guidance, not tool description content. Violates separation of concerns.
Code sample is truncated (search_documents response ends at 'searchRes'). Unable to verify actual return schemas, error handling, or idempotency guarantees. Complete implementation code is required for full assessment.