Skip to main content
Glama
Sign In

Nextmail

by sh.nextmail
OverviewDiscussionsAdmin

List webhook dead letters

listWebhookDeadLetters
Read-only

The events one webhook endpoint gave up on, newest first: every event whose last automatic attempt failed, because its retries ran out, the receiver gave an answer that is not tried again, or the endpoint was switched off before the next retry. Each row names the event, how many times it was tried, the last answer and that attempt, which getWebhookDelivery reads in full. status is open by default, the ones still waiting to be replayed or discarded; replayed, discarded and all read the rest. A dead letter is kept 30 days after the event was given up on. One page at a time: when more follow, the last line gives a cursor to pass back for the next page.

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": {
      "endpointId": "<endpointId>"
    },
    "name": "listWebhookDeadLetters"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
sinceNoAn ISO 8601 instant, such as 2026-09-01T00:00:00Z.
untilNoAn ISO 8601 instant, such as 2026-09-01T00:00:00Z.
cursorNo
statusNo
endpointIdYesThe webhook endpoint, by its id (whe_…). listWebhooks names every one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover read-only/non-destructive, and the description adds real value beyond them: newest-first ordering, the 30-day retention window, per-row contents, and cursor-based single-page pagination. It stops short of saying what a replay or discard does to the list, but the disclosure of lifecycle and retention is substantial.

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-loads the purpose and definition, then moves to row shape, status scoping, retention and pagination in a logical order. The sentences are long and semicolon-dense, but every clause carries information rather than filler.

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?

With no output schema, the description usefully describes the returned row fields and pagination signal, and it covers retention and ordering. The remaining gap is the limit parameter and the exact semantics of the since/until range, which an agent would have to guess.

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 only 50%, and the description compensates for the two least obvious parameters: the status enum meanings and default, and the cursor being the last line of a page to pass back for the next page. It says nothing about limit or about what since/until filter on, which leaves a gap on 3 of 6 params.

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 resource (dead-lettered events for one webhook endpoint) with an exact definition of what qualifies as a dead letter — retries exhausted, non-retryable receiver answer, or endpoint disabled before retry. It also differentiates from the sibling getWebhookDelivery by saying that tool reads the full attempt detail.

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?

Explains the status scoping up front (open by default, replayed/discarded/all for the rest) and points to getWebhookDelivery for full detail, which is a genuine alternative. It does not explicitly contrast with listWebhookDeliveries or listWebhookEvents, so the sibling routing is implied rather than stated.

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

All Nextmail toolsInspect
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