hive
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Hive provides on-demand access to an Obsidian vault.
When to use each tool
Start of session: Call
session_briefing(project)to load tasks, lessons, git activity, and health in one call.Browsing vault structure: Use
vault_listto discover projects and navigate directories. Callvault_queryto read their content.Reading vault files: Use
vault_queryinstead of direct filesystem access. Supports section shortcuts (context, tasks, roadmap, lessons) and arbitrary paths. Usescope:projectsyntax when project names are ambiguous across scopes.Finding information: Use
vault_searchfor keyword/regex lookup with filters. Addranked=Truefor relevance-ranked results, orsince_days=Nfor recent changes.Recording lessons: Call
capture_lessonwhen a bug fix, architectural decision, or useful insight emerges during work. Default is inline mode — passtitle,context,problem, andsolution. Passtext=...for batch mode when you want a worker model to extract multiple lessons from a free-form text block.Writing to vault: Use
vault_writeto create, append, or replace files. Usevault_patchfor surgical find-and-replace edits. Passcommit=Falseto defer the git commit; flush a batch of deferred writes withvault_commit(message=...). When obsidian-git is configured on the vault,commit=Falseis safe —vault_healthsurfaces the detected interval.Deleting a file: Use
vault_delete(project, path)to remove a single file (git-recoverable). Destructive — only on explicit user request.Offloading work: Use
delegate_taskfor summarization, boilerplate generation, or analysis. Usedelegate_task(project=...)to summarize vault files. Best for boilerplate and format conversion, not for architecture or security decisions.Checking workers: Call
worker_statusbeforedelegate_taskto verify the worker is configured and reachable.Checking vault health: Call
vault_healthafter modifying vault files or periodically to detect drift. Addinclude_usage=Truefor usage statistics.
Use project='_meta' to access cross-project content (patterns, templates).
Read-only tools are safe to call freely. Write tools auto-commit to git.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vault_listB | List vault projects, or files within a project. When called without arguments, lists all available projects. When called with a project, lists files in that project directory. |
| vault_queryB | Read content from a vault project — use instead of direct filesystem access. |
| vault_searchB | Search the vault: full-text, ranked, or recent changes. Default mode: flat full-text search across all vault files. Ranked mode (ranked=True): results scored by relevance. Recent mode (since_days>0): files changed in the last N days. rank_by mode (rank_by != 'bm25'): lessons-only, ranked by usage. |
| session_briefingA | Call at the start of every new session to load project context. Without a project, returns the available project list with a usage hint — discoverability parity with vault_health() and worker_status(). With a project, assembles active tasks, recent lessons, git activity, and project health into a single response (replaces 3-4 manual calls). |
| vault_writeA | Write to the vault: append, replace a section, or create a new file. Modes:
|
| vault_patchA | Surgical find-and-replace in a vault file with auto git commit. Supports single or multi-replacement. For a single replacement, provide
Each Uses 3-pass cascading match: exact → body-only → whitespace-normalized. |
| vault_commitA | Commit every unstaged and untracked change in the vault, in one commit. Companion to It also sweeps edits made outside hive. A path that already has a
staged change is left out and named in the result: it belongs to
whoever staged it, often another session sharing the vault. Commit
one deliberately with Returns the new commit SHA on success, a clean-tree notice when there is nothing to commit, or a human-readable error. |
| vault_deleteA | Delete a single file from the vault (destructive; recoverable via git). Removes one file and, by default, commits the deletion so it stays
recoverable from git history ( |
| vault_healthA | Return vault health metrics, validation, and optional usage analytics. Always emits the Without parameters, returns a health summary for all projects. When checks are specified, runs drift detection (frontmatter, stale, links). When include_usage is True, appends tool usage analytics. When include_runtime is True, appends runtime metadata (uptime, tools, budget). |
| capture_lessonA | Capture lessons: inline / batch write, or lookup by keyword. Inline mode (default): provide title, context, problem, solution.
Batch mode: provide text to extract lessons automatically via worker.
Lookup mode: provide |
| delegate_taskA | Offload work to a cheaper model or summarize vault files. When project is provided, reads a vault file. Small files (≤50 lines) are returned directly. Large files are auto-delegated to a worker for summarization — falls back to raw content if workers are unavailable. |
| worker_statusA | Show worker health: configuration, reachability, model, and usage. HIVE-384 reshaped this tool, and the reshape is the point rather than a side effect. The old output led with a dollar budget and reported two providers by configuration: it said "Ollama: offline / OpenRouter: no API key" for an unknown length of time while every caller treated the worker as a working capability. A status surface that cannot distinguish "configured" from "answers" is how a dead backend stays invisible. So reachability is probed, not inferred, and reported separately from configuration. The dollar figures are gone: on a flat subscription they would read zero forever, and a gauge that always says the same thing looks like a working gauge. |
| vault_askA | Ask a natural-language question; get a source-cited synthesized answer (semantic retrieval / RAG) or relevant vault sections when no synthesis model is configured. OPTIONAL — disabled by default. Requires the |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| retrospective | Quick end-of-session review that extracts lessons and appends them to the vault. |
| delegate | Structured protocol for delegating tasks to cheaper models via hive-worker. |
| vault_sync | Post-sprint vault synchronization — reconcile docs with shipped code. |
| benchmark | Estimate token savings from hive MCP tools in the current session. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| projects_resource | List all vault projects with file counts and available shortcuts. |
| health_resource | Vault health metrics for all projects. |
TDQS
Scored across 13 tools
Most tools map to a single verb on a single resource, and the descriptions actively steer callers apart (e.g. vault_ask says to use vault_search for keyword lookups, vault_commit explains its relationship to commit=False writes). A few boundaries blur: delegate_task doubles as a vault-file reader alongside vault_query, capture_lesson's lookup mode overlaps vault_search, and session_briefing aggregates data that vault_health also reports.
Every name is snake_case verb_noun, which is highly predictable. The only deviation is scope of prefixing: vault_* covers storage operations while session_briefing, capture_lesson, delegate_task, and worker_status are unprefixed — a seemingly deliberate but still visible split.
13 tools sits squarely in the well-scoped range, and each earns its place: eight cover vault CRUD/search/git, and the remainder cover session context, lessons, delegation, worker health, and optional RAG. No filler tools and no obviously missing siblings.
The vault lifecycle is well covered — list, read, write/create, patch, delete, search, and git commit are all present, with recoverability and idempotency handled. Minor gaps remain: no move/rename operation for files, no explicit project creation or deletion, and no directory-level operations (which delete explicitly rejects).