# Woo Revenue Incident Graph (remote · revenue-graph.utilityhouse.xyz)

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

- Trust score: 72/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-20

## Components

- remote · `revenue-graph.utilityhouse.xyz`: 72/100 (this document), [markdown](https://verifymcp.io/servers/tytutueh13-sudo-woo-revenue-incident-graph/mcp-registry.md), [page](https://verifymcp.io/servers/tytutueh13-sudo-woo-revenue-incident-graph/mcp-registry)

## Channel facts

- Endpoint: `https://revenue-graph.utilityhouse.xyz/mcp/registry`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.2.2`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-20.

- **Endpoint Security**: 66/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS enforcement could not be verified: the plaintext port answered with HTTP 405, which proves neither a plaintext path nor enforcement.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 68/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 907 tokens (~226/item across 4 items; 4 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 50/100
  - Stability observed for 15 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 96/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 86% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 4 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 5 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 60/100
  - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28.

## Install

### How do I install the Woo Revenue Incident Graph MCP server?

Woo Revenue Incident Graph is a hosted endpoint at https://revenue-graph.utilityhouse.xyz/mcp/registry, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http tytutueh13-sudo-woo-revenue-incident-graph 'https://revenue-graph.utilityhouse.xyz/mcp/registry'
```

### Cursor

```json
{
  "mcpServers": {
    "tytutueh13-sudo-woo-revenue-incident-graph": {
      "url": "https://revenue-graph.utilityhouse.xyz/mcp/registry"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "tytutueh13-sudo-woo-revenue-incident-graph": {
      "type": "http",
      "url": "https://revenue-graph.utilityhouse.xyz/mcp/registry"
    }
  }
}
```

### Codex

```toml
[mcp_servers.tytutueh13-sudo-woo-revenue-incident-graph]
url = "https://revenue-graph.utilityhouse.xyz/mcp/registry"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "tytutueh13-sudo-woo-revenue-incident-graph": {
      "type": "remote",
      "url": "https://revenue-graph.utilityhouse.xyz/mcp/registry",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add tytutueh13-sudo-woo-revenue-incident-graph --url 'https://revenue-graph.utilityhouse.xyz/mcp/registry' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  tytutueh13-sudo-woo-revenue-incident-graph:
    url: "https://revenue-graph.utilityhouse.xyz/mcp/registry"
```

### Netclaw

```json
{
  "McpServers": {
    "tytutueh13-sudo-woo-revenue-incident-graph": {
      "Transport": "http",
      "Url": "https://revenue-graph.utilityhouse.xyz/mcp/registry"
    }
  }
}
```

### Vellum

```bash
assistant mcp add tytutueh13-sudo-woo-revenue-incident-graph -t streamable-http -u 'https://revenue-graph.utilityhouse.xyz/mcp/registry'
```

### Other

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

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-20 (score 72, +1)

No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-18 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 40 to 43. That category is still filling its 30-day observation window: 12 days of observed history at the previous scan, 13 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-16 (score 70, +1)

No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-13 (score 69, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-11 (score 68, +2)

- [security improvement] DNSSEC: fail → pass

### 2026-09-10 (score 66, +1)

No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-07 (score 65, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-06 (score 64, 0)

- [functional improvement] Stability: unverified → 0.03

## MCP tools (4)

### `get_checkout_health_snapshot` (~162 tokens)

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.

Input parameters:

- `window_seconds` (integer): Window in seconds. Default 86400 (24h), maximum 604800 (7d).

Output parameters:

- `collected_at` (integer|null)
- `connected` (boolean)
- `coverage` (object)
- `data_freshness` (string)
- `diagnosis_recommended` (boolean)
- `error_fingerprints` (integer)
- `gateway_summary` (object)
- `order_counts` (object)
- `paid_order_change_pct` (integer|null): Change in paid orders across the window; null when there is too little data to compare.
- `reason` (string)
- `recent_changes` (integer)
- `scheduler_overdue` (integer)
- `webhook_summary` (object)

### `diagnose_revenue_incident` (~259 tokens)

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.

Input parameters:

- `symptom` (string): What the merchant reports. Use "unknown" rather than guessing.
- `window_seconds` (integer): Window in seconds. Default 86400 (24h), maximum 604800 (7d).

Output parameters:

- `abstained` (object|null)
- `billable` (boolean)
- `coverage` (object)
- `data_freshness` (string)
- `failure_pattern` (string)
- `failure_pattern_reasoning` (array)
- `hypotheses` (array)
- `price_micros` (integer)
- `symptom` (string)
- `timeline` (array)
- `window` (object)

### `check_checkout_change_risk` (~168 tokens)

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.

Input parameters:

- `component` (string): e.g. "plugin:woocommerce-gateway-stripe". Omit to check this store's own recent changes.
- `to_version` (string)

Output parameters:

- `billable` (boolean)
- `checked` (array)
- `price_micros` (integer)
- `source` (string)

### `verify_revenue_recovery` (~152 tokens)

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.

Input parameters:

- `change_applied_at` (integer, required): Epoch ms when the fix was applied.
- `window_seconds` (integer): Window in seconds. Default 86400 (24h), maximum 604800 (7d).

Output parameters:

- `after` (object|null)
- `before` (object|null)
- `billable` (boolean)
- `new_regressions` (array)
- `price_micros` (integer)
- `reason` (string)
- `status` (string)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/tytutueh13-sudo-woo-revenue-incident-graph/mcp-registry#diagnostics

## Score history

- 2026-09-20: 72
- 2026-09-19: 71
- 2026-09-18: 71
- 2026-09-17: 70
- 2026-09-16: 70
- 2026-09-15: 69
- 2026-09-14: 69
- 2026-09-13: 69
- 2026-09-12: 68
- 2026-09-11: 68
- 2026-09-10: 66
- 2026-09-09: 65
- 2026-09-08: 65
- 2026-09-07: 65
- 2026-09-06: 64
- 2026-09-05: 64

## Common questions

### What is the Woo Revenue Incident Graph MCP server?

Woo Revenue Incident Graph is an MCP server listed in the public MCP registry as io.github.tytutueh13-sudo/woo-revenue-incident-graph. Check WooCommerce checkout-change risk using public evidence and privacy-safe store signals. This page covers its hosted endpoint (https://revenue-graph.utilityhouse.xyz/mcp/registry).

### Is the Woo Revenue Incident Graph MCP server safe to use?

Woo Revenue Incident Graph scores 72 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Woo Revenue Incident Graph MCP server expose?

Woo Revenue Incident Graph exposes 4 tools: get_checkout_health_snapshot, diagnose_revenue_incident, check_checkout_change_risk, verify_revenue_recovery. Their descriptions and schemas cost roughly 741 tokens of context every time the server is loaded.

### Does the Woo Revenue Incident Graph MCP server require authentication?

No. We connected to Woo Revenue Incident Graph without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the Woo Revenue Incident Graph MCP server still maintained?

Woo Revenue Incident Graph is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://revenue-graph.utilityhouse.xyz/mcp/registry
- Changelog RSS feed: https://verifymcp.io/servers/tytutueh13-sudo-woo-revenue-incident-graph/mcp-registry.xml
- Changelog JSON feed: https://verifymcp.io/servers/tytutueh13-sudo-woo-revenue-incident-graph/mcp-registry.json
- HTML version of this page: https://verifymcp.io/servers/tytutueh13-sudo-woo-revenue-incident-graph/mcp-registry