Loading ToolBench
Persistent memory for agents. Corrections stick, context compounds, every session starts smarter.
This is a well-designed knowledge management MCP server with strong conceptual clarity around Zettelkasten principles. Tool names follow verb_noun conventions (knowledge-store, knowledge-search, knowledge-get) and descriptions are substantially above the baseline (many 150 - 250 chars, rich with context and structure examples). Schemas are comprehensive with proper typing and enum constraints. However, several tools lack explicit output schema documentation in the visible code, parameter descriptions could be more actionable in places, and error handling guidance is not explicitly visible in tool definitions. The server demonstrates mature patterns around structured input (kind enums, lifecycle constraints, project scoping) and knowledge domain specificity, but falls short of A-grade exceptional quality due to incomplete output schema visibility and some generic parameter documentation.
Fetch contextual information: agent docs, project authority, preferences, and recent activity. Useful for understanding vault layout and agent-specific guidance without a query.
Retrieve a note by ID with full content and metadata. Use after knowledge-search to fetch exact results by noteId.
Run contextual graph review of link health: find broken wikilinks, analyze contextual link validity, and assess vault connectivity.
Extract article content as clean markdown. Returns title, content, word count, and metadata. PREFER passing html from your own web tools (Playwright, Exa, web_fetch) — the built-in url fetcher is a basic fallback that cannot render JavaScript or bypass bot protection. Treat extracted content as a candidate; store it only when it passes the precision gate.
Maintain and audit the knowledge base. Actions include promotion, archival, deletion, rebuilding, formatting, upgrading, reviews, deduplication, embeddings, agent docs injection, scope audits, link health checks, and global publishing.
Output schemas are not explicitly documented in visible tool definitions. While input schemas are comprehensive (knowledge-store shows title, content, kind, summary, guidance, status, lifecycle, tags, project, client, related, model, dryRun, disposition, noteId, expectedUpdatedAt, confirm, token), the corresponding output structure for each tool is not visible in the source provided. This prevents LLMs from planning what fields to extract after a call.
knowledge-get, knowledge-context, knowledge-maintain, knowledge-health, and knowledge-open have generic or sparse descriptions that fail to clarify WHEN to use them vs related tools or WHAT specific structure they return. E.g. 'Fetch contextual information' lacks context about what 'contextual' means or why an agent should call it instead of knowledge-search.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Batch extract candidates from text, URLs, or session context. Pre-screen multiple candidates before storage. Returns structured metadata for each candidate without persisting them.
Open a note or vault in Obsidian. Can launch Obsidian if not running, or reveal a specific note if already open.
Search the persistent knowledge base using full-text search and semantic similarity. Accepts natural language queries, keywords, or phrases. Returns full content by default; compact mode is an additive metadata view with exact knowledge-get pointers.
Store knowledge in the persistent Zettelkasten knowledge base. One concept per note. Content structure by kind: • decision: context, options, decision, tradeoffs, consequences, reversibility • procedure: trigger, prerequisites, steps, verification, failures • observation: what, where, why it matters, implications • reference: summary, excerpts, content • domain: agent role, scope, conventions, playbook, boundaries Use knowledge-template for full structure with examples.
Retrieve structure templates and guidelines for note kinds. Helps understand expected content layout, conformance rules, and examples for each kind.
knowledge-open performs local Obsidian integration (launches app, opens vault, reveals notes), this is a REVERSIBLE side effect that the agent should acknowledge. The description does not make clear that this tool has side effects on the user's system (spawning processes, modifying vault state). Error handling and confirmation patterns are not visible.
knowledge-mine's 'candidates' parameter accepts an array of pre-structured objects, but the schema of each candidate object is not documented. This forces the LLM to guess at the expected candidate structure (e.g., does it have title, content, kind, tags?). Schema completeness is ~65% for this tool.
knowledge-store's dryRun and confirm parameters form a review-then-confirm workflow, but the token parameter's lifecycle (when it's returned from a preview call, how long it's valid, what happens if it expires) is not documented. This is an implicit multi-step pattern that could fail silently.
knowledge-search returns results 'in full (default) or compact' mode, but the schema for compact mode is not documented. An LLM cannot understand what 'additive metadata view with exact knowledge-get pointers' means without seeing the actual structure. Compact mode response structure must be explicit.