hive mcp: own MCP servers and their credentials

[unforcedagi]

Why hive has to own this

Buzz cannot configure an HTTP MCP server. I read the source rather than assuming:

• buzz-acp's McpServer is {name, command, args, env} — stdio only, no url, no headers
• the backend-provider deploy payload (deploy_payload_json) carries no MCP field at all

That's a boundary in Buzz's surface, not a gap to route around. If agents are to reach an HTTP MCP server, hive owns the configuration and the credential.

Until now the only route was two flat fields on the desktop provider config, which could express exactly one server and hardcoded its name to "mcp". hive-spec has always had mcp: Vec<Mcp> — the format was never the limit.

What this adds

$ hive mcp add parachute --url https://vault.example/vault/unforced/mcp --agent uni
$ hive mcp login parachute --agent uni
$ hive mcp list --agent uni
$ hive mcp refresh parachute --agent uni

Specs are edited, not regenerated. The README calls generated specs "safe to edit and to commit" — but any generator that rewrites the document deletes comments, ordering, and blocks it doesn't know about. toml_edit keeps them, so hive mcp add and a human editor can share one file. There's a test for exactly that.

The login flow

Walks what the MCP spec defines: unauthenticated probe → WWW-Authenticate: resource_metadata → protected-resource metadata (RFC 9728) → authorization-server metadata (RFC 8414) → dynamic client registration (RFC 7591) → PKCE S256 → authorization code → token, resource-bound per RFC 8707.

Why interactive rather than secret put with a minted token. A minted token carries the minter's authority and expires without warning. Verified against a live Parachute vault, whose access tokens last 900 seconds — an agent on a static token fails its first tool call fifteen minutes after setup, and the error reads as a broken MCP server.

The refresh token is stored alongside, and it only helps because the broker serves credentials per connection rather than injecting them at container start. A design that baked credentials into the environment couldn't renew without recreating the container. That's an existing architectural choice paying off.

refresh reads through the broker's grant-checked path under a named hive-cli grant rather than reaching around it, so a manual renewal shows in the audit log exactly like an agent's own fetch.

No new runtime dependencies

HTTP goes through curl, for the same reasons hive_core::docker drives Docker through its CLI — no large dependency tracking a moving API, and every request is a command you can re-run by hand. base64url is forty lines rather than a crate. Only toml_edit and sha2 were added, both already in the workspace.

Verified against a live vault

• discovery, dynamic registration, PKCE, code exchange — all real, not mocked
• the stored token opens an actual MCP session (serverInfo: parachute-vault/unforced)
• refresh produced a genuinely different token
• 120 tests pass (108 existing + 12 new)

Known limitation

The loopback redirect needs a browser that can reach the host's 127.0.0.1, so a headless box needs someone at its screen. The RFC 8628 device grant would fix it — you'd get a code and type it anywhere — but Parachute advertises only authorization_code and refresh_token today. Noted rather than worked around.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Gw5rgVt1CQ8EYrLpZtQjdM