get_hoverfly_statusLABSCO 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.
Setup effort
Run a container — pull the image and point your client at it
USE CASES
01
Carrying on when a third-party API is down
Start Hoverfly in simulate mode and stand up a mock for the endpoint you need.
02
Reproducing an error response you cannot trigger for real
Add the failing response as a mock and check it is registered.
03
Working out why a mock is not being hit
Read the debug logs, then ask which matcher the request actually needs.
04
Keeping a mock set for the next session
Download the simulation, and let the next start auto-load it.
05
Resetting to a clean state between tests
Clear the mocks and confirm Hoverfly is still up.
12 tools
Listed in project docs. Your client may show a different list.
start_hoverfly_web_serverstop_hoverfly_serverfetch_hoverfly_versionlist_hoverfly_mocksadd_hoverfly_mockclear_hoverfly_mocksshow_hoverfly_endpoints_infoget_hoverfly_documentationsuggest_hoverfly_matchersget_hoverfly_debug_logsdownload_hoverfly_simulationBEFORE YOU INSTALL
What to know first
Tools you get
12 tools named in the project's documentation.
Requires
docker on PATH
Where it runs
The documented client runs the server on your machine.
INSTALLATION
Connect your client
Pull the image and point your client at it.
Server setup
Only needed to contribute or build from source — for most users the Docker image in the client configuration is sufficient, and Docker pulls it automatically
TERMINAL
git clone https://github.com/kapishmalik/hoverfly-mcp-server
cd hoverfly-mcp-server
mvn clean package
java -jar target/hoverfly-mcp-server-<YOUR_VERSION>.jarMCP Clients
Any MCP client
ANY MCP CLIENT · JSON
{
"mcpServers": {
"hoverfly-mcp": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-p",
"8500:8500",
"-p",
"8888:8888",
"-v",
"<YOUR_PATH_TO_DATA>:/opt/hoverfly-mcp/simulation-data",
"docker.io/kapish88/hoverfly-mcp-server"
]
}
}
}
