Supersonik MCP Server

Last Updated: 2026-10-06

MCP Server URL: https://api.supersonik.ai/mcp Authentication: OAuth. No API key required.

---

Quick install

Add Supersonik as a remote HTTP server, complete the browser sign-in, and enable its tools in your client. There is no package to install and no API key to create.

ChatGPT

ChatGPT on the web

1. In ChatGPT, open Settings → Security and login and turn on Developer mode.
2. Open ChatGPT Plugins, select +, and create a developer-mode app named Supersonik.
3. Under Connection, enter https://api.supersonik.ai/mcp, then create the connection and complete the Supersonik sign-in.
4. Start a new conversation, select + → Developer mode, and enable Supersonik for the conversation.

Developer mode is available on ChatGPT Pro, Plus, Business, Enterprise, and Education accounts on the web. A workspace administrator may need to allow it.

ChatGPT desktop app

1. Open Settings → MCP servers and select Add server.
2. Name it Supersonik, choose Streamable HTTP, and enter https://api.supersonik.ai/mcp.
3. Save the server, restart the app, then select Authenticate to sign in.

Type /mcp in the composer to view the connected server.

Codex

Run these commands in a terminal:

codex mcp add supersonik --url https://api.supersonik.ai/mcp
codex mcp login supersonik

The second command opens the Supersonik sign-in in your browser. Run codex mcp list to confirm the connection, or use /mcp inside the Codex terminal UI. Codex CLI, the Codex IDE extension, and the ChatGPT desktop app share this MCP configuration on the same computer.

Claude Code

Run these commands to add Supersonik for every project and start the browser sign-in:

claude mcp add --transport http supersonik --scope user https://api.supersonik.ai/mcp
claude mcp login supersonik

The second command opens the Supersonik sign-in in your browser. Run claude mcp list afterward if you want to confirm the server reports Connected.

Claude and Claude Desktop

1. Open Customize → Connectors, select +, then choose Add custom connector.
2. Name it Supersonik and paste https://api.supersonik.ai/mcp as the connector URL.
3. Select Add, then Connect, and sign in to Supersonik.
4. In a conversation, select + → Connectors and enable Supersonik.

The connector is stored on your Claude account, so the same connection is available in Claude on the web and in Claude Desktop. On Team and Enterprise plans, an owner must first add it from Organization settings → Connectors; members can then find it under Customize → Connectors and select Connect.

Cursor

Add the server under Cursor Settings → Tools & MCP, or add it to your global ~/.cursor/mcp.json file so it is available in every project:

{
  "mcpServers": {
    "supersonik": {
      "url": "https://api.supersonik.ai/mcp"
    }
  }
}

Cursor asks you to authenticate with Supersonik when it first connects. Make sure the server and its tools are enabled under Tools & MCP before using it in Agent.

Slackbot

Follow the Slack app installation guide to install Supersonik in your workspace, then connect your account to Slackbot. Your Slack administrator may need to approve the app and its MCP connection.

Once connected, ask Slackbot to list your published demos, create a link with prospect context, or query demo results. Slackbot uses the tools permitted by your Supersonik account. Creating a demo link returns the URL without sending an email or message to the prospect.

For the form inside Slack, use /demo or Supersonik → Home → Create custom demo link. That flow has its own account connection and works independently of Slackbot.

Other MCP clients

Choose your client's option for adding a remote Streamable HTTP server and use this URL:

https://api.supersonik.ai/mcp

Complete the OAuth sign-in when prompted. A compatible client discovers the authentication configuration automatically, so you do not need to provide a client ID, secret, or API key.

Confirm the connection

Ask your assistant:

Who am I in Supersonik, and which organizations can I access?

The assistant should use Supersonik and return your identity and accessible organizations. If it answers without using a Supersonik tool, open the client's tools or connectors menu and confirm the server is connected and enabled for the current conversation.

What you can ask

Once connected, try prompts such as:

