Skip to main content
Glama
revclamp

RevClamp MCP Server

Official

revclamp_simulate_webhook_replay

Simulates out-of-order and duplicate subscription lifecycle webhooks against a 72-hour deduplication window and creation-time watermark to reveal replay gaps versus naive arrival-order handling.

Instructions

Simulates out-of-order and duplicate subscription lifecycle webhooks against a 72-hour deduplication Set and monotonic createdSec watermark vs. a naive arrival-order handler.

Input Schema

NameRequiredDescriptionDefault
eventsNo
scenarioPresetNoout_of_order_stale_update_after_cancel
idempotencyWindowSecNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv1.20.1
    • removedInput schema / properties / events / description
      Removed value: -"Optional custom array of 1 to 10 webhook events ({ eventId, eventType, createdSec, subscriptionStatus, tier, currentPeriodEndSec }) in arrival order."
    • removedInput schema / properties / events / items
      Removed value: -{
      -  "additionalProperties": false,
      -  "properties": {
      -    "createdSec": {
      -      "description": "Provider event creation timestamp in Unix seconds (must be <= nowSec + 34560000 / 400 days) compared monotonically against lastAppliedCreatedSec.",
      -      "maximum": 4102444800,
      -      "minimum": 946684800,
      -      "type": "integer"
      -    },
      -    "currentPeriodEndSec": {
      -      "description": "Optional subscription current_period_end timestamp in Unix seconds.",
      -      "maximum": 4102444800,
      -      "minimum": 946684800,
      -      "type": "integer"
      -    },
      -    "eventId": {
      -      "description": "Unique provider webhook event ID (e.g. evt_cancel_final_1050) checked against the 72-hour deduplication Set.",
      -      "maxLength": 96,
      -      "minLength": 1,
      -      "pattern": "^[A-Za-z0-9_.:-]{1,96}$",
      -      "type": "string"
      -    },
      -    "eventType": {
      -      "description": "Webhook event type string (e.g. customer.subscription.deleted, customer.subscription.updated, invoice.payment_failed).",
      -      "maxLength": 96,
      -      "minLength": 1,
      -      "pattern": "^[A-Za-z0-9_.-]{1,96}$",
      -      "type": "string"
      -    },
      -    "subscriptionStatus": {
      -      "description": "Subscription lifecycle status carried by this webhook event.",
      -      "enum": [
      -        "active",
      -        "trialing",
      -        "past_due",
      -        "paused",
      -        "canceled",
      -        "cancelled",
      -        "unpaid",
      -        "cancel_at_period_end",
      -        "expired"
      -      ],
      -      "type": "string"
      -    },
      -    "tier": {
      -      "description": "Optional RevClamp plan tier associated with the subscription state (default: 'growth_59').",
      -      "enum": [
      -        "free",
      -        "starter_19",
      -        "growth_59",
      -        "scale_199"
      -      ],
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "eventId",
      -    "eventType",
      -    "createdSec",
      -    "subscriptionStatus"
      -  ],
      -  "type": "object"
      -}
    • removedInput schema / properties / events / maxItems
      Removed value: -10
    • removedInput schema / properties / events / minItems
      Removed value: -1
    • addedInput schema / properties / idempotencyWindowSec / default
      Added value: +259200
    • removedInput schema / properties / idempotencyWindowSec / description
      Removed value: -"Deduplication and replay-acceptance window in seconds (valid range: 60 to 2592000, default: 259200 for 72 hours)."
    • removedInput schema / properties / nowSec
      Removed value: -{
      -  "description": "Reference evaluation timestamp in Unix seconds used to check the 72-hour idempotency window.",
      -  "maximum": 4102444800,
      -  "minimum": 946684800,
      -  "type": "integer"
      -}
    • addedInput schema / properties / scenarioPreset / default
      Added value: +"out_of_order_stale_update_after_cancel"
    • removedInput schema / properties / scenarioPreset / description
      Removed value: -"Scenario preset to evaluate when custom events are omitted (default: 'out_of_order_stale_update_after_cancel')."
    • changedInput schema / properties / scenarioPreset / enum
      Previous value: -[
      -  "out_of_order_stale_update_after_cancel",
      -  "duplicate_event_id_replay_72h",
      -  "valid_monotonic_upgrade_sequence",
      -  "expired_72h_window_stale_event",
      -  "custom"
      -]New value: +[
      +  "out_of_order_stale_update_after_cancel",
      +  "duplicate_event_id_replay_72h",
      +  "valid_monotonic_upgrade_sequence",
      +  "expired_72h_window_stale_event"
      +]
  2. First observedv1.20.0

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations present, the description carries the full burden. It usefully discloses the core behavioral model — deduplication Set with a 72-hour window and a monotonic createdSec watermark compared against a naive handler — but says nothing about side effects (whether events actually hit an endpoint), return shape, or what 'simulate' produces. Meaningful but incomplete disclosure.

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?

A single front-loaded sentence with no filler; the core mechanism comes first. The density of undisclosed jargon ('monotonic createdSec watermark') makes it slightly harder to parse than necessary, but nothing is wasted.

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?

No annotations, no output schema, no required parameters, and 0% schema description coverage mean the description is the only source of truth — yet it omits return values and the semantics of two of three parameters. For a simulation tool whose output is the whole point, this leaves significant gaps.

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 coverage is 0% and all three parameters are undocumented. The description implies the 72-hour window that idempotencyWindowSec defaults to, but doesn't state the window is configurable, doesn't describe what the 'events' array items look like, and doesn't explain how scenarioPreset interacts with events (precedence or mutual exclusivity).

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

Purpose4/5

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

States a specific verb ('Simulates') and a precise resource (out-of-order/duplicate subscription lifecycle webhooks) plus the mechanism it tests (72-hour dedup Set, monotonic createdSec watermark, naive arrival-order baseline). This clearly separates it from the only webhook-adjacent sibling, revclamp_verify_webhook_signature, though it never names siblings explicitly.

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

Usage Guidelines2/5

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

There is no explicit when-to-use, when-not, or alternative-tool guidance. The phrase 'vs. a naive arrival-order handler' hints at a comparison/testing purpose but leaves the agent to infer when to pick this over other revclamp tools.

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