Carillon docsMCP server
Connect an agent, configure an app, send to a test device, and read its delivery trace.
Set up with your agent
Copy a prompt with the quickstart, SDK guides and MCP connection. Sign in or create your account when the agent opens the browser.
Copy setup promptRead the prompt
Help me send my first mobile push with Carillon in this project.
Read https://app.carillon.dev/docs/llms.txt, then https://app.carillon.dev/docs/quickstart and the SDK guide matching this codebase:
React Native: https://app.carillon.dev/docs/sdks/react-native
Swift: https://app.carillon.dev/docs/sdks/swift
Kotlin: https://app.carillon.dev/docs/sdks/kotlin
Connect the hosted MCP at https://app.carillon.dev/mcp using OAuth. Open the browser so I can sign in or create an account; never ask for my password.
List my organizations and select the appropriate workspace.
Reuse a matching app or create one after checking the existing apps.
Inspect the code and use the installed SDK API. Get an active mobile key with key_list. Never put a secret key in the mobile app.
Check provider credentials and guide me through any Apple/Firebase steps or device actions you cannot perform. Keep credential files and secrets out of chat and version control.
Configure the SDK, native capabilities and notification permission, then rebuild. Verify the device registration, send one notification only to my chosen test device, and inspect its trace. A provider acceptance is not proof of display on the phone. Report what was verified and what still needs my action.
Read the current MCP tool list; use the documented API or dashboard when a required action is not available as a tool.Connect an HTTP MCP client to:
https://app.carillon.dev/mcpFor Claude Code:
claude mcp add --transport http carillon https://app.carillon.dev/mcpSign in or create an account through the browser when prompted. Signup creates a workspace and resumes the MCP authorization flow. The client receives an OAuth access token with your organization memberships. Access tokens last one hour; refresh tokens last one week.
Use device_list to verify registration, then notification_send_test to send one real notification to a device you select. Read its result with message_trace. For backend integration and campaigns, use a secret key with POST /v1/messages.
The tools
Start with organization_list, then app_list. Pass the returned organization and app IDs
explicitly to subsequent tools.
| Tool | Arguments | Reads only | Destructive |
|---|---|---|---|
device_list | app_id, cursor? | Yes | No |
message_trace | app_id, message_id | Yes | No |
notification_send_test | app_id, device_id, title, body?, confirm: true | No | No |
organization_list | none | Yes | No |
app_list | organization_id | Yes | No |
app_create | organization_id, name | No | No |
credential_list | app_id | Yes | No |
credential_upload | app_id, provider, key_id, team_id?, bundle_id?, material | No | No |
key_list | app_id | Yes | No |
key_create | app_id, type, label? | No | No |
key_revoke | app_id, key_id, confirm | No | Yes |
audience_list | app_id | Yes | No |
audience_preview | app_id, definition | Yes | No |
audience_create | app_id, name, definition | No | No |
audience_delete | app_id, audience_id, confirm | No | Yes |
notification_send_test requires your confirmation of the device and content. It sends in live mode, not simulated test mode, and must not be retried automatically. It is offered when sending is configured.
The credential pair is only offered where key management is configured, so a tool that would have to refuse the call is not listed.
Permissions and confirmation
Destructive tools require an explicit confirmation. key_revoke and audience_delete take a
confirm argument and refuse without it, which is where the agent asks you first. Revoking a mobile
key breaks device registration in every installed copy of an app until users take an update.
A secret key is shown once, to the agent too. key_create returns its value in that one answer
and nowhere else, exactly as the dashboard does. A mobile key stays readable, as it does everywhere
else.
An app or organization outside your memberships answers "no such", never "forbidden". The two cases are not distinguishable from the answer.
A refused tool call includes an error and the next action. For example:
No such resource. No app with that id, or you are not a member of the
organization owning it. Call app_list for an organization you belong to.