• "How many demos did we run last month, and how many did the prospect join?"
• "Show me the demos for anyone at <company domain>."
• "Summarize the transcript of demo <demo id>."
• "List the insights configured for my organization."
• "What insight results do we have for demo <demo id>?"
• "Across recent demos, summarize how our insights are performing."
• "Summarize insight coverage, latest results, and quality."
• "Which published demos can I share? List their names and links."
• "Create a link for demo enterprise-demo for jane@example.com, with context: focus on SSO and onboarding."
• "Create an HTTP tool for this n8n workflow's production webhook."
• "List our tools and show me the definition of our workflow tool."
• "Update this HTTP tool's response template without changing its request."
• "Delete this unused custom HTTP tool from our catalog."
• "Show me fictional call context to design this n8n workflow's request."

Your assistant can read your identity, organizations, demos and their transcripts, configured insights, collected demo results, and your tool catalog. It can also create personalized links for published public demos you can access. Creating a link returns a URL; it does not send an email or Slack message. With tools:write, it can create and update custom HTTP tool definitions. Neither operation calls the tool's URL or attaches it to an agent. Updating configuration declarations can affect existing attachment values, as described below. With tools:delete, it can also delete unused custom HTTP tools. Managing agent attachments is not available through this server. With tools:read, your assistant can also fetch fictional call context to design HTTP requests and test fixtures without reading a real conversation.

When a voice & chat agent hands a conversation over to a demo agent that shares its screen, the demo still has one transcript. Each turn says which agent was in the call (agent_type is voice_chat or screen_sharing), so your assistant can tell where the handoff happened and who said what.

Internal test runs are hidden by default wherever demos are involved, so counts and summaries reflect real prospect activity unless you ask for test runs to be included.

If you can access more than one organization, ask the assistant to list them first, then name the organization it should use for later requests.

Tools

The tools your client will list, and what each one answers. Your assistant picks them on its own; you don't need to name them.

Find published demo experiences

Use list_published_launch_configs to discover the demo experiences available for personalized links. It returns published, public experiences with an active version and a nonempty URL slug in the selected organization. Draft, inactive, testing, private, and deleted experiences are excluded — a testing experience is one your team is trialling against a version of the product tour that has not gone live, and it is never offered for personalized links. Voice & chat experiences, the embedded website widget, are also excluded: they cannot be started from a link. list_demos lists demo sessions; those session IDs cannot be used to create a personalized link.

The tool requires launch_configs:read. It is hidden from discovery without that permission, and direct calls return NotPermitted. The optional operate_as_organization_id selects an organization you have permission to act in; omitted or null means your home organization. An unauthorized organization is rejected with no fallback to your home organization.

Call it with {} for the first page. limit defaults to 20 and accepts 1–100; offset defaults to 0. Results are ordered newest first, with configuration ID as a tie-breaker. The response contains:

• items: each experience's id, name, nullable description, demo_url_slug, and standard url.
• total_count: the number of matching experiences in the organization.
• next_offset: pass this as offset for the next page; null means finished.

Choose an experience from items, then pass either its id as launch_config_id or its demo_url_slug to create_demo_link, together with recipient_email and context. Use the returned personalized URL unchanged. The listing's url is a standard demo link and carries no personalized context. For example, after choosing the returned enterprise-demo slug:

{
  "demo_url_slug": "enterprise-demo",
  "recipient_email": "jane@example.com",
  "context": {"notes": "Explain how SSO works for Jane's onboarding team."}
}

Listing does not create links, start demos, or send messages. Newly published experiences can take a short time to appear. A configuration can change after discovery; link creation checks its availability and your access again.

Inspect and update tools

These tools accept operate_as_organization_id when you have an active grant for another organization. Omit it to use your home organization. An inaccessible organization returns ResourceNotFound; the request does not fall back to your home organization.

Find tools with list_tools. Requires tools:read. Optional limit defaults to 20 and accepts integers from 1 to 100; offset defaults to 0 and accepts integers from 0 to 9223372036854775807. Booleans and numeric strings are rejected. The response contains items and next_offset. Each item has id, official_key, name, display_name, description, and is_official—not request templates, configuration declarations, or attachment values. Pass next_offset as the next request's offset until it is null.

Built-ins appear first, ordered by official_key; your custom tools follow, ordered by name and UUID. Catalog edits between requests can shift page boundaries. A page beyond the end returns an empty items list and next_offset: null. A tool you have just created or updated is available to subsequent catalog reads immediately.

