Loading ToolBench
Cerebro Central local para IA. Navegación GraphRAG con SurrealDB y MCP. A local central brain for AI with GraphRAG navigation using SurrealDB and MCP.
NexusBrain MCP has moderate definition quality with mixed results across tools. All 6 tools have descriptions and basic schemas, but several lack depth in parameter documentation, output schema specificity, and error handling guidance. Parameter descriptions are present but often generic (e.g., 'The identifier of the code chunk node'). No tool annotations (readOnlyHint/destructiveHint) are visible despite clear risk classifications. Output schemas are not documented in the code. The server follows a consistent naming pattern (verb_noun) but parameter naming could be more specific (e.g., 'node_id' is generic; 'code_chunk_id' would be clearer). Error handling and recovery guidance are absent from tool definitions.
Analyzes the "blast radius" of a code chunk.
Shows the execution flow or outgoing dependencies of a code chunk.
Ingests a repository into the database and builds the Knowledge Graph.
Records an architectural decision, the solution to a complex bug, or a business rule.
Searches the project historical log (long-term memory).
Searches for code chunks in the repository using semantic search (meaning).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in metadata. Tools marked WRITE risk (record_decision, ingest_path) should declare destructiveHint/non-idempotent status to prevent accidental agent misuse.
Output schemas are not documented. Callers cannot determine what fields will be returned, blocking downstream tool composition and forcing LLMs to guess structure. E.g., semantic_code_search likely returns code chunks with metadata, but this is not formally declared.
Parameter descriptions are generic and lack actionable constraints. 'The identifier of the code chunk node' does not explain format, source, or how to obtain node_id. Descriptions should answer: What is valid? Where do I get this value? What happens if invalid?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 10 | - | v1 |
No error handling guidance. Tools lack recovery hints (e.g., 'If node_id is invalid, call semantic_code_search() first to find a valid chunk'). Error responses should be actionable for agents.
get_execution_flow lacks a description for what 'execution flow' means. Does it return call graphs, data dependencies, or control flow? The description (50 chars) is too vague for LLM selection.
ingest_path accepts a repo_path parameter but does not validate or document the expected path format (absolute vs relative, supported VCS types, size limits). No guidance on long-running ingestion behavior or progress reporting.
record_decision has an optional related_code_id parameter with null default, but no description of consequences if omitted. Does the decision still persist? Is linking optional or recommended? This ambiguity invites misuse.
semantic_code_search limit parameter defaults to 5 with no explanation of the default rationale or acceptable range. LLMs cannot determine if 5 is safe or if they should request more results.