Cito API

catch_up_webhook

After an endpoint outage: re-send the match and result events this webhook missed (failed, or skipped during a pause) and never received. Live ticks are left out. Use dryRun first to see how many. Stops at the first failure. API calls: 1.

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": "catch_up_webhook"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The webhook id, from list_webhooks or create_webhook. Never invent one.
`limit`	No	Max items to return (default 50, max 100). Example: 50.
`since`	No	ISO 8601 time. Default 24 hours ago, at most 7 days.
`dryRun`	No	Only report what is missing.

Output Schema

Name	Required	Description
`ok`	Yes	true if the tool succeeded
`data`	No	Result payload when ok is true; null on error
`meta`	Yes
`error`	No
`partial`	No
`pagination`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description discloses that delivery halts at the first failure, that live ticks are excluded, and that the call costs 1 API request. The one gap is whether re-sent events can produce duplicate deliveries to the endpoint.

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 short sentences plus a quota note; the outage scenario and scope exclusions are front-loaded and every clause carries information. Nothing is padded or restated from the schema.

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

Completeness4/5

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

For a mutation-ish delivery tool with an output schema and full parameter coverage, the description covers trigger, scope, failure behavior, and cost. Only duplicate-delivery semantics and whether partial progress is reported to the caller remain unstated.

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%, so id, limit, since, and dryRun are already documented with examples and bounds. The description only reinforces dryRun as a counting mode, adding little syntax or meaning the schema doesn't already carry.

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?

Names a specific verb and resource: re-send the match and result events a webhook missed after an endpoint outage. It also scopes the target set precisely (failed or skipped during a pause, never received, live ticks excluded), which separates it from list_webhook_events and webhook_deliveries.

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?

The trigger condition is explicit: use it after an endpoint outage to backfill missed events, and run dryRun first to see the count. It doesn't name a sibling such as replay_webhook or test_webhook as the alternative in adjacent cases, so the when-not is left implicit.

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

All Cito API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?