Loading ToolBench
Personal Knowledge MCP Server — structured retrieval, knowledge graph, and multi-granularity summaries
Personal KB MCP shows strong fundamentals with 16 well-defined tools, comprehensive parameter schemas, and clear descriptions. Tool names follow verb_noun conventions (kb_ask, kb_search, kb_store). Most parameters include type definitions and descriptions. However, there are gaps: output schemas are not explicitly documented in the visible code, some parameters lack constraint information (enums for entry_type values), and error handling guidance is not visible in tool definitions. The server demonstrates good composition (separate search, get, store, batch operations) and proper security considerations (manager mode gating for kb_maintain). STDIO transport is a hard constraint limiting protocol readiness.
Explore related knowledge via graph traversal. Use when you need to discover connections, trace decision history, or find everything related to a concept. Returns full details.
Bulk update multiple entries with new tags, project_ref, confidence_level, or entry_type
Start or query the KB Explorer web interface (graph visualization, chat, queries)
Record agent feedback on KB results — missing entries, unhelpful/inaccurate content, friction points for future tuning
Retrieve full details for specific entries by ID. Use after kb_search or kb_preflight to read the complete content of interesting results.
Ingest raw text or Markdown content into the knowledge base
Fetch and ingest content from a URL (HTML, PDF, or plain text)
Output schemas not explicitly documented. Tool definitions show input parameters but do not include return type/schema documentation visible in code. LLMs cannot reliably predict response structure for downstream composition.
Parameter constraints not fully expressed. entry_type accepts 'decision|lesson|convention|fact' but this is documented only in descriptions, not as enum constraints in schema. Allows LLM hallucination of invalid values.
kb_maintain combines 11 distinct actions (stats, deactivate, reactivate, rebuild_embeddings, etc.) into a single 'action' enum parameter. This violates single-responsibility principle and forces LLM to reason about a complex action space. Consider splitting into separate tools (kb_maintain_stats, kb_maintain_deactivate, kb_maintain_rebuild_embeddings).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
List all contributors and their entry counts
List all active projects and their entry counts
List all teams and their entry counts
Administrative maintenance operations for the knowledge base. Requires KB_MANAGER=TRUE environment variable. Actions: stats, deactivate, reactivate, rebuild_embeddings, rebuild_graph, purge_inactive, vacuum, entry_versions, list_feedback, summarize_feedback, search_stats, list_contributors, list_audit
Get a project context primer at session start. Returns a compact table-of-contents of expiring entries, recent decisions/lessons, and active conventions. Use 'since' to narrow to a time window (e.g. '7d', '2w'). Call this when you start working on a project to see what's relevant.
Quick lookup by keywords or filters. Returns compact summaries (no details). Use for duplicate checking, finding entries, or filtering by tags/project/type.
Create or update a single knowledge entry
Create or update multiple knowledge entries in a single batch operation
Get a synthesized natural-language answer with citations. Use when you need to answer a user question directly from the KB.
No visible error handling guidance in tool definitions. Errors are handled in implementation but not described to LLM. When kb_search fails (no results, invalid query, etc.), the tool does not guide LLM on recovery steps.
Tool descriptions for kb_list_* (contributors, projects, teams) are very brief (65 chars). They state WHAT but lack WHEN to use and prerequisite context. Descriptions should be 50-200 chars explaining use case.
kb_maintain requires confirmation via 'confirm' boolean for purge_inactive but parameter descriptions do not highlight this constraint prominently. Multi-step dependencies between parameters are under-documented.