Inspect a definition with get_tool. Requires tools:read. Supply exactly one of tool_id (a custom tool's UUID) or official_key (a built-in's key), using values from list_tools. Built-ins have no UUID. The response has the same full definition fields as create_http_tool, including templates, argument/configuration declarations, and setup guidance. It contains no stored attachment credentials. Missing or inaccessible tools return ResourceNotFound; supplying both selectors or neither returns BadRequest.

Change a custom tool with update_http_tool. Requires tools:write. Supply tool_id and a changes object containing only fields to change. The accepted fields and size limits are those described under Create an HTTP tool. The response is the complete updated definition.

• Omitted fields remain unchanged. An empty changes object is a no-op.
• arguments and config_variables replace their entire lists; [] removes all declarations. Update referencing templates in the same call when needed.
• request_template replaces the entire request object, not individual keys. Include headers and body you want to retain.
• Explicit null clears only setup_instructions or error_template. Other fields cannot be cleared with null and return BadRequest.
• Built-ins cannot be updated. Executable-definition changes are also blocked when a tool is used by a published launch configuration; you can still change its catalog label and setup guidance.
• Changing a configuration variable to secret encrypts existing plaintext attachment values. Removing a secret declaration or making it non-secret discards its stored secret value rather than exposing it as plaintext. You may need to re-enter that value in the app.

For example, replace just the successful-result template:

{
  "tool_id": "00000000-0000-4000-8000-000000000001",
  "changes": {"response_template": "{{response.message}}"}
}

Validation checks the complete resulting definition before applying changes. Invalid declarations or templates return BadRequest; a duplicate or reserved name returns ResourceAlreadyExists. A published-use restriction returns EntityInPublishedLaunchConfigError. Repeating an identical update does not apply an incremental change. Neither reading nor updating a definition tests its endpoint or changes an already-running call. Tools are hidden from discovery when you lack their permission, and direct calls without it return NotPermitted.

Create a personalized demo link

Use create_demo_link to generate the same clean, token-based personalized URL as the existing API. MCP adds the sender email from your authenticated user and uses your current permissions; a Slack installation is not required. The organization-authenticated Client API keeps its existing endpoint, request, response, and context behavior. Use list_published_launch_configs first if you do not know the experience's ID or URL slug.

For example, these are the arguments to create_demo_link:

{
  "demo_url_slug": "enterprise-demo",
  "recipient_email": "jane@example.com",
  "context": {
    "notes": "ABC: Jane wants to evaluate SSO and reduce onboarding time.",
    "presentation_order": ["Onboarding", "SSO"],
    "presentation_instructions": "Present these demos in the listed order."
  }
}

The response contains id, token, and a ready-to-share url, for example:

https://app.supersonik.ai/d/<token>

Share the url as returned. New URLs use a random token without an mcp. prefix. Previously shared /d/mcp.<token> and /d/c/<token> links keep working; you do not need to replace them.

Recipient details and context stay server-side behind the opaque token. Emails are not added to the URL or returned by the public configuration endpoint. The sender comes from your authenticated identity; there is no sender_email argument, and a sender mentioned in context cannot replace that identity.

The configured email form remains available. Each visitor's form email takes precedence over the stored default for that session. This resolved email is used for enrichment and participant attribution. The stored context stays unchanged, so you can reuse one link for several people; conversation memory is kept separate for each recipient. When no form email is supplied, the stored default is used.

The stored context object follows the API's 32 KB serialized-size and five-level nesting limits, including the recipient, authenticated sender, and source metadata. Presentation order and instructions are passed as prompting context; they do not modify the published configuration. If context.recipient_email differs from the tool's recipient_email argument, the argument supplies the default. MCP assigns context.source and context.sender_email; caller-supplied values cannot replace them. The authenticated caller remains the creator.

The tool requires launch_configs:read, just like creating a link in the app. An inaccessible, unpublished, or private demo is rejected. There must be an active published version. An unauthorized requested organization is rejected, with no fallback to your home organization.

