CallMeter

replay.webhook

Destructive

Replay a stored webhook delivery through the same forward/retry pipeline after your consumer was down. Requires API key. Charges 0.01 credits ($0.0001) per forward; see the billing note for failed calls. SIDE EFFECTS / DESTRUCTIVE: re-POSTs the original payload to destinations and may bill again — do not call casually. Prefer after confirmed consumer recovery. Billing errors stop the call. Inputs: required id (delivery id).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "replay.webhook"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Delivery id to replay. Example: dlv_01HXYZ

Output Schema

Name	Required	Description
`error`	No	Present on 409-style conflict
`status`	No	forwarded \| conflict \| failed
`replayed`	No
`delivery_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond annotations that already flag destructive=true and idempotent=false, the description discloses API-key requirements, a 0.01-credit charge per forward, possible re-billing on failed calls, billing errors that stop execution, and that the original payload is re-POSTed to destinations. This is substantial behavioral context an agent needs before invoking a costly mutation.

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 compact and front-loaded: purpose, prerequisites, billing, side effects, caution, and inputs are covered in a few dense sentences. Each sentence adds operational value, and the warning is placed prominently.

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?

With an output schema available, the description does not need to explain return values. It covers authentication, billing, destructive side effects, preconditions, and the sole input, leaving an agent with enough information to decide correctly whether and how to call it.

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 coverage is 100%, and the only required parameter 'id' is fully documented in the schema with an example. The description restates 'required id (delivery id)' but adds no syntax or format detail beyond what the schema already provides, so baseline 3 is appropriate.

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 states a specific verb and resource: 'Replay a stored webhook delivery through the same forward/retry pipeline.' It also gives the operational context ('after your consumer was down'), making the tool's purpose distinct from sibling tools like relay.webhook or capture.screenshot.

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 gives clear usage context: replay only after confirmed consumer recovery and warns 'do not call casually.' However, it does not explicitly compare this tool to relay.webhook or other alternatives, so it stops short of full alternative routing guidance.

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

All CallMeter tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?