hyperhive/hive-agent-mcp
Repository files (latest commit first)
Filename Latest commit message Latest commit date
atlas bed7ae6d5a docs: a config change is a PR from a clone, not an edit in place
Seven places described an authoring flow that does not exist: the
manager editing and committing a child's config in the bind-mounted
config dir. mara, on the snapshot issue: "the pr workflow is the main
one, anything else is legacy … the config dir in agent container is
read only copy to see own config … changes need to go through local
clone and via forge".

Two of the seven are the request_init_config MCP tool description and
its args struct, which are rendered into the system prompt of every
agent holding the approvals tool group. A wrong tool description is not
a stale comment; it is an instruction the whole hive reads as fact,
which is why the claim kept being repeated back.

The init tool creates the repo and seeds it. Nothing else. Tailoring
the seeded template is not a separate mechanism - it is the ordinary
config-change flow, a PR reviewed like any other.

Prose only; the code already implements the PR flow (an approval's
commit_ref is a PR number). Where a doc justified the parent's
read-write mount on the child's config dir with the authoring model,
the justification is removed rather than replaced: that mount is a
defect tracked on its own issue, and it should not read as intentional
while it waits.
2026-08-04 22:40:22 +02:00
..
src docs: a config change is a PR from a clone, not an edit in place 2026-08-04 22:40:22 +02:00
Cargo.toml refactor(sock): one socket client, retry as a policy value 2026-07-26 22:44:48 +02:00
README.md remove hive-agent-wake — no shipped consumer 2026-07-25 20:05:32 +02:00

hive-agent-mcp

The built-in hyperhive MCP server every agent gets by default. Runs a long-lived streamable-http listener (the hive-mcp-http systemd unit) that claude reconnects to each turn via --mcp-config — this avoids the per-turn stdio re-registration race that a spawned-per-turn server would hit. HTTP is the sole transport; there is no stdio mode here.

When to use it

This is where the core hyperhive tool surface lives: send, recv, ask/answer, remind, get_loose_ends, set_status, get_agent_meta, lifecycle (kill/start/restart/update on direct children), scheduling, and the approval-request tools. Reach for this crate when you're adding or changing a built-in tool rather than an extraMcpServers add-on — those are separate stdio bridges (see hive-bash-mcp, hive-matrix-mcp) that dial the harness socket or their own daemon instead of living here.

Shape

  • mcp/ — the tool surface itself: one handler per tool, dispatch through client.rs back into the hyperhive broker (/run/hive/mcp.sock) or, for loose-ends v2 (todos/reminders), the in-agent socket the hive-agent harness serves.
  • client.rs — socket client to the hyperhive broker.
  • send_allow.rs — enforces the per-agent hyperhive.allowedRecipients allow-list on send/ask.
  • paths.rs — socket + state path resolution shared with the harness's own paths.rs conventions.

Sibling of hive-agent (the serve loop that renders the --mcp-config blob pointing here). Standalone bin crate so the always-on MCP server doesn't need to link the whole turn-loop lib.