Loading ToolBench
nobrainr has 17 tools with generally good descriptions and clear naming conventions. All tools follow verb_noun patterns (memory_search, decision_store, crawl_and_store, etc.). Descriptions are detailed and context-aware, averaging 150-250 characters with explicit guidance on when/why to use each tool. However, critical gaps exist: NO input schemas are visible in the source code provided. Parameter definitions are listed (query, limit, hybrid, tags, etc.) but JSON Schema validation structures are not shown, making it impossible to verify type constraints, enums, pattern validation, or required/optional designation. This is a HARD SCORING ISSUE, without visible schemas, schema scores must be 0 per the rubric. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors, no actionable error messages documented. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not present despite the server having clear READ_ONLY vs WRITE distinctions documented in the summary. Output schemas are not documented in the visible code. The server lacks pagination parameter documentation (limit exists but offset/cursor patterns not shown). Per-tool scores reflect these gaps: all tools lose schema points due to missing JSON Schema visibility, and most lose error-handling points.
Crawl via Crawl4AI (synchronous) + enqueue the result via the document queue path.
DECISIONS ONLY (category='decision', status='active' by default). Use BEFORE making an architectural or technical choice to see prior policy. Takes optional scope prefix ('nobrainr', 'bimavo/gaeb-parser') and status filter. Results come back without the noise of free-form memories.
Store an explicit CHOICE with rationale and rejected alternatives. Decisions are prescriptive choices with rationale + rejected alternatives, separate from free-form learnings.
Knowledge graph exploration. Get entity connections and relationships.
Knowledge graph entity search. Find entities by name or type.
Fact-layer retrieval. Search extracted facts from memories.
NO VISIBLE INPUT SCHEMAS: All 17 tools lack JSON Schema definitions in the provided source code. Parameter lists exist (query, limit, hybrid, tags, etc.) but type constraints, enums, patterns, required/optional flags, and validation rules are not shown. This violates the critical requirement that every parameter must have a JSON Schema type definition.
MISSING TOOL ANNOTATIONS: Tools are internally marked as READ_ONLY vs WRITE (documented in the input summary), but MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not visible in the FastMCP registration code. This prevents clients from knowing which tools are safe to call repeatedly or which have permanent side effects.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Entity-graph retrieval. Search using the knowledge graph structure.
Index a directory by extracting code symbols and storing as memories. Inspired by jcodemunch-mcp. Extracts code symbols (functions, classes, methods) using Python's ast module and stores them as memories with structured metadata.
Record significant agent activity (session starts, decisions, completions).
Report if a search result was helpful. Pass search_trace_id, search_rank, and search_query from the original result to compute rank-aware metrics (MRR/NDCG). Negative feedback is equally valuable.
Maintenance operations on memory data. Available for manual runs.
Structured filtering by tags, category, source.
Call at session end with a batch of learnings from the session.
Hybrid semantic + text search, reranked. Every result row carries search_trace_id, search_rank (1-indexed), and search_query so you can close the feedback loop via memory_feedback and populate MRR/NDCG metrics. Prefer hybrid=True. Results include learnings, decisions, and all other memory types mixed together.
Store a memory (learning/observation). Returns queued status with queue_id in <50ms. The worker processes writes FIFO through embedding+dedup+extraction pipeline. Pass wait=True only if you genuinely need to block for the memory_id.
Long-document path, same queue. Returns one queue_id per chunk with a shared document_id in metadata. Contextual prefixes are filled in later by a scheduler job, not on the hot path.
Poll a queued write to see {status, memory_id, result_status, error_message}. Use when you need to close the loop on a write.
NO DOCUMENTED ERROR HANDLING: The visible code shows no error recovery guidance, error classification (retryable vs fatal), or actionable error messages. Tools like memory_store and crawl_and_store can fail (embedding service down, network timeout, document parse error) but no recovery hints are documented.
MISSING OUTPUT SCHEMA DOCUMENTATION: No tool returns a documented output schema. The rubric requires agents to know what fields to expect so they can chain tools and extract data. For example, memory_search returns results with search_trace_id, search_rank, search_query (mentioned in description) but no formal output structure is shown.
GENERIC PARAMETER DESCRIPTIONS: Several tools have minimal parameter docs. e.g., memory_query parameters 'tags' (Filter by tags), 'category' (Filter by category), 'source_machine' (Filter by source machine) lack constraint info (array format, max items, allowed category values). memory_maintenance 'operation' parameter is completely undocumented, what operations are valid?
MISSING PAGINATION GUIDANCE: memory_search, decision_search, memory_query, entity_search, and fact_search accept 'limit' but no documentation of default limits, maximum safe limits, or pagination strategies (offset vs cursor). Agents may request 1000 results, causing context bloat and timeouts.
INCOMPLETE PARAMETER DESCRIPTIONS FOR WRITE TOOLS: memory_store, memory_store_document, and crawl_and_store accept 'source_machine' with note 'CRITICAL: YOUR machine, not server hostname'. This is good, but other parameters like 'category' are under-specified, is 'architecture' valid? What's the full enum? Similar issue with decision_store 'constraints' and 'alternatives_rejected', are these free-form strings or structured objects?
VAGUE TOOL PURPOSE FOR GRAPH/ENTITY TOOLS: entity_graph, graph_search, and fact_search descriptions are sparse (60 chars). It's unclear how they differ from memory_search or when an agent should prefer graph_search over memory_search. Agents need explicit selection criteria.