Skip to content

MCP

stove-cli exposes a local Model Context Protocol endpoint. AI agents (Claude Code, Cursor, ...) query failed runs through compact, structured tools instead of grepping raw logs.

In 30 seconds Start stove. Point your agent at the MCP endpoint. Agents call stove_failures, stove_failure_detail, stove_trace, stove_snapshot against the same SQLite the Dashboard reads. Token-aware, read-only, loopback-only.

Discovery

Banner on stove shows the endpoint:

stove

Stove CLI v0.24.0 running
UI:   http://localhost:4040
REST: http://localhost:4040/api/v1
MCP:  http://localhost:4040/mcp
gRPC: localhost:4041

Or hit GET /api/v1/meta for metadata:

{
  "stove_cli_version": "0.24.0",
  "mcp": {
    "enabled": true,
    "transport": "streamable-http",
    "endpoint": "http://localhost:4040/mcp",
    "scope": "read-only-test-observability"
  }
}

Connect an agent

// ~/.config/claude-code/config.json
{
  "mcpServers": {
    "stove": {
      "type": "http",
      "url": "http://localhost:4040/mcp"
    }
  }
}

Use the standard Streamable HTTP MCP transport. The URL is http://localhost:4040/mcp; the config key may be named type or transport depending on the client.

Tools

Tool Returns
stove_apps apps recorded in the dashboard database
stove_runs runs, filterable by app and status
stove_failures top-N recent failures across all apps/runs, summarized
stove_failure_detail one failure: assertion, system entries, snapshot summary
stove_timeline chronological events for one test
stove_trace OTel span tree for one test (when tracing is on)
stove_snapshot system state at failure (Kafka topics, WireMock unmatched, ...)
stove_raw_evidence full untruncated entry / payload (rarely needed)

Data model

database
└── apps           (one per appName)
    └── runs       (one per test suite execution)
        └── tests  (one per test case)
            ├── entries     HTTP/DB/Kafka/...
            ├── spans       OTel tree
            └── snapshots   system state at failure

Most tools take app, run_id, or test_id to drill down. Start broad with stove_failures, then narrow.

Token budgeting

Each tool ships in three modes:

  • tiny. Top-line summary only. Use for surveys.
  • compact (default). Most decision-grade detail; truncated payloads.
  • full. Untruncated. Costs tokens; only when needed.

Sensitive keys are auto-redacted (passwords, JWTs, common secret patterns).

1. stove_failures(limit=5, app="my-service")
   → list of recent failures, with test_id and run_id

2. stove_failure_detail(test_id, run_id, mode="compact")
   → assertion, entries leading up to it, snapshot summary

3. (optional) stove_trace(test_id, run_id)
   → call chain inside the app

4. (optional) stove_snapshot(test_id, run_id, system="kafka")
   → drill into one system if root cause unclear

Security

  • Loopback-only access. MCP rejects non-loopback clients and non-local Host / Origin headers.
  • Read-only. No mutations. No exec. No file writes.
  • No outbound calls. Agent reads what stove already stored.

Pairs well with

Troubleshooting

Symptom Check
Agent can't connect stove running? Port matches MCP URL?
stove_failures empty Tests producing events? dashboard { } registered in Stove().with?
stove_trace returns nothing Tracing enabled? See Tracing setup
Payloads truncated Use mode="full" for full detail (token cost)