Woo Revenue Incident Graph

io.github.tytutueh13-sudoPublished by GitHub account tytutueh13-sudov0.2.2Updated Oct 25, 2026

Check WooCommerce checkout-change risk using public evidence and privacy-safe store signals.

The publisher's own server: AgentReady Woo

VerifiedStreamable HTTPWeb executableData & AnalyticsBusiness & Commerce

Overview

AI-generated overview

A remote MCP server that helps an assistant check a WooCommerce store's checkout and payment health, diagnose revenue incidents, and verify recovery after a fix

What you can do
Check current checkout and payment health for a connected WooCommerce store, including order counts by status, gateway, webhook and scheduler health, and whether a full diagnosis is warranted (free). Diagnose likely causes of a checkout or payment failure, with counter-arguments and ways to tell whether a fix held, using privacy-safe store signals such as order status over time, transitions, note reason codes and gateway/webhook health. Assess the risk of a planned or already-applied checkout change by checking a component and version against public release and issue evidence. Verify whether revenue signals recovered after a change by comparing paid, pending and failed order mix, webhook and
When to use it
Use it when a WooCommerce store shows checkout or payment problems, when you want to know whether a suspected change is worth investigating, or when you need to confirm that a fix actually restored revenue. It suits store operators and support or developer workflows around the money path.
Requirements
A remote streamable HTTP endpoint; no package, environment variables or headers are declared. It works with a connected WooCommerce store, and no authentication is declared.
Before you install
The diagnosis and verification tools read a connected store's order and payment signals, so review what store data is shared with the remote service. The risk tool relies on public release and issue evidence and may not reflect this store's specific setup. No authentication is declared, so confirm access control before connecting a live store.

Installation

In SourceWeft

  1. Open Woo Revenue Incident Graph in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.tytutueh13-sudo%2Fwoo-revenue-incident-graph/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "woo-revenue-incident-graph": {
      "type": "http",
      "url": "https://revenue-graph.utilityhouse.xyz/mcp/registry"
    }
  }
}

Tools

4

get_checkout_health_snapshot

Is this store's revenue path healthy right now?

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 commerce changes there were, which signal families this store can and cannot report, and how fresh the underlying data is. Call this FIRST — it is cheap, and `diagnosis_recommended` tells you whether the expensive call would have anything to work with. It returns no customer, order, or payment identifier because the store never sends any.

Parameterswindow_seconds

diagnose_revenue_incident

Why did this store's checkout revenue break?

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, scheduler backlog, checkout page health, recent plugin/theme/core changes — against public release and issue evidence, on one timeline. Every answer reports which signal families this store could and could not report, because a family that cannot be collected is not a family that is fine. Returns up to three ranked hypotheses, each with the observations behind it, independent public sources where they exist, counterevidence, what remains unknown, safe next steps, and a verification plan. Returns `abstained` and charges nothing when the snapshot is stale, coverage is thin, or the signals do not support any cause — an unsupported guess during an outage is worse than no answer. Free while in beta. Call get_checkout_health_snapshot first.

Parameterssymptomwindow_seconds

check_checkout_change_risk

Is this change likely to break checkout?

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 status transitions, gateway webhooks, wallet checkout), not to general plugin update safety. With no component named, checks every commerce change this store has made recently. Says `unknown` when nothing independent is on record — an absence of reports is not a safety record, and is reported as the absence it is. Free.

Parameterscomponentto_version

verify_revenue_recovery

Did the fix actually hold?

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 `unknown` — and `unknown` when too little new data has arrived to tell, which is free. A quiet ten minutes is not a recovery. Free while in beta.

Parameterswindow_secondschange_applied_atrequired

Version history

1
  1. v0.2.2LatestSep 16, 2026

Score

83% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts

    Declare a GitHub repository with a README, or serve resource_documentation in the OAuth protected-resource metadata.

  • LicenseNot applicable

    A hosted service is used under its provider's terms, so no license is expected here. This check is left out of the percentage.

Other Utilityhouse integrations