Loading ToolBench
MCP server for Obsidian worldbuilding vaults - provides AI tools with consistent canonical context
Hivemind MCP demonstrates solid foundational quality with good naming conventions, comprehensive parameter documentation, and proper schema validation via Zod. All 18 tools follow verb_noun naming patterns (query_*, search_*, list_*, get_*, generate_*, store_*, validate_*, submit_*). Parameter descriptions are present and mostly detailed. However, significant gaps exist: tool descriptions vary widely in depth and actionability; output schemas are not documented (no response type definitions visible); error handling strategy is absent from tool definitions; and no evidence of idempotent operation design, pagination for bulk results, or recovery guidance. The codebase uses Zod for input validation (good), but there is no visible output schema documentation, recovery patterns, or composition guidance. Most tools are read-only (15 of 18), reducing risk, but write operations (rebuild_index, generate_image, store_asset, submit_for_review) lack confirmation/dry-run patterns. The server integrates well with Obsidian and ComfyUI, but MCP protocol surface area is underexploited (no resources, logging, annotations, progress, cancellation, error reporting).
Generate an image using ComfyUI with worldbuilding context. Context is prepended to the prompt to ensure consistency with canon.
Get canon approval status of an entity or asset
Get statistics about the vault and context savings from using MCP. Shows vault size, potential token savings, and efficiency metrics.
List assets with optional filters by entity, type, status, or workflow
List all relationship types available in the vault. Use this to discover valid filter values for graph queries.
Get a specific asset by ID with its generation settings and metadata
Output schemas not documented. Tool definitions include Zod input validation but provide no explicit documentation of response structures, field types, or return value formats. LLMs cannot reliably infer what fields to extract from responses or how to chain tools. E.g., query_graph_neighbors returns 'neighbor entities with their relationship types and directions' but no schema defining the response object structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 62 | - | v1 |
Get immediate neighbors (1-hop connections) of an entity. Returns neighbor entities with their relationship types and directions.
Find shortest path between two entities. Returns both the node sequence and edge list.
Get entities within N hops of a starting entity. Useful for exploring the neighborhood around an entity.
Query entities with dates after a specified date. Returns entities where the date field is later than the given date.
Query entities with dates before a specified date. Returns entities where the date field is earlier than the given date.
Query entities with dates matching an exact date. Returns entities where the date field exactly matches the given date.
Query entities with dates in a specified range. Returns entities where the date field falls between startDate and endDate (inclusive).
Force a complete rebuild of the vault index. Use this when files have been added or modified outside of normal detection.
Search across all worldbuilding content using hybrid search (keyword + semantic + graph)
Store an asset in the vault with metadata and relationship tracking
Submit an entity or asset for canon review
Check an entity for consistency issues with canon and relationships
No error recovery guidance. Tool descriptions do not explain what the LLM should do if a call fails. E.g., rebuild_index says 'Force a complete rebuild' but does not document failure modes or recovery steps. query_graph_path says 'Returns both the node sequence and edge list' but does not explain what happens if no path exists. Missing recovery guidance forces LLMs to guess or fail silently.
Destructive operations lack confirmation/dry-run pattern. rebuild_index, generate_image, store_asset, and submit_for_review modify state without explicit confirmation or dry-run capability. Agents can trigger irreversible actions (image generation costs, index rebuilds) without a safety gate. No mention of rollback or undo capability.
Pagination not implemented for bulk-result tools. search_vault, list_assets, query_timeline_* all accept a 'limit' parameter but no cursor, offset, or next_page mechanism is visible. Returning large result sets (up to 1000 items in timeline tools) risks context window exhaustion without pagination support documented.
Tool descriptions are sometimes generic or lack actionable context. E.g., rebuild_index says 'Use this when files have been added or modified outside of normal detection' but does not explain what 'normal detection' is or how to know when to call it. get_vault_stats describes output ('Shows vault size, potential token savings') but not WHEN to call it or what to do with the result. Description length varies: query_graph_neighbors (160 chars, good), but list_relationship_types (~90 chars, brief).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in definitions. The MCP spec supports tool annotations to signal semantic properties. All tools are marked Risk: READ_ONLY or Risk: WRITE in metadata but not integrated into the MCP tool definition via annotations. This prevents clients from applying appropriate UI/confirmation logic automatically.
entityId parameter accepts multiple formats (ID, name, Type:name) but format validation is unclear. Parameter description says 'Entity identifier (ID, name, or Type:name format like "Character:john")' but does not specify validation rules, error messages, or priority if multiple formats match. Ambiguity invites LLM confusion and lookup failures.
Missing tool composition guidance. Tools operate on entities, assets, and relationships, but there is no documented flow or sequencing. E.g., after calling search_vault to find a Character, how does an LLM generate an image for it? The response from search_vault must return an entityId compatible with generate_image, but this is not documented.