Loading ToolBench
MCP Server for LightRAG that provides tools to query documents, insert text/files, upload documents, and manage document indexing through the LightRAG API
The server has 7 tools with generally present descriptions and visible input schemas. However, there are significant quality gaps: (1) Missing output schema documentation across ALL tools, the rubric requires documented return types for A+ servers; (2) Parameter descriptions vary in quality; some are clear (query, mode) while others are overly generic or lack actionable constraints; (3) One parameter (response_type in query_document) has a description in Russian ('Определяет формат ответа'), which breaks usability for English-speaking agents; (4) No enum constraints on string parameters that clearly should have them (mode, response_type); (5) Error handling is present via format_response() but lacks recovery guidance, agents don't know what to do on failure; (6) Tool naming follows verb_noun convention correctly but lacks discovery of related tools; (7) No tool annotations (readOnlyHint, destructiveHint) despite clear risk classifications. The server is functional but falls short of production-grade quality due to missing schemas, weak error guidance, and incomplete parameter descriptions.
Get list of all uploaded documents
Add batch of documents from directory to LightRAG
Add text directly to LightRAG storage
Add document from file to LightRAG
Execute a query to documents through LightRAG API
Start scanning LightRAG /inputs directory for new documents
Upload document from file to LightRAG's /inputs directory and start indexing
Missing output schema documentation across ALL 7 tools. The rubric requires 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' None of the tools have documented return types, field names, or result structure. This is a critical gap for production tools.
Duplicate tools: insert_file and upload_document are indistinguishable. Both accept file_path, both have nearly identical descriptions ('Add document from file'), both have WRITE risk. This violates the composition rule: 'Avoid multiple tools that do the same thing differently.' LLMs will conflate them, wasting reasoning and risking duplicate calls.
Parameter description in Russian (response_type: 'Определяет формат ответа. Примеры: ...'). This breaks usability for English-speaking agents and is unprofessional. Must be in English.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
No enum constraints on string parameters that should have them. query_document.mode is described as '(mix, semantic, keyword, global, hybrid, local, naive)' but not declared as an enum in the schema. response_type has a default but no enum constraint. This invites LLM hallucination of invalid values.
Error handling lacks recovery guidance. format_response() wraps errors in {status: 'error', error: string}, but descriptions don't guide LLMs on what to do next. E.g., 'File not found. Try scan_for_new_documents() to index files.' Missing error-recovery patterns per the rubric.
No tool annotations. query_document has READ_ONLY risk, yet no readOnlyHint. insert_*, upload_*, scan_* are WRITE operations, yet no destructiveHint. The rubric rewards 'tool annotations (readOnlyHint/destructiveHint/idempotentHint)' as a current-spec pattern. Missing annotations weaken agent planning and safety.
Ambiguous tool discovery. Tools insert_document, upload_document, insert_file, insert_batch, and scan_for_new_documents all ingest content. Descriptions don't clarify when to use each: insert_document takes raw text; insert_file takes a file path; upload_document also takes a file path and mentions '/inputs directory'. This violates: 'When multiple tools operate on the same resource, their names must make the distinction obvious.'
No pagination or result limits documented. query_document has top_k=60 default (reasonable), but get_documents() doesn't mention a limit. If there are thousands of documents, returning all of them will blow the context window. The rubric requires: 'Even if the API allows returning thousands of items, cap results at a reasonable limit (e.g. 20-50).'
Async behavior undocumented. scan_for_new_documents and upload_document mention 'start' indexing, but descriptions don't clarify: is this blocking? Does it return immediately and index asynchronously? Does it return a job ID or status? Agents need explicit guidance.