Skip to main content
Glama

Audit B2B Revenue Leakage & Dispute Readiness

revclamp_audit_revenue_leakage
Read-onlyIdempotent

Run a deterministic 90-day B2B revenue leakage and chargeback readiness audit across Stripe subscriptions, AI/API usage telemetry events, and open disputes. Executes as a 100% read-only, stateless diagnostic with zero external Stripe mutations. Returns structuredContent containing ok, mode, statelessEphemeralAudit, tenantId, dunningGracePeriodDays, costPerEventCents, and audit (scannedCustomers, scannedEvents, ghostLeakEventsCount, affectedCustomersCount, estimatedBleedUsd, disputesEligibleForAutoEvidence). Use this tool for portfolio-wide multi-customer audits; use revclamp_evaluate_ghost_usage for single-customer entitlement checks or revclamp_stage_stripe_dispute_ce3 to build a single dispute's Visa CE 3.0 evidence bundle.

Input Schema

NameRequiredDescriptionDefault
demoNoOptional simulation flag (boolean) for deterministic sample audit preview.
disputesNoOptional array of up to 50 Stripe dispute objects (each with id like 'du_123', customer, amount in cents, reason such as 'fraudulent', and status such as 'needs_response').
customersNoOptional array of up to 50 Stripe customer snapshots (each with id like 'cus_123', optional email, subscriptions array or list object, and subscriptionsHasMore: false). Omit to run against workspace telemetry or deterministic sandbox fixtures.
usageEventsNoOptional array of up to 200 product/AI API usage telemetry events (each with stripe_customer_id or email, event_name, and occurredAtSec Unix timestamp in seconds).
costPerEventCentsNoEstimated marginal compute or API cost per leaked usage event in integer USD cents (valid range: 1 to 100000, default: 142 i.e. $1.42/event).
dunningGracePeriodDaysNoCustom dunning grace window in integer days (valid range: 0 to 14, default: 3) allowed after latest_invoice_failed_at before flagging past_due subscriptions as unpaid ghost usage.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / costPerEventCents / description
      Previous value: -"Estimated marginal compute or API cost per leaked usage event in integer USD cents (valid range: 1 to 10000, default: 142 i.e. $1.42/event)."New value: +"Estimated marginal compute or API cost per leaked usage event in integer USD cents (valid range: 1 to 100000, default: 142 i.e. $1.42/event)."
    • changedInput schema / properties / costPerEventCents / maximum
      Previous value: -10000New value: +100000
    • addedInput schema / properties / demo
      Added value: +{
      +  "description": "Optional simulation flag (boolean) for deterministic sample audit preview.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds substantive context beyond annotations: it is stateless and ephemeral, performs zero external Stripe mutations, and enumerates the structuredContent return fields so an agent knows what to expect.

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

Conciseness5/5

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

Three dense sentences: purpose first, behavioral guarantees second, routing guidance third. The enumeration of return fields is long but earns its place because there is no output schema.

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?

Complete for a stateless audit tool with no output schema: annotations cover safety, the input schema covers all parameters, and the description covers return fields and sibling routing. Nothing an agent needs to invoke it correctly 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 documents all six parameters with types, ranges, defaults, and examples. The description does not add parameter-level semantics beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource: a deterministic 90-day B2B revenue leakage and chargeback readiness audit across Stripe subscriptions, usage telemetry, and disputes. It clearly distinguishes itself from the named sibling tools for single-customer checks and single-dispute evidence staging.

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

Usage Guidelines5/5

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

Explicitly says to use this tool for portfolio-wide multi-customer audits and names the alternatives: revclamp_evaluate_ghost_usage for single-customer entitlement checks and revclamp_stage_stripe_dispute_ce3 for a single dispute's Visa CE 3.0 evidence bundle. This gives clear when-to-use and when-to-use-something-else guidance.

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.