Meridian

List Shopify Webhook Deliveries

webhook_deliveries_list

Read-only

Lists recent inbound Shopify webhook deliveries for an app, newest first. Each entry reports topic, shop_domain, status, attempts, response_code (what the app's handler answered), error_message, and the triggered_at / forwarded_at / handled_at timestamps.

Use it to tell apart the two failures that look identical from inside the repo: no delivery row for a topic means Shopify never sent it (check webhook_routes_list. The topic is probably unrouted or failed to register), while a row with a 4xx/5xx response_code means it arrived and the app's own handler rejected it.

Optionally filter by topic (exact Shopify topic, e.g. orders/create) or status. limit defaults to 20 and caps at 100.

THE WEBHOOK BODY IS NEVER RETURNED. It is merchant commerce data, and neither are the request headers, which carry the HMAC signature. Read a payload in the Meridian dashboard when you need one.

Takes the app_id from apps_list.

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": {
      "app_id": "<app_id>"
    },
    "name": "webhook_deliveries_list"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum deliveries to return. Default 20, maximum 100.
`topic`	No	Only deliveries for this exact Shopify topic, e.g. `orders/create`.
`app_id`	Yes	The app uuid returned by `apps_list`.
`status`	No	Only deliveries in this state: `processed`, `failed`, `ignored`, `received`, `blocked` or `dropped`.
`organization_id`	No	An organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026

changedInput schema / properties / status / description

Previous value: -"Only deliveries in this state, e.g. `forwarded`, `failed`, `pending`."New value: +"Only deliveries in this state: `processed`, `failed`, `ignored`, `received`, `blocked` or `dropped`."

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare read-only and non-destructive, and the description goes well beyond them by stating the webhook body and HMAC-bearing headers are never returned and pointing to the dashboard for payloads. It also discloses ordering (newest first), the default and cap on `limit`, and the meaning of `response_code`, which is what an agent needs to plan a diagnosis.

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 purpose, then diagnostic logic, then filters, then the data-withholding warning in caps. Slight waste in the trailing 'Takes the `app_id` from `apps_list`', which merely repeats the schema's own note.

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 enumerates the returned fields (`topic`, `shop_domain`, `status`, `attempts`, `response_code`, `error_message`, timestamps) and explains what `response_code` represents. Combined with the diagnostic framing and the payload exclusion, an agent has everything needed to call and interpret it.

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 description coverage is 100%, so all five parameters are already documented, including the `limit` cap and example topic. The description reinforces `app_id` provenance and filter intent but adds no syntax or edge-case detail absent from the schema, making the baseline 3 correct.

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 and resource ('Lists recent inbound Shopify webhook deliveries for an app, newest first') and names the sibling it complements ('webhook_routes_list'), so an agent can distinguish it 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?

Gives an explicit decision procedure: no delivery row for a topic means Shopify never sent it, so go check routes; a row with 4xx/5xx means the app's handler rejected it. This is a concrete when-to-use and when-to-look-elsewhere rule, not a generic restatement.

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

All Meridian tools Inspect

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

Need Help?