Summary
Mocks you can add mid-conversation, and logs for when they miss.
Matching is where API mocking usually goes wrong, and here the suggestion and the evidence sit in the same session: ask for a matcher, then read the debug log that says whether the request hit it. Simulations persist to the mounted volume, so a working mock set survives the container.
What it is
A Spring Boot MCP server that drives Hoverfly: start it in simulate mode, add and clear mocks while it runs, save simulations for reuse, and read its logs when a mock does not fire.
What you get
- Hoverfly started as a web server in simulate mode, auto-loading the most recent saved simulation unless you turn that off, and stopped again with its mocks cleared (start_hoverfly_web_server, stop_hoverfly_server)
- Mocks added, listed and cleared while it is running (add_hoverfly_mock, list_hoverfly_mocks, clear_hoverfly_mocks)
- A simulation saved out for reuse later (download_hoverfly_simulation)
- Suggestions for which matcher a request needs (suggest_hoverfly_matchers)
- Status, version and endpoint information, plus debug logs (get_hoverfly_status, fetch_hoverfly_version, show_hoverfly_endpoints_info, get_hoverfly_debug_logs)
- Hoverfly's own documentation available in the session (get_hoverfly_documentation)
Requirements
Docker, with the proxy port and the admin API port published, and a volume mounted at /opt/hoverfly-mcp/simulation-data if simulations should survive a restart. Building from source instead needs Java 17 and a recent Maven.