Agent compatibility
Hover has no internal agent runtime to register into. It ships as an MCP
server (hover-mcp); your coding agent is the host that runs the model and
calls Hover's tools. "Which agents are supported" is just "which MCP clients can
reach the server" — and they all get an identical tool surface.
Known-good agents
| Agent | Add it with | Notes |
|---|---|---|
| Claude Code | claude mcp add hover -- hover-mcp | Recommended. Allow/deny tool controls can scope the session to Hover's MCP surface. |
| Cursor | Add hover-mcp as an MCP server in Cursor's settings | Identical tools + /mcp__hover__test_app. |
| Codex / Gemini CLI / other | Point the agent's MCP config at the hover-mcp command | Works if the agent speaks MCP. |
Install once with npm i -g @hover-dev/mcp; pass -e HOVER_LANG=<code> at
registration to have the agent converse in your language.
How it plugs in
- Hover registers as an MCP server and exposes grounded tools
(
browser_navigate,browser_snapshot,click_control,fill_control,crystallize_spec, …) plus the workflow prompts (test_app,guard,build,heal,optimize,lint,ask). See the MCP tool protocol for the wire format. - The model and its auth belong to the agent, never to Hover — Hover bundles no LLM SDK. See API keys.
- The agent drives your dev server over CDP through those tools; crystallization is deterministic (record == replay).
Older versions
Before Hover moved MCP-first, the engine kept an in-process registry of agent CLIs it would spawn and sandbox (claude / codex / gemini / qwen). That layer is retired: the agent is now whatever MCP client you run, and it owns its own model, auth, and sandboxing.