Skip to main content
Glama
RajGehlot28

@twitterapis/mcp

by RajGehlot28
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

twitter_monitor_webhook_redrive

Replay webhook deliveries that dead-lettered during an endpoint outage, requeuing them with a full retry budget oldest first while skipping permanent failures.

Instructions

Replay deliveries that dead-lettered while your endpoint was down. A delivery is dead-lettered after it fails all 8 attempts across 21 minutes, so an outage longer than that window loses those events; this re-queues them with a full retry budget, oldest first. Bounded by default so a recovered endpoint is not flooded: max_age_hours defaults to 24 and limit to 100. Returns requeued and skipped_permanent. A delivery that died for a permanent reason, a 410 Gone, a deleted webhook, or a URL egress refused, is not replayed, because it would fail the same way and spend the budget again. Replayed events carry the same signature and payload as the original, so make your handler idempotent on the event id if a duplicate would matter. Returns 409 if the webhook is disabled, which happens after your endpoint answers 410 Gone: re-register it first. Free per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe webhook's id, from twitter_monitor_webhook_create or twitter_monitor_webhook_list.
limitNoOptional. Most deliveries to replay in one call, 1 to 1000, oldest first. Defaults to 100.
max_age_hoursNoOptional. How far back to look for dead-lettered deliveries, 1 to 168 hours. Defaults to 24.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.9

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true); the description goes far beyond them by disclosing retry semantics (8 attempts across 21 minutes, full budget on replay), oldest-first ordering, bounded defaults to avoid flooding, the 409-on-disabled behavior, and the idempotency requirement for duplicate event ids.

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?

Front-loaded with the core action and the outage context, and dense with operational detail rather than filler. It is longer than average, but nearly every clause carries a distinct behavioral fact (retry budget, defaults, permanent-failure exclusion, idempotency, 409, cost), so the length is largely justified.

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?

For a mutation-style webhook operation with no output schema, the description explicitly covers the return values (requeued, skipped_permanent), the failure case (409), the safety implications (idempotency), and the cost model. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is already 100% (both optional params document ranges and defaults), so the baseline is 3. The description adds meaning the schema lacks: why the bounds exist ('so a recovered endpoint is not flooded') and the oldest-first replay order, which is not stated in either param description.

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?

States a specific verb (replay/redrive) and resource (dead-lettered webhook deliveries), plus the exact trigger condition ('dead-lettered while your endpoint was down'). An agent can distinguish this from sibling webhook tools like twitter_monitor_webhook_list or twitter_monitor_deliveries without opening a schema.

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

Usage Guidelines5/5

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

Explicitly scopes when to use (after an outage that exceeded the retry window) and when not to (permanent failures such as 410 Gone, deleted webhook, or egress-refused URLs are never replayed, with the reason given). It also names the prerequisite for the 409 case: re-register a disabled webhook first.

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

Deploy Server

Other Tools