Can an AI agent debug a failed webhook on Sume over MCP?
Over MCP an agent can read job status, events and delivery status to see why a webhook did not arrive. Redeliver is a REST call that needs jobs:write.
Partly. Over the MCP server an agent can read a job's state, its events, and the webhook delivery status on the job. The resend itself is the REST call POST /v1/jobs/{id}/webhook/redeliver, which needs jobs:write; the MCP job tools listed in the docs are read tools plus jobs_cancel.
Sume details are from MCP tools and gates and Job webhooks, read 2026-09-30.
What are the vendors doing?
Svix's September 2026 changelog says its App Portal MCP server lets a customer's coding agent read endpoints, failed delivery attempts, payloads and responses, and even resend messages or recover an endpoint. Hookdeck's CLI v3 entry says its Event Gateway MCP server gains write mode behind --allow-write, where the agent can create, update, retry and dismiss; without the flag it stays read-only.
What can an agent read on Sume?
| Question | Where to look |
|---|---|
| Did the job finish? | jobs_status or jobs_get |
| What happened, in order? | jobs_events, which can include webhook.delivery |
| Did delivery fail? | Webhook delivery status and attempt count on the job object |
| Possible statuses | pending, delivering, delivered, retrying, failed, exhausted |
| Resend the event | REST redeliver, needs jobs:write |
What should the agent do first?
Read jobs_status. If the job is terminal, the result is available through jobs_result whether or not a webhook arrived, so the agent can report the result without resending. If delivery shows retrying, the receiver is failing: check for non-2xx answers, redirects, or the 10-second timeout.
When is a redeliver the right call?
When the receiver is fixed and a downstream system still needs the event. Redeliver re-sends the real terminal event with a fresh signature, and works after automatic attempts are exhausted. Give it to the agent only with a key you are willing to let write jobs. See jobs_wait versus webhooks.
Sources
Related posts
More in Developers
- Agent loops on Sume: tool calls spend writes, polls spend reads
An MCP tool call spends the write budget once for the run it creates; a jobs_status poll spends none. Reads have their own, much larger budget.
- AI SDK isLoopFinished vs the 20-step cap for Sume video jobs
ToolLoopAgent stops after 20 steps by default. How many jobs_wait calls a Sume video render needs, and the per-call guards to keep if you lift the cap.
- AI SDK MCP client close() in onEnd: Sume jobs keep running
Closing the AI SDK MCP client in onEnd ends the tool connection, not the Sume jobs already submitted. Track job ids, then read or cancel them.
- Airtable script 50-fetch limit: send 100 records as one bulk run
An Airtable automation script gets 50 fetches and a 30-second timeout. One Sume bulk-run request carries up to 100 items, so one fetch beats a per-record loop.
Written by Sume