Loading ToolBench
Curator MCP surface v1: the one agent entrypoint for the Knowledge Plane — MCP server providing search, retrieval, note management, and proposal workflows over a local vault with hybrid (vector + FTS) indexing
Curator MCP has well-structured tool definitions with clear naming (verb_noun pattern: kp_search, kp_get_note, kp_related, kp_recent, kp_propose, kp_digest_latest) and comprehensive descriptions (avg 150 chars, within 10-1024 baseline). All 6 tools have input schemas with typed parameters and enums where appropriate (mode in kp_search, kind in kp_recent). However, output schemas are not documented in the visible code, LLMs cannot predict response structure. Parameter descriptions are present but lack detail on constraints (e.g., kp_search 'k' has no min/max bounds; kp_propose 'files' object structure is vague). Error handling is minimal, no recovery guidance or actionable error messages visible. The kp_propose tool (WRITE operation) lacks confirmation/dry-run pattern, risking accidental vault mutations. Tool composition is sound (single responsibility, clear chaining via IDs), but output documentation gaps prevent confident downstream planning.
The latest librarian digest note, or null when none exists yet.
Fetch one note by id (any identity namespace: curio: | zotero: | kp: | path:). Returns full content, frontmatter, and index metadata.
Propose vault changes (the ONLY write verb). Creates a proposals/v1 changeset — title, rationale, and the full new content of each file — for human review; nothing is applied directly.
Recently ingested or changed notes; days defaults to 7, kind optionally filters by identity namespace (curio | zotero | kp | path).
Embedding-nearest notes to an existing note (by id, any namespace); k defaults to 10. The note itself is excluded.
Search the knowledge plane. Returns ranked notes (id, title, path, snippet, score) for a free-text query; mode is hybrid (default), vector, or fts; k defaults to 10.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). kp_search returns 'ranked notes (id, title, path, snippet, score)' but no formal schema visible; kp_get_note returns 'full content, frontmatter, index metadata' without field definitions.
Parameter constraints missing. kp_search 'k' (number of results) has no min/max bounds, LLM could pass 0, -1, or 10000. kp_recent 'days' unbounded. No validation guidance in descriptions.
kp_propose (WRITE tool) lacks confirmation/dry-run pattern. No mention of review workflow, approval gates, or undo capability. Agents could propose destructive vault changes without safeguards.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2025-06-18+ | v2 |
Error handling not visible. No recovery guidance, error classification, or actionable messages. If kp_search fails or kp_get_note returns 404, LLM has no guidance on next steps.
kp_propose 'files' parameter is an object with vague structure ('map of vault-relative paths to full new content'). No schema for the object keys/values, no guidance on file format, encoding, or size limits.