Loading ToolBench
MCP orchestrator/proxy that fronts Neuron + NeuRAG, routing tool calls to registered MCP servers
Six tools with complete JSON schemas and descriptions. Naming follows verb_noun pattern (knowledge_ingest, knowledge_query). Descriptions are substantive (100-300 chars), explaining WHAT and WHEN. However, parameter descriptions lack depth, many omit format constraints, ranges, or validation rules. Output schemas are undocumented; LLMs cannot predict response structure. Error handling is absent from descriptions. No tool annotations (readOnlyHint/destructiveHint). knowledge_ingest and knowledge_add_chunks are WRITE operations but lack confirmation/dry-run patterns. knowledge_query description is excellent (explains user-specific search, cites sources), but others are generic.
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 undocumented. LLMs cannot predict response structure (fields, types, pagination). knowledge_ingest returns 'job id' but format/type unknown. knowledge_query returns results but structure opaque.
Parameter descriptions lack validation rules. 'path' (knowledge_ingest, knowledge_index) omits format constraints (absolute vs relative, file vs directory handling). 'top_n' (knowledge_query) has min/max in schema but not in description text, LLMs cannot read JSON Schema constraints.
WRITE operations lack confirmation/dry-run patterns. knowledge_ingest and knowledge_add_chunks modify state (ingest files, attach chunks) but offer no preview or confirmation step. Agents cannot verify intent before destructive actions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
No error handling guidance. Descriptions do not explain failure modes or recovery steps. E.g., knowledge_ingest_status does not document what happens if job_id is invalid or job not found.
No tool annotations. Tools lack readOnlyHint (knowledge_query, knowledge_index, knowledge_ingest_status are read-only) and destructiveHint (knowledge_ingest, knowledge_add_chunks modify state). LLMs cannot infer safety properties.