Skip to main content
Glama

Webhook Studio

by com.webhook-studio

list_deliveries

List outbound delivery attempts for a bucket, newest first, with the full request and response of each. Pass success:false to see only failures — the direct answer to "which of my forwards are broken and why".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax deliveries to return (1–100, default 20).
cursorNoPagination cursor from a previous response.
sourceNoDelivery source.
successNoFilter to succeeded (true) or failed (false) deliveries.
bucket_idYesThe endpoint id.

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the burden. It discloses the sort order ('newest first'), the return content ('full request and response of each'), and the filtering behavior for success. This adds meaningful behavioral context beyond the schema.

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?

Two sentences, front-loaded with the primary action and resource. The second sentence provides a targeted usage tip. No wasted words.

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?

The description is complete for a list tool: it explains the core output (full request/response), ordering, and a common diagnostic use case. It does not explain pagination or the source filter, but those are covered by the schema, and there is no output schema to complicate matters.

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 100%, so baseline is 3. The description adds value by specifically explaining the success:false parameter and its use case, going beyond the schema's simple boolean filter 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?

The description clearly states the verb 'List' and the resource 'outbound delivery attempts for a bucket', with specifics like 'newest first' and 'full request and response'. This distinguishes it from sibling tools like list_events and list_buckets.

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 provides an explicit use case: passing success:false to see only failures, framed as the direct answer to 'which of my forwards are broken and why'. It does not name alternatives or exclusions, but the context is clear and actionable.

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

All Webhook Studio toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct resource and action: buckets, events, schemas, deliveries, forwarding, verification, replay, and waiting. Even similar pairs like latest_event vs list_events are clearly differentiated by purpose, with no overlapping responsibilities.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern with underscores, such as create_bucket, list_events, and delete_bucket. The only slight deviation is 'latest_event', which uses an adjective instead of a verb, but it remains intuitive and does not disrupt the overall predictability.

Tool Count4/5

At 17 tools, the set is slightly above the typical well-scoped range of 3-15, but the domain covers buckets, events, schemas, deliveries, configuration, and more, so each tool serves a distinct and justified purpose. The count feels appropriate for the platform's breadth rather than excessive.

Completeness3/5

The set covers the primary lifecycle for buckets, events, and schemas, including create, read, list, and delete operations. However, there is no way to update or delete a forwarding rule after creation, and no explicit update operation for bucket metadata, leaving notable gaps in managing configurations.

Resources