| Filename | Latest commit message | Latest commit date |
|---|---|---|
b88a5b2430
Both agent-facing tools go away end to end, with no replacement. This is an intentional capability removal: agents can no longer enumerate their own subtree, and can no longer queue a meta-flake input bump. The system prompt and docs/tools/lifecycle.md land in this same commit on purpose. A tool named in the prompt but absent from the server makes agents confidently call something that doesn't exist, and the failure then surfaces far from its cause. Removed: - MCP registrations and bodies (hive-agent-mcp), plus the now-unused UpdateMetaInputsArgs. - Wire variants Request::ListDescendants, Request::RequestUpdateMetaInputs and Response::Containers, plus ContainerInfo, whose only consumer was that response. - hive-c0re's handle_list_descendants (its whole module) and handle_request_update_meta_inputs, the two dispatch arms, and the require_group(agent, "approvals", ...) gate on the meta-inputs verb. - The stream_enrich emoji entry and argument formatter. - docs/tools/lifecycle.md (both tools it documented are gone), its two referrers, the tool-group tables and the agent-hierarchy prose. Tool groups are kept, deliberately. ToolGroup::Lifecycle listed exactly one tool and now lists none — it is vestigial, but the variant stays so existing meta/capabilities.json grants still parse; retiring it is a separate decision. ToolGroup::Approvals also listed exactly one tool, but the group is NOT dead: check_can_cancel_approval still gates cancel_loose_end's approval-cancel arm on it server-side. ApprovalKind::UpdateMetaInputs stays too. Nothing in production code produces it any more, but pre-existing approval rows may still carry it, and the operator's own path to a meta update is unaffected — the dashboard's POST /api/meta-update inserts the meta_update job directly, bypassing approvals entirely. The two format_ack tests in hive-agent-mcp that named request_update_meta_inputs were only using it as a label string while exercising the generic OkWarn/Ok renderer, so they are retargeted to a surviving tool rather than deleted. Note hive-c0re's priv_client::list_containers is a different thing (the host-side privileged container listing behind hive-priv) and is untouched. Closes #4591 |
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
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,
remind, get_loose_ends, set_status,
get_agent_meta, lifecycle (kill/start/restart/update on the
agent's own subtree), 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 throughclient.rsback into the hyperhive broker (/run/hive/mcp.sock) or, for loose-ends v2 (todos/reminders), the in-agent socket thehive-agentharness serves.client.rs— socket client to the hyperhive broker.send_allow.rs— enforces the per-agenthyperhive.allowedRecipientsallow-list onsend.paths.rs— socket + state path resolution shared with the harness's ownpaths.rsconventions.
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.