Each successful call creates a new link. Reuse the returned URL when sharing the same link again. Creating a link does not send email, post to Slack, start a demo, or invoke an AI model. Your assistant can use a separate email or Slack tool to deliver it when you ask it to. After this tool is deployed, refresh your MCP client's tool list if it still shows the previous catalog.

Create an HTTP tool

Use create_http_tool to turn an existing HTTP endpoint, such as an n8n webhook, into a tool you can configure for demo calls. When you also connect n8n's MCP server, your assistant can create the workflow there and save its HTTP tool here. Use the published workflow's production webhook URL, reachable from Supersonik, not a localhost URL. Creating the catalog entry does not verify that the workflow is active or reachable.

The tool accepts two parameters:

The definition uses the same validation as the app:

URLs are limited to 2,000 characters; request bodies and response/error templates to 8,000 characters each. Argument and configuration names must be unique within their respective lists and use 1–64 lowercase letters, digits, or underscores, starting with a letter.

String arguments may also set format: "utc_timestamp" to normalize timestamp inputs to UTC. An optional argument (required: false) with that format can use derived_from with kind: "clock_offset". Its offset_seconds defaults to 0 and is measured from the invocation time, or from an earlier timestamp argument named by anchor_argument (default null). An anchor must be required or have its own derivation. Optional minimum_offset_seconds and maximum_offset_seconds bound the timestamp relative to the anchor; an input below the minimum is recomputed from the default offset and floor. A positive granularity_seconds rounds platform-chosen values up when that does not exceed the maximum; valid supplied values are not rounded. These three bounds/rounding fields default to null.

Request templates reference declared arguments with {{args.name}} and configuration with {{config.name}}. Use {{context}} or supported nested context paths to explicitly send call context; it is not sent automatically. Context can include personal information and conversation text, so send only what your workflow needs. Requests use substitution only, not Jinja filters or control flow. Supply the body as a string: in JSON templates, quote string arguments and leave object-valued context placeholders unquoted to preserve JSON types.

Response and error templates receive response (parsed JSON, or null when unavailable) and status (the HTTP status, or 0 when no HTTP response exists). They do not receive args, config, or context. Error templates can also handle network or response-processing failures when execution budget remains; if they cannot render, the standard failure result is used.

For example, these are the arguments to create_http_tool:

{
  "definition": {
    "name": "send_workflow_request",
    "display_name": "Send workflow request",
    "description": "Send an action requested during a demo to our integration workflow.",
    "arguments": [
      {"name": "action", "type": "string", "description": "The requested action"}
    ],
    "config_variables": [
      {"name": "api_key", "description": "Webhook API key", "is_secret": true}
    ],
    "request_template": {
      "method": "POST",
      "url": "https://workflows.example.com/webhook/demo-action",
      "headers": {
        "Content-Type": "application/json",
        "Authorization": "Bearer {{config.api_key}}"
      },
      "body": "{\"action\":\"{{args.action}}\",\"demo_id\":{{context.demo.id}},\"recipient\":{{context.recipient}}}"
    },
    "response_template": "{{response.message}}"
  }
}

The response is the saved catalog entry, including its id, metadata, argument/configuration declarations, and request/response/error templates. is_official is false, official_key is null, and setup_stages is empty. Keep the returned ID to identify the tool. Attach it to an agent and supply its configuration separately in the app before using it in demos. This MCP tool has no agent_id or credential-value parameter.

Do not put passwords, API keys, or tokens directly in URLs, headers, bodies, or other definition fields. Definitions are saved and returned to your assistant. Use secret configuration declarations and placeholders instead, then enter the values when configuring the attachment in the app.

An existing or reserved tool name returns ResourceAlreadyExists; it never updates the existing tool. Invalid argument shapes are rejected before creation, and invalid placeholder declarations return BadRequest. Calls without tools:write return NotPermitted. An unavailable or unauthorized requested organization returns ResourceNotFound, not a fallback creation in your home organization. Creating a tool is a write operation, so do not blindly repeat it after an uncertain result.

Delete an HTTP tool

Use delete_http_tool with the custom tool's tool_id UUID. It requires tools:delete; tools:write alone is not sufficient. The optional operate_as_organization_id selects another organization when your grant permits it, just as for the other catalog operations.

