Loading ToolBench
Multi-project Personal Knowledge Base — Graph RAG + YouTube Ingestion. MCP server providing knowledge base search, retrieval, entity exploration, and document ingestion tools.
Grimoire has well-structured tool definitions with clear naming (verb_noun pattern: knowledge_search, knowledge_retrieve, knowledge_add) and comprehensive descriptions (avg 180 chars, within 10-1024 baseline). All 8 tools have input schemas with type definitions and parameter descriptions. However, output schemas are completely undocumented, no tool declares what fields it returns, forcing LLMs to infer structure. Error handling is absent: no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Parameter constraints are good (enums for mode, defaults for project), but descriptions lack actionable format guidance (e.g., 'file_path' should specify '.txt only' explicitly). Tool composition is sound: knowledge_retrieve vs knowledge_search distinction is clear, and tools chain logically (search → source → entity_connections). Security: no secrets exposed as params, but no audit logging or permission gates visible.
Add text content directly to a project's knowledge base. Text will be chunked, entities extracted, and integrated into the knowledge graph.
Add a local .txt file to a project's knowledge base. Reads the file and processes it the same as knowledge_add.
Explore one entity's neighborhood in the knowledge graph — its direct connections and all relationships. Use when asked about a specific named concept: 'как VSL связан с другими', 'что связано с Dan Kennedy'. Requires exact or near-exact entity name. If unsure of the name, use knowledge_retrieve first to discover it.
List all available projects in the knowledge base with their descriptions.
DEFAULT tool for knowledge base questions. Returns raw graph data (entities, relationships, text chunks) without LLM synthesis — Claude synthesizes directly for better quality and speed. Skips Qwen, no extra latency.
Search with server-side Qwen synthesis. SLOW (~20s) and lower quality — use knowledge_retrieve instead in most cases. Only use when you specifically need Qwen's perspective.
No output schemas documented. Tools return data but LLMs cannot plan downstream calls or extract fields reliably. knowledge_search returns 'sources' and 'entities' (inferred from code), but this is not declared in the tool definition.
No error handling guidance. Tools can fail (API timeout, invalid project, malformed query) but return no recovery hints. LLMs cannot distinguish retryable errors from user-fixable ones.
knowledge_add_file parameter 'file_path' lacks format constraints. Description should state '.txt files only' and max file size explicitly, not leave LLM to guess.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
Search across ALL projects simultaneously. Use only when the question might span multiple knowledge domains. Slower than knowledge_search. For single-project questions, use knowledge_search instead.
Fetch the full original transcript/source text by name. Use AFTER knowledge_search when you need exact quotes, full context, or want to verify what a specific source actually says. Source names come from the 'sources' field in search results. Returns: full text of the transcript.
knowledge_projects returns empty inputSchema properties ({}). No output schema declared. LLM cannot know what fields describe a project (name, description, size, created_at, etc.).
No pagination support visible. knowledge_search_all searches 'ALL projects' but no limit, offset, or cursor parameters. Large result sets could exhaust context window.