Loading ToolBench
Unified MCP server for AI-assisted development — on-demand Obsidian vault access + worker delegation
Hive is a mixed-quality MCP server with solid foundational work but significant gaps in definition completeness and consistency. The server defines 11 tools across vault operations, worker delegation, and load testing, but only 5-6 are production-grade. Naming is generally clear and verb-forward (vault_query, vault_write, list_projects), but descriptions vary wildly in quality, some are detailed (vault_write, vault_ask) while others are trivial or missing (ping: 'Trivial fast call...', slow: unmarked). Critical issue: 3 tools (ping, record, slow) appear to be internal load-test/spike utilities mixed with production tools; these should be separated or documented as non-public. Input schemas are present for all tools but inconsistently documented, most lack detailed parameter descriptions (e.g., vault_patch 'operation' param has no enum or format guidance). Output schemas are not visible in the source provided, a significant gap per the rubric. Error handling is not evident in tool definitions. Per the rubric baseline (average 4 params/tool, 90% of A+ tools start with action verb, 100% of A+ tools have param descriptions), Hive achieves ~70% on naming and ~50% on description completeness, averaging to a C-range score.
List all projects available in the Obsidian vault
Trivial fast call with no shared state (for benchmarking)
Shared-state write for load testing: INSERT a row and return running count
Slow operation modelling git path with blocking work offloaded to worker thread
Query the vault using semantic retrieval with optional model synthesis
Report the health status of the vault and server
Patch or update specific content in the Obsidian vault
Three tools (ping, record, slow) are internal load-testing utilities mixed with production vault/worker tools. Load tests belong in separate test harnesses, not the public MCP interface. These degrade discoverability and confuse agents about what Hive actually does.
vault_patch 'operation' parameter has no enum, format constraint, or example. The description says 'The patch operation to perform' with no guidance on valid values. This violates the rubric's constrained-input pattern and invites hallucinated operations.
Output schemas are not documented in the source provided. The rubric requires documented return types for all tools. Without visible return schemas, agents cannot plan downstream calls or extract required fields. This is a critical omission.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Query and retrieve content from the Obsidian vault
Write or append content to the Obsidian vault
Delegate a task to the worker pool for distributed processing
Idempotent write tool for testing (INSERT OR IGNORE on idempotency key)
Descriptions for vault_health, vault_patch, and ping are vague or under 30 characters. 'Report the health status of the vault and server' (46 chars) is generic and does not explain when to call it or what fields to expect. ping at 'Trivial fast call with no shared state (for benchmarking)' (57 chars) should not be in production.
No error-handling guidance in tool definitions. Tools that mutate state (vault_write, vault_patch, worker_call, write, record) lack descriptions of failure modes, retryability, or recovery steps. Per the rubric, error responses should tell the LLM what to do next.
vault_ask and vault_query both query the vault with semantic vs. direct access, but the distinction is not clearly explained. Parameter descriptions for both lack guidance on when to use each. The rubric requires that when multiple tools operate on the same resource, distinctions must be obvious.
worker_call parameters 'model' and 'prompt' lack format constraints or guidance. What models are available? What prompt length is acceptable? The rubric requires actionable parameter descriptions with ranges and constraints.