Built-ins cannot be deleted: they have an official_key, not a UUID. Deleting a tool that still has an active agent attachment returns BadRequest; detach it separately in the app first. Deletion never detaches an agent or calls the tool's endpoint.

Success returns no structured data and frees the tool's name for reuse. Missing, inaccessible, and already-deleted UUIDs return ResourceNotFound. Repeating the same UUID does not delete a replacement tool created with the old name. Calls without tools:delete return NotPermitted, and the tool is hidden from discovery without that permission. Review the selected tool before deleting it; there is no MCP undo operation.

Get fictional tool context

Call get_tool_sample_context with no required arguments. It requires tools:read. The optional operate_as_organization_id selects the organization whose permission to use, when your grant permits it; it does not personalize the example or read that organization's demos.

You receive the same fictional context used by the editor's testing panel: recipient, sender, enriched_lead, lead, view, transcript, transcript_truncated, demo, now, and launch. Timestamps are based on the current time, so repeated calls need not return identical values. The result contains no real conversation data or credential values.

For an n8n workflow, select only the approved fields you need and use those fictional values to construct the context portion of your example request. Combine it with your explicit input arguments for workflow test fixtures and your handoff. Do not send the whole context just because it is available. Real calls can have null identities, enrichment or views, and missing optional data; test those cases too.

This operation does not save changes, render or validate a template, or execute an HTTP request. A sample or a passing pinned workflow test does not prove webhook authentication or downstream execution works. Calls without tools:read return NotPermitted, and the tool is hidden from discovery without that permission.

Requirements

• A Supersonik account. Sign in with the credentials you use at app.supersonik.ai. The server only returns data your existing permissions allow. Listing published experiences and creating personalized links require launch_configs:read. Catalog listing, inspection and fictional sample context require tools:read; creating and updating HTTP tools require tools:write; deleting them requires tools:delete.
• A client with remote MCP and OAuth support. Some clients require a paid plan, and workspace administrators may need to allow custom connections.

How it works

Supersonik exposes a Model Context Protocol (MCP) server. MCP is an open standard that lets AI assistants and agents connect to external tools and data. The Supersonik server uses the remote Streamable HTTP transport and OAuth, so compatible clients can discover and authenticate the connection without a locally installed package.

Security and data access

• Authentication uses OAuth against Supersonik's identity provider. No API key is required, and your password is never shared with the AI client. The connection holds a token issued to you personally.
• Authorization mirrors the Supersonik app. Every tool call is checked against your permissions and scoped to your organization; the server never exposes another organization's data.
• Writes are explicit. create_demo_link stores personalized context and requires launch_configs:read. create_http_tool and update_http_tool require tools:write; delete_http_tool requires tools:delete. Other tools are read-only. None of these writes invoke an endpoint, send a message, start a demo, or attach a tool to an agent. Updates can replace saved definition fields and reclassify attachment configuration; deletion removes an unused catalog entry. Review these changes before applying them.
• Template data. Definitions are saved in your catalog and returned to the assistant. Keep credentials out of their literal contents; use secret configuration placeholders instead.
• Disconnecting. Remove or disconnect the server in your client's settings at any time to revoke its access.

Personalized link identity

Personalized MCP links store recipient details and user context behind an opaque /d/<token> URL. The server identifies links created through MCP and records the signed-in creator. The sender comes from that authenticated creator, never from an arbitrary address in context. Resolved emails stay server-side and are not returned in public configuration.

The configured email form remains available. A visitor's submitted email overrides the stored default for that session, including enrichment and participant attribution. The reusable link stays unchanged, with conversation memory separated per recipient. Without a submitted form email, the stored default is used.

The organization-authenticated Client API retains its existing endpoint, payload, response, and context behavior. Supplying email keys or source: "mcp" in API context does not enable MCP identity handling, including on the existing user-authenticated API route. Existing generic and Slack links retain their form/query flow.

Troubleshooting

Support

Questions or issues? Contact your Supersonik account team or write to support@supersonik.ai.

Last updated: 2026-09-25.