Loading ToolBench
Standalone MCP RAG server: hierarchical knowledge graph on Turso/SQLite with pluggable embeddings
NeuRAG has 7 tools with complete schemas and descriptions. Naming follows verb_noun convention (knowledge_*). Descriptions are detailed and contextual (avg ~180 chars), exceeding the 10-1024 baseline. All parameters have type definitions and descriptions. However, several tools lack output schema documentation, error handling guidance is minimal, and some parameter constraints could be more explicit. The server demonstrates solid foundational quality but falls short of production-grade polish in error recovery and response shaping.
Attach previously indexed chunks to a node.
Create a node in the hierarchy.
Chunk a file or directory without saving. Returns JSON list of chunks. LLM then calls knowledge_add_node + knowledge_add_chunks to organize them. For whole folders prefer knowledge_ingest (server-side, no chunks through context).
Graph-ize a folder OR a single document server-side in ONE call: nodes from the folder structure, chunks, embeddings, links. Runs in background — returns a job id immediately; poll knowledge_ingest_status. Re-ingesting the same file REPLACES its chunks, so updating a document is just calling this again. Prefer this over knowledge_index: no chunk text travels through the model's context.
Status of ingest jobs started with knowledge_ingest (all jobs, or one via job_id).
Search the USER'S OWN indexed material — their documents, notes and code, not general knowledge. Use it whenever the question could touch what they have indexed: answering from training data instead means answering about somebody else's version of the subject, confidently and unverifiably. Costs one round-trip; skip it for procedural turns, for general knowledge the vault would not hold, and for anything already answered in this conversation. Cite the node or source you used, so the user can check it.
Output schemas not documented. Tools return results but LLMs cannot plan downstream calls without knowing response structure (e.g., knowledge_query returns what fields? knowledge_ingest_status returns what status object shape?).
Error handling lacks recovery guidance. No indication of what LLM should do on failure (retry? ask user? call alternative tool?). E.g., knowledge_ingest could fail if path is invalid or permissions denied, no guidance provided.
knowledge_status description is truncated ('truncated in source, but represents vault statistics and health'), incomplete documentation prevents LLM from understanding when/why to call it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Status of the knowledge base (truncated in source, but represents vault statistics and health)
knowledge_ingest_status lacks pagination/limit parameters. If many jobs exist, response could be unbounded and blow context window. No indication of result count or next_cursor.
knowledge_add_chunks chunks parameter is an array of objects with optional fields (source, section, chunk_index). No validation rules documented, LLM cannot know if all fields are required or which combinations are valid.