Skip to main content
Glama
beel-es

BeeL MCP server

Official
by beel-es
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

beel_list_webhook_deliveries

Read-onlyIdempotent

Retrieve webhook delivery attempts for a subscription in reverse chronological order, with each response. Filter by event type or event ID to trace retries and diagnose delivery failures.

Instructions

Returns the delivery attempts of this subscription, newest first. Each entry records one attempt with the response it got, so a retried event appears once per attempt.

  • event_type: narrows the list to a single event type.

  • event_id: follows one event across every attempt made on it, without paging through the whole history.

Endpoint: GET /v1/accounts/{account_id}/webhooks/{webhook_id}/deliveries

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number, starting at 1. The response echoes it back as `pagination.current_page`.
limitNoHow many items to return per page. The response echoes it back as `pagination.items_per_page`.
event_idNoOnly deliveries of this event. Use it to follow every attempt on one event without paging through the whole history.
account_idYesYour own account, or an account you provisioned. It — not the credential, and not the `BeeL-Active-Company` header — decides which account the operation acts on. An account you do not reach answers `403`, and so does an account that does not exist, so the existence of somebody else's account is never disclosed.
event_typeNoOnly deliveries of this event type.
webhook_idYesSubscription of the account in the path. A subscription of another account answers `404`, the same as one that does not exist: under the account resolved from `{account_id}` it simply is not there.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observedv0.3.1

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/destructive annotations, it discloses meaningful runtime behavior: results are newest first, each entry records one attempt with the response it got, and retried events appear once per attempt. This is exactly the kind of behavioral context annotations cannot convey.

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 is tight, front-loaded, and organized with a brief core sentence followed by focused bullets. The endpoint line and parameter bullets partially duplicate the schema, but they do not add meaningful bloat and are easy for an agent to scan.

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 6-parameter list operation with full schema coverage, the description plus schema cover path, sorting, filters, pagination, and output semantics. There is no output schema, and while the description could specify return fields more deeply, 'each entry records one attempt with the response it got' gives sufficient shape for correct invocation.

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%, and the schema already documents each parameter in comparable or greater detail. The description's event_type and event_id bullets restate the schema's descriptions rather than adding new semantic information, so a baseline 3 is appropriate.

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?

The description opens with a specific verb and resource: 'Returns the delivery attempts of this subscription,' and immediately states the ordering ('newest first'). The endpoint line and the clarification that each retried event appears once per attempt remove ambiguity about what this tool returns.

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 description gives clear context for when to use the tool and adds practical filter guidance for event_type and event_id, especially the 'without paging through the whole history' use case. It does not explicitly name sibling alternatives or state when not to use it, but the tool's role as a list operation is clear.

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