Dashboard MCP
The Dashboard MCP server connects your coding agent (Claude Code, Cursor, VSCode, Codex, and others) to your Svix environment, so it can work on your webhooks from your editor. It covers two jobs:
- Webhooks you receive through Svix Ingest: the agent can create a source for a provider (Stripe, GitHub, …), point it at your handler, fetch the signing secret your handler needs, and debug failed deliveries against the real payloads.
- Webhooks you send to your customers: the agent can look up any of your applications, check endpoint health, read the exact response a customer’s server returned, and replay what they missed.
This is a different server from the App Portal MCP. The App Portal MCP is for your customers, and is scoped to a single application. The Dashboard MCP is for you, and is scoped to a whole environment.
Connecting your agent
Point your agent at the Dashboard MCP server for your region:
https://mcp.<region>.svix.com/dashboardWhere <region> is the region your account is in (us, eu, ca, or au). For example, in Claude Code:
claude mcp add --transport http svix-dashboard https://mcp.us.svix.com/dashboardThe first time the agent connects, it opens the Svix Dashboard in your browser. Pick the environment the agent should have access to and approve the request. The agent then keeps itself signed in on its own, so there’s no token to copy or renew.
This requires an agent that supports MCP’s OAuth authorization flow, which most current agents do.
To connect the same agent to several environments, add the server once per environment with a distinct URL by appending any unique segment, for example the environment ID: https://mcp.us.svix.com/dashboard/<env_id>. The segment only keeps the connections apart; the environment itself is the one you pick in the browser.
What the agent can do
Every tool names the source or application it acts on, so the agent first finds it (list_sources, list_applications) and then drills in. IDs can be raw Svix IDs (src_..., app_..., ep_..., msg_...) or your own UIDs.
Ingest sources
A source is one provider you receive webhooks from. It has an ingest URL you register with that provider, and Svix verifies what the provider sends before forwarding it to the source’s ingest endpoints: your own handlers.
| Tool | Purpose |
|---|---|
list_sources | Your environment’s ingest sources. |
get_source | One source: its type, provider configuration, and the ingest URL to register. |
create_source | Create a source for a provider and get its ingest URL. |
update_source | Replace a source’s configuration (e.g. rotate the provider’s signing secret). |
delete_source | Delete a source, its endpoints, and its ingest URL. |
rotate_source_token | Get a new ingest URL. The old one keeps working for 48 hours. |
get_source_portal_link | A link into the Ingest portal UI for a source. |
Ingest endpoints
| Tool | Purpose |
|---|---|
list_ingest_endpoints | The handler URLs a source forwards to. |
get_ingest_endpoint | One endpoint’s URL, enabled state, rate limit, and metadata. |
create_ingest_endpoint | Point a source at a handler URL. |
update_ingest_endpoint | Repoint or disable an endpoint. |
delete_ingest_endpoint | Stop forwarding to an endpoint. |
get_ingest_endpoint_secret | The whsec_... secret your handler verifies signatures with. |
rotate_ingest_endpoint_secret | Get a new signing secret. The old one stays valid for 24 hours. |
get_ingest_endpoint_headers | Custom headers sent with every delivery. |
update_ingest_endpoint_headers | Replace those headers. |
get_ingest_endpoint_transformation | The transformation applied before a webhook reaches your handler. |
update_ingest_endpoint_transformation | Set the transformation’s code and/or toggle it on or off. |
Debugging ingest deliveries
These take the source_id they apply to.
| Tool | Purpose |
|---|---|
list_messages | Webhooks the source received from the provider. |
get_message | One received webhook: the exact payload your handler has to parse. |
get_endpoint_stats | Delivery health of an ingest endpoint over a time window. |
list_attempts_by_endpoint | Delivery attempts to a handler (e.g. only failures), with the response it returned. |
list_attempts_by_message | Every endpoint one received webhook was attempted against. |
get_attempt | One attempt in full, including the status code and body your handler returned. |
resend_message | Replay one webhook to a handler, re-signed so it passes verification. |
recover_endpoint | Replay everything that failed to reach a handler since a given date. |
Applications
For the webhooks you send. These take the app_id (ID or UID) of any application in the environment.
| Tool | Purpose |
|---|---|
list_applications | Your applications, searchable by name, UID, or metadata value. |
get_application | One application (name, UID, metadata). |
get_app_stats | Application-wide attempt totals and error rate, per event type. |
list_app_endpoints | The application’s endpoints, optionally with each one’s error rate. |
get_app_endpoint | Full configuration of one endpoint. |
get_app_endpoint_stats | Success / fail / pending / sending counts over a time window. |
get_app_transformation | An endpoint’s transformation code, enabled state, and variables. |
list_app_messages | Messages sent to the application (filter by event type, channel, time). |
get_app_message | A message’s event type, channels, and JSON payload. |
list_app_attempts_by_endpoint | Delivery attempts for an endpoint (e.g. only failures), with response bodies. |
list_app_attempts_by_message | Every endpoint a single message was attempted against, and how each responded. |
get_app_attempt | One attempt in full, including the response status code and body. |
resend_app_message | Resend one message to an endpoint. |
recover_app_endpoint | Replay all failed messages for an endpoint since a given date. |
The create_*, update_*, delete_*, rotate_*, resend_*, and recover_* tools change live configuration or perform real deliveries. The server instructs agents to only use them when you explicitly ask, and most agents ask for confirmation before running a tool, but review those calls before approving them.
Some things this makes easy:
- “Set up Stripe webhooks for my app.”: the agent creates a Stripe source, gives you the ingest URL to register in Stripe, points the source at your handler, and fetches the signing secret your handler verifies with.
- “Write a handler for
invoice.paid.”: the agent reads realinvoice.paidwebhooks the source received, so the handler is written against the actual payload. - “Why is my GitHub handler failing?”: the agent checks the endpoint’s stats, then the failed attempts and the exact response your handler returned. Once it’s fixed, it replays what failed.
- “Acme says they’re not getting our webhooks.”: the agent finds Acme’s application, checks its endpoints’ error rates, and reads the responses Acme’s server returned.
Access and security
The server is scoped to a single environment: an agent can see and change that environment’s ingest sources and applications, and nothing outside it. Access is tied to the user who approved it, so an agent can’t do anything that user couldn’t do in the dashboard, and if the user loses access to the environment, so does the agent.
The agents you’ve authorized are listed under Connected agents in Settings -> Dashboard MCP. Their access lasts 30 days from when you approve it, after which you sign in again. Revoking one from its menu -> Revoke stops it from refreshing its access immediately; the short-lived credential it already holds keeps working until it expires, which is at most an hour.
Message payloads the agent reads are sent to whichever model provider backs your coding agent, so treat this the same way you’d treat pasting a payload into that tool.
The Dashboard MCP is available on Svix Cloud only.