CallMeter

relay.webhook

Idempotent

Relay a third-party webhook into CallMeter: verify HMAC or shared secret, dedupe by delivery id, store the payload, and forward to the endpoint's destinations with retries. Charges 0.01 credits ($0.0001) per forward, not on receive; see the billing note for failed calls. SIDE EFFECTS: contacts external destination URLs you configured; may retry on failure. Prefer when an agent must accept provider callbacks without running its own queue. Billing and ceiling errors stop the call. Inputs: required id (endpoint id) plus upstream JSON body.

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": "relay.webhook"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	CallMeter webhook endpoint id (ep_…). Example: ep_live_abc123
`deliveryId`	No	Optional idempotent delivery id (maps to X-Webhook-Delivery-Id). Same id within 24h dedupes — no second charge.

Output Schema

Name	Required	Description
`status`	No	accepted \| duplicate \| forwarded
`accepted`	No	True when ingress accepted for forward pipeline
`duplicate`	No	True when same delivery id within 24h dedupe window (no re-charge)
`delivery_id`	No	Stored delivery id

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 10, 2026

TDQS

A4.3/5.0

Behavior5/5

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

The description adds substantial behavior beyond annotations: it contacts external destination URLs, may retry on failure, charges per forward rather than receive, and billing or ceiling errors stop the call. These details are directly relevant to a mutation-capable open-world tool and do not contradict the annotations.

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 front-loaded with the core operation, then covers side effects, billing, usage preference, and inputs. Each sentence contributes practical information without redundant repetition.

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 tool's complexity, the annotations, the complete input schema, and the presence of an output schema, the description is complete enough for an agent to call it correctly. It covers verification, dedupe, forwarding, retries, billing implications, and side effects.

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 both id and deliveryId thoroughly. The description adds only that id is required and the upstream JSON body is passed, which is useful framing but not meaningful new parameter semantics beyond the schema.

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?

The description states a specific verb and resource: relay a third-party webhook into CallMeter, including verify, dedupe, store, and forward steps. It does not explicitly differentiate from the sibling replay.webhook tool, so it is clear but lacks sibling-level disambiguation.

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 a clear usage context: prefer this when an agent must accept provider callbacks without running its own queue. It does not name explicit exclusions or alternatives such as replay.webhook, so it stops short of full when/when-not 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?