Skip to content

Woo Revenue Incident Graph

by tytutueh13-sudo · remote · no sign-in to list tools · v0.2.2 · published by GitHub user tytutueh13-sudo

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

Changes · 3

4 tools: 3 change things and 1 only read.

Scanned Oct 21, 2026

1 check matched something in the tool definitions. No finding is not a safety guarantee. How the checks work.

claude mcp add --transport http woo-revenue-incident-graph https://revenue-graph.utilityhouse.xyz/mcp/registry

Findings

Matches of fixed checks, with the text they matched.

1 warn
  • The server marks "check_checkout_change_risk" read-only (readOnlyHint: true), and its own name, description or input give the class "write".

    Matched text

    annotations: {"readOnlyHint":true,"destructiveHint":false,"idempotentHint":true,"openWorldHint":true}; The name "check_checkout_change_risk" says "checkout": a word for a change.

    What this check looks for

Tools

Open a tool for its reasons and full description. Descriptions are the publisher's own words, shown as they are.

4 tools

Changes things 3Claude Code: ask
  • check_checkout_change_riskAnswers: 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?1 finding

    Why it is in this group

    • The name "check_checkout_change_risk" says "checkout": a word for a change.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.

    Findings

    • Warn

      The server marks "check_checkout_change_risk" read-only (readOnlyHint: true), and its own name, description or input give the class "write".

      Matched text

      annotations: {"readOnlyHint":true,"destructiveHint":false,"idempotentHint":true,"openWorldHint":true}; The name "check_checkout_change_risk" says "checkout": a word for a change.

      What this check looks for
    Description, as the server wrote it
    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.

    Annotations the server declares

    • readOnlyHint: true
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: true
  • diagnose_revenue_incidentAnswers: 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.No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • readOnlyHint: true
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: true
  • verify_revenue_recoveryAnswers: after a change was made, did this store's revenue signals actually recover?No findings

    Why it is in this group

    • Nothing in its name or description says what it does, so it is counted as a write.
    • The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • readOnlyHint: true
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: true
Only reads 1Claude Code: allow
  • get_checkout_health_snapshotAnswers: is anything wrong with this connected WooCommerce store's checkout and payment path right now, and is a full diagnosis worth running?No findings

    Why it is in this group

    • The name "get_checkout_health_snapshot" says "get": a word for reading.
    Description, as the server wrote it
    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.

    Annotations the server declares

    • readOnlyHint: true
    • destructiveHint: false
    • idempotentHint: true
    • openWorldHint: true

This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.

Install

Pinned to version 0.2.2. Values in angle brackets are yours to fill in.

claude mcp add --transport http woo-revenue-incident-graph https://revenue-graph.utilityhouse.xyz/mcp/registry

Run in a terminal.

Claude Code permissions

Allow the reads, ask before a change, deny the deletes. Paste into .claude/settings.json.

.claude/settings.json
{
  "permissions": {
    "allow": [
      "mcp__woo-revenue-incident-graph__get_checkout_health_snapshot"
    ],
    "ask": [
      "mcp__woo-revenue-incident-graph__diagnose_revenue_incident",
      "mcp__woo-revenue-incident-graph__check_checkout_change_risk",
      "mcp__woo-revenue-incident-graph__verify_revenue_recovery"
    ],
    "deny": []
  }
}

Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. It assumes the server is installed as woo-revenue-incident-graph. Review it before you use it.