Skip to main content
Glama
revclamp

RevClamp MCP Server

Official

revclamp_evaluate_ghost_usage

Determines whether a metered API/SaaS usage event belongs to an entitled customer or is post-cancellation/post-grace ghost usage under Stripe 2025-03-31.basil.

Instructions

Evaluates whether a metered API/SaaS usage event belongs to an entitled customer or represents post-cancellation / post-grace ghost usage under Stripe 2025-03-31.basil.

Input Schema

NameRequiredDescriptionDefault
usageEventYesMetered usage event with customer_id, event_name, occurred_at (or occurred_at_sec).
subscriptionsYesStripe subscriptions list envelope ({ data: [...], has_more: false }).
dunningGracePeriodDaysNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.20.2
    • changedInput schema / properties / usageEvent / description
      Previous value: -"Metered usage event with customer_id, event_name, occurred_at."New value: +"Metered usage event with customer_id, event_name, occurred_at (or occurred_at_sec)."
  2. Changed10 schema fields changedv1.20.1
    • removedInput schema / properties / customerId
      Removed value: -{
      -  "description": "Required Stripe customer identifier to evaluate (format example: 'cus_9s6XKzkNRiz8i3', max 64 chars).",
      -  "type": "string"
      -}
    • addedInput schema / properties / dunningGracePeriodDays / default
      Added value: +3
    • removedInput schema / properties / dunningGracePeriodDays / description
      Removed value: -"Dunning grace window in integer days (valid range: 0 to 14, default: 3) after latest_invoice_failed_at during which past_due subscriptions remain entitled."
    • removedInput schema / properties / occurredAtSec
      Removed value: -{
      -  "description": "Optional alias for usageTimestampSec: Unix epoch timestamp in integer seconds (e.g. 1761264000) when the usage event occurred (used when usageTimestampSec is omitted).",
      -  "type": "integer"
      -}
    • changedInput schema / properties / subscriptions / description
      Previous value: -"Required Stripe customer subscriptions payload: either a Stripe list object ({ data: [...], has_more: false }) or a raw array of up to 50 subscription objects containing id, status ('active', 'trialing', 'past_due', 'canceled', 'unpaid'), current_period_end, or items.data[].current_period_end in Unix seconds."New value: +"Stripe subscriptions list envelope ({ data: [...], has_more: false })."
    • addedInput schema / properties / subscriptions / type
      Added value: +"object"
    • removedInput schema / properties / subscriptionsHasMore
      Removed value: -{
      -  "description": "Pagination completeness flag (boolean). Must be explicitly set to false when passing a raw subscriptions array so RevClamp can verify no active subscription was truncated on a later page.",
      -  "type": "boolean"
      -}
    • addedInput schema / properties / usageEvent
      Added value: +{
      +  "description": "Metered usage event with customer_id, event_name, occurred_at.",
      +  "type": "object"
      +}
    • removedInput schema / properties / usageTimestampSec
      Removed value: -{
      -  "description": "Optional Unix epoch timestamp in integer seconds (e.g. 1761264000) when the AI/API usage event occurred (defaults to current server Unix timestamp if omitted).",
      -  "type": "integer"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "customerId",
      -  "subscriptions"
      -]New value: +[
      +  "subscriptions",
      +  "usageEvent"
      +]
  3. First observedv1.20.0

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full behavioral burden. It explains the conceptual evaluation but does not state whether the tool is read-only, what permissions or Stripe API access are required, how missing or malformed subscriptions are handled, or what the result contains.

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?

The description is a single front-loaded sentence with no wasted text. The purpose and domain context are stated immediately, and the Stripe version qualifier is compact.

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

Completeness2/5

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

Given there are no annotations, no output schema, three parameters including two nested objects, and incomplete schema descriptions, the single sentence is not complete enough. It omits return-value behavior, dunning grace semantics, error conditions, and operational constraints.

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

Parameters2/5

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

Schema description coverage is only 67%, and the description adds no parameter-level meaning beyond the schema. It does not explain the dunningGracePeriodDays parameter at all, nor does it clarify the expected shape or handling of usageEvent and subscriptions beyond what the schema already says.

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 uses a specific verb, 'Evaluates whether,' and a precise resource: a metered API/SaaS usage event being entitled versus post-cancellation or post-grace ghost usage. It is clearly distinguishable from all listed sibling tools, which cover VAT validation, webhook verification, revenue leakage audits, ROI calculation, dispute linting, reconciliation, webhook replay, and dispute staging.

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

Usage Guidelines3/5

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

The description implies the usage context by framing the tool as determining whether a usage event is entitled or ghost usage. However, it gives no explicit when-to-use guidance, no exclusions, and no alternatives among the revclamp sibling tools.

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