io.github.tytutueh13-sudo/woo-revenue-incident-graph

Est-ce que io.github.tytutueh13-sudo/woo-revenue-incident-graph est sûr ?

Au dernier audit MCP Hub, le serveur MCP « io.github.tytutueh13-sudo/woo-revenue-incident-graph » est classé « Non encore testé ». Référencé dans l'annuaire. Seul le pentest comportemental fait foi, et il n'a pas encore été exécuté sur ce serveur. Le verdict est réévalué en continu ; consultez la fiche pour l'état à jour.

Méthode : MCP Hub analyse la description de chaque outil (couche 1) et, pour le verdict fort, exécute le serveur dans une micro-VM isolée avec leurres et réseau bloqué (couche 2). On publie des noms et des compteurs, jamais le contenu brut renvoyé par un outil.

Les 4 outils

• check_checkout_change_risk≈ 532 tokens

  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.

  Paramètres, retour & exemple (2)

  Paramètres

  • component · string · optionnel
    e.g. "plugin:woocommerce-gateway-stripe". Omit to check this store's own recent changes.
  • to_version · string · optionnel

  Exemple d'appel

  {"name": "check_checkout_change_risk", "arguments": {"component": "texte", "to_version": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"source": "named_component", "checked": [], "billable": true, "price_micros": 1}}

• diagnose_revenue_incident≈ 1456 tokens

  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.

  Paramètres, retour & exemple (2)

  Paramètres

  • symptom · string · optionnel · orders_dropped | payment_succeeded_order_pending | failed_orders_spiked | payment_method_missing | checkout_errors | unknown
    What the merchant reports. Use "unknown" rather than guessing.
  • window_seconds · integer · optionnel
    Window in seconds. Default 86400 (24h), maximum 604800 (7d).

  Exemple d'appel

  {"name": "diagnose_revenue_incident", "arguments": {"symptom": "orders_dropped", "window_seconds": 1}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"window": {}, "symptom": "texte", "billable": true, "coverage": {}, "timeline": [], "abstained": {}, "hypotheses": [], "price_micros": 1, "data_freshness": "fresh", "failure_pattern": "card_testing_suspected", "failure_pattern_reasoning": []}}

• get_checkout_health_snapshot≈ 949 tokens

  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.

  Paramètres, retour & exemple (1)

  Paramètres

  • window_seconds · integer · optionnel
    Window in seconds. Default 86400 (24h), maximum 604800 (7d).

  Exemple d'appel

  {"name": "get_checkout_health_snapshot", "arguments": {"window_seconds": 1}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"reason": "texte", "coverage": {}, "connected": true, "collected_at": 1, "order_counts": {}, "data_freshness": "fresh", "recent_changes": 1, "gateway_summary": {}, "webhook_summary": {}, "scheduler_overdue": 1, "error_fingerprints": 1, "diagnosis_recommended": true}}

• verify_revenue_recovery≈ 398 tokens

  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.

  Paramètres, retour & exemple (2)

  Paramètres

  • window_seconds · integer · optionnel
    Window in seconds. Default 86400 (24h), maximum 604800 (7d).
  • change_applied_at · integer · requis
    Epoch ms when the fix was applied.

  Exemple d'appel

  {"name": "verify_revenue_recovery", "arguments": {"change_applied_at": 1}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"after": {}, "before": {}, "reason": "texte", "status": "resolved", "billable": true, "price_micros": 1, "new_regressions": []}}

C'est votre serveur ?

Revendiquez-le sur l'espace créateur (preuve GitHub, domaine ou npm) pour afficher le badge « propriétaire vérifié » et lancer un pentest comportemental à la demande afin d'obtenir le badge « Vérifié ».

Créer un compte / revendiquer →

Source

https://revenue-graph.utilityhouse.xyz/mcp/registry