io.github.tytutueh13-sudo/woo-revenue-incident-graph · v0.2.2 · ecommerce
Woo Revenue Incident Graph is healthy: it completed an MCP handshake in 4283 ms and exposes 4 tools.
Check WooCommerce checkout-change risk using public evidence and privacy-safe store signals.
Endpoint: https://revenue-graph.utilityhouse.xyz/mcp/registry (streamable-http)
No repository listed · JSON · Add to my inventory
| Users (last 30 days) | 0 |
| Handshake | Healthy |
| Auth needed | None |
| Tool count | 4 |
| Latency | 4283 ms |
| Last checked (UTC) | 2026-10-16T17:15:46.414Z |
| Checked (UTC) | Status | Latency | Error |
|---|---|---|---|
| 2026-10-16T17:15:46.414Z | Healthy | 4283 | |
| 2026-10-15T11:15:11.343Z | Healthy | 4021 |
get_checkout_health_snapshot | Answers: is anything wrong with this connected WooCommerce store's checkout and payment path right now, and is a full diagnosis worth running? Free, always. Returns order counts by status with the change across the window, gateway/webhook/scheduler health, checkout page health, how many recent comme |
diagnose_revenue_incident | Answers: what most likely broke this store's checkout or payment path, what argues against each explanation, and how to tell whether a fix actually held. Joins the store's own privacy-safe signals — order status over time, order-status transitions, order-note reason codes, gateway and webhook health |
check_checkout_change_risk | Answers: is a change to this store's checkout or payment path known to have broken revenue elsewhere — before it is applied, or when explaining a change that was already made? Checks a component and version against public release and issue evidence scoped to the money path (payment capture, order st |
verify_revenue_recovery | Answers: after a change was made, did this store's revenue signals actually recover? Compares the window before a stated change against the window since: paid vs pending vs failed order mix, webhook failure counts, and gateway availability. Returns `resolved`, `improving`, `still_failing`, or `unkno |