Webhook Ingest with AI: Paste a URL, Read What Lands in Chat
TL;DR
- The Webhook Ingest MCP server gives each connection a hosted URL — paste it into anything that can POST content (schedulers, form tools, monitoring systems, export jobs, custom scripts) and ask in chat for the latest delivery, recent history, or a specific stored payload.
- Each connection keeps a rolling history of what arrived — CSV, JSON, raw bodies, file uploads, and common document types — so agents answer from stored data, not from memory.
- Built for teams who already have push data somewhere but still copy-paste files into chat, or maintain one-off receivers nobody wants to operate.
Brightline Ops wires a dozen small integrations. Nightly exports, form submissions, alert dumps — all of them know how to POST to an HTTPS URL. What they did not have was a place those payloads could sit until someone asked an agent a question about them.
Chat only helps when the agent reads what already landed, not when someone rebuilds a listener for every new sender.
The whole product is: URL in, read from chat
There is no vertical lock-in. The pattern is the same whether the upstream system is a BI scheduler, a Typeform-style form, a cron job you wrote last year, or a SaaS product with a "send to URL" setting.
- Open Webhook Ingest in your MCPBundles workspace and save a connection. Give it a short label ("Nightly export", "Lead form dump", "Inventory sync") and optional notes about what the payloads mean.
- Copy the ingest URL from the connection panel.
- Paste it into the upstream system's delivery settings — wherever it asks for an HTTPS endpoint — and turn sending on.
MCPBundles hosts the receiver. You are not running nginx, S3, or a Lambda on your side. When the upstream fires, the payload POSTs to us; we store it against that connection; your agent reads it through MCP in Claude, Cursor, or another client.
Optional signing secret: if the sender supports HMAC on the raw body, you can require it. Many systems rely on the unique URL alone — both paths work.
"Latest" is almost always the right first question
Most prompts are not about payload ids. They are about what changed.
"What was in the last delivery?"
"Did anything arrive since yesterday?"
"Summarise the JSON that landed this morning."
Start with the latest stored delivery — filename or content type, capture time, and parsed preview when the body is CSV or JSON. If the timestamp is older than the user expects, say so: agents cannot force a new send from chat; data arrives when the upstream sends it.
History when senders repeat or fail silently
Sometimes the question is comparative or forensic.
"List the last ten deliveries and flag duplicate filenames."
"Compare the two most recent CSV exports — did row count drop?"
Use recent deliveries when debugging a schedule, spotting duplicate sends, or picking a specific run by date. Each POST is one stored delivery — not a merged warehouse. Comparisons happen in the conversation.
Formats: structured previews where we can, storage everywhere else
CSV (including inside zip) and JSON get tabular or structured previews in chat — good for column questions and field summaries. XLSX, PDF, and opaque binary bodies are stored; ask tabular questions against CSV or JSON when you can.
Some senders POST a small wrapper with a link to download the real file. MCPBundles follows that link when it is reachable over public HTTPS and stores the fetched content. VPN-only or signed private links will not resolve from our servers — direct POST of the bytes works best.
Size limits and large answers
Incoming payloads are stored up to about 2 MB per delivery. Oversized bodies are rejected so storage stays predictable. Very large upstream exports may need compression or slimmer fields on the sender side.
When an agent pulls a big stored payload back into chat, MCPBundles uses the same large-response download link pattern as other servers: small previews inline, full body via a short-lived link when the answer would overflow the channel.
Teach the agent once per connection
Opaque field names show up in every integration. The connection form accepts agent context notes ("qty is units on hand", "evt is event type") that merge into the bundle skill. Whoever understands the upstream payload documents it once; every later thread inherits the glossary.
What stays upstream
Sending logic, schedules, retries, and authentication with the third-party product stay where they already live. MCPBundles does not replace your form builder, monitoring stack, or data warehouse. It removes the hop between payload arrived and someone asked the agent about it.
Connect Webhook Ingest on MCPBundles. Try: what was in the most recent delivery on this connection? Paste the URL, wait for one send, then ask.