Wednesday, 8:40 AM. A customer writes in: "I tried to upgrade twice last night and it just spun." You have Claude Code open, because you were about to do something else. You could open the events feed, filter by level, narrow the window, find the customer, and read three payloads. Instead you type the question into the terminal you are already in.
Did anything fail in checkout last night?
Two checkout-failed events at 23:14 and 23:16, both error, both with a payload reason of
timeout after 30s, both for the same user_id. Then a third from the same customer at 07:52
this morning that succeeded. The answer is in the conversation before you have found the feed.
That is the feature. EventSend now has a read-only MCP server at
https://eventsend.io/mcp. Connect Claude Code, Cursor, Claude Desktop, claude.ai or ChatGPT to
it and ask, in plain language, about your own event history.
The read half of the story
The prompt pages already cover the write half: paste one page of instructions and the agent that built your app instruments it, sending an event on every success and failure path. Those events go to Slack, Discord, Telegram and your phone. They also sit in your organization's history, and until now the only way to read that history was the events page.
Now the same assistant can read it back. Nine tools, all read-only: list_organizations,
search_events, get_event, get_user_timeline, list_event_names, event_stats,
delivery_health, get_usage and describe_setup. You never name them. You ask, and the
assistant picks.
How many
payment-receivedevents this week, and how does that compare to last week?
41 so far this week against 36 in the same seven days before, up 14%. The assistant notes that today's count is still filling, because the response said so.
What did customer cus_9Xk2 do before cancelling?
new-subscriber on August 3. invoice-paid on September 3. export-failed from your own app on
September 9, with timeout after 30s in the payload. payment-failed on September 10 and again
on the 13th. churn on the 16th. Five events from Stripe, one from your app, one timeline,
because they all carried the same user_id.
Are deliveries to Slack failing?
The #payments destination delivered 212 events today and failed 3 attempts, every one of them a
429. The most recent failure was at 14:02, and the log shows the retry thirty seconds later
went through. Nothing is stuck.
How much of the monthly quota is used?
1,830 of 2,500 events, 73%, with nine days left in the period. At the current rate the period ends at about 2,410. You will make it.
Every answer comes from what the tools return, and every response tells the assistant your organization's time zone and the current time, so "last night" and "this week" mean what you mean by them.
Connecting
The endpoint is the same everywhere. Only the credential differs.
claude.ai, ChatGPT and Claude Desktop sign in. Add a custom connector, paste
https://eventsend.io/mcp, and the client sends you to EventSend, where you log in and choose
which of your organizations the connection may read. Nothing is copied or pasted. The connection
sees exactly what you see in the organizations you picked, and loses one if you leave it.
Claude Code and Cursor use an MCP key, created by an owner or admin on the organization's Settings → MCP tab. A key belongs to one organization and can be rotated or revoked at any time, with immediate effect.
claude mcp add --transport http eventsend https://eventsend.io/mcp \
--header "Authorization: Bearer mcp_YOUR_KEY"
For Cursor, add the server to ~/.cursor/mcp.json, or .cursor/mcp.json in a project:
{
"mcpServers": {
"eventsend": {
"url": "https://eventsend.io/mcp",
"headers": {
"Authorization": "Bearer mcp_YOUR_KEY"
}
}
}
}
That is the whole setup. Ask the next question.
Send a user_id and the timeline builds itself
The per-customer question only works if every event about a customer carries the same
identifier. Events now accept an optional user_id: a stable id you choose, such as your account
id or your Stripe customer id, matched exactly. Stripe sources set it for you, to the Stripe
customer id and never the email. If your own app sends the same id, one timeline covers signup,
payment, failure and churn regardless of which system reported each step.
curl -X POST https://eventsend.io/api/events \
-H "Authorization: Bearer $EVENTSEND_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"event": "export-failed",
"message": "Export failed for [email protected]: timeout after 30s",
"level": "error",
"user_id": "cus_9Xk2",
"occurred_at": "2026-09-09T21:40:12Z",
"payload": {"format": "csv", "rows": 48210}
}'
Put the email in payload, where it is data. Put the customer id in user_id, where it is
identity. The other new field, occurred_at, is when the thing actually happened, so a webhook
that arrives late or a backfill lands in the right place on the timeline. Leave it out and the
moment EventSend received the event is used, which is right for almost everything sent live.
What it will not do
- Nothing writes. There is no tool that creates, edits or deletes anything, and no response ever carries a route token, a signing secret, an MCP key or a destination's configuration.
- Raw events are bounded by your plan's retention. Seven days on Free, up to ninety on Scale. Daily counts per event name and per destination are kept for twelve months on every plan, so "how many" reaches back further than "show me".
- Ids match exactly.
cus_9Xk2andCUS_9XK2are two customers. There is no fuzzy matching and no merging you did not ask for. - It is not a funnel tool. It reads events, counts them by day, and reports delivery outcomes. Ask it what happened, not what your conversion rate should be.
The server is on every plan, including Free, and every credential is listed on the organization's MCP tab and in your own connected apps, where it can be revoked with no grace period.
You already have an assistant open. Point it at your events and read the MCP docs for the tool reference, the time-window rules and the limits.