Skip to main content
Glama

Alert deliveries

alert_deliveries
Read-onlyIdempotent

The delivery status of the workspace's alerts, newest first. Every attempt has a claim row (queued, or held_budget or held_quiet when it was not sent, digest when the fact arrived too old for an immediate alert) and an outcome row (sent or failed with its error_class). A delivered row means the receiver confirmed it (a signed webhook, or the SMS provider's final report), undelivered is the SMS provider's final negative report, and a dead_letter row closes an endpoint delivery whose failure is permanent or whose every retry is spent. Rows name the alert event by event_id and an endpoint by endpoint_id; a user's identity is not served. A key reads the deliveries of its own team's alerts and of workspace wide ones. Filter by event_id, status or channel. Paged with limit and offset; the response carries the exact total.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "alert_deliveries"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoPage size, default 50, maximum 100.
offsetNoRows to skip, default 0.
statusNoOnly rows with this status.
channelNoOnly rows on this channel.
event_idNoOnly the deliveries of this alert event.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / event_id / maximum
      Previous value: -2147483647New value: +9223372036854776000
  2. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only declare read-only, idempotent, non-destructive, and closed-world behavior, while the description adds substantial context: what held_budget, held_quiet, digest, delivered, undelivered, and dead_letter mean; how confirmation works; and that user identity is not served. This goes well beyond what the annotations provide.

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?

The description front-loads the resource and ordering, then moves through status semantics, access scope, filtering, and pagination. It is dense but every sentence carries useful semantic information; it could be slightly more scannable, but the length is warranted by the complexity.

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 no output schema, the description still explains the row structure, status meanings, access rules, available filters, pagination, and that the response includes an exact total. That is enough for an agent to invoke the tool correctly and interpret the result.

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 description coverage is 100%, so the schema already documents every parameter and its enum values. The description adds useful interpretation of the status values and reiterates the event_id/status/channel filters and limit/offset paging, though it does not add syntax-level detail 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 clearly identifies the resource as alert deliveries for the workspace's alerts, newest first, and explains the claim/outcome row model. It does not explicitly contrast with the sibling alert_events tool, so it falls short of full sibling differentiation.

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

Usage Guidelines3/5

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

It states the available filters and access rules (own team's alerts and workspace-wide ones), which implies when to use the tool, but it gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The usage context is therefore adequate but inferential.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources