Skip to main content
Glama

Why did this store's checkout revenue break?

diagnose_revenue_incident
Read-onlyIdempotent

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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
symptomNoWhat the merchant reports. Use "unknown" rather than guessing.
window_secondsNoWindow in seconds. Default 86400 (24h), maximum 604800 (7d).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
windowYes
symptomYes
billableYes
coverageYes
timelineYes
abstainedYes
hypothesesYes
price_microsYes
data_freshnessYes
failure_patternYes
failure_pattern_reasoningYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (read-only, idempotent, open-world, non-destructive), the description discloses that the tool reports which signal families were collectable, returns counterevidence and unknowns, abstains without charging when evidence is insufficient, and is free in beta. These are meaningful behavioral details that materially affect how an agent should interpret the response.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every major section earns its place: purpose, signal coverage, abstention policy, beta status, and prerequisite. The prerequisite instruction at the end is slightly less front-loaded than ideal, but the overall structure is clear and not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema and annotations, the description is fully complete: it explains return shape, coverage limits, abstention conditions, cost implications, and the required prerequisite call. Nothing an agent needs to decide whether and how to invoke the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents symptom and window_seconds. The description adds no additional parameter-level guidance beyond the existing schema, matching the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool diagnoses what broke a store's checkout/payment path, supplies counterevidence, and advises on verifying a fix. It describes concrete outputs (ranked hypotheses, evidence, verification plan) and clearly distinguishes itself from the sibling get_checkout_health_snapshot by naming it as a prerequisite rather than duplicating it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It tells the caller to invoke get_checkout_health_snapshot first and explains when the tool abstains (stale snapshot, thin coverage, unsupported signals), which is useful usage context. However, it does not explicitly contrast itself with verify_revenue_recovery or check_checkout_change_risk, so the guidance is strong but not fully explicit about all sibling alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources