Skip to main content
The Autoplay MCP server is a single Model Context Protocol endpoint. Any MCP-speaking agent connects to it and pulls what it needs on demand — at the exact moment it needs context to answer — and can launch the user’s next onboarding step as a guided in-app tour. It’s agent-agnostic. Intercom Fin is one client; so is a custom agent, an IDE assistant, or the MCP Inspector. They all use the same URL, the same Bearer token, and the same tools.
⭐ MCP is the integration path. Connect your existing agent to Autoplay over MCP — you don’t build or host an event pipeline, a context store, or a trigger system. If your platform can’t speak MCP but can call an HTTP endpoint, there’s a limited REST API fallback for the activity read only.

​
1. 🔌 Connect to the server

YOUR_MCP_KEY is the mcp_key from your Quickstart product registration. Keep it server-side. Every tool takes a product_id, and auth is checked against it on each call:
  • Invalid or missing token → the call fails with “Invalid or missing API key”.
  • Token valid but scoped to another product → it fails with “API key does not match product_id”. The key’s external_id must equal the product_id you pass, so a key for product A can’t read product B.
The canonical endpoint is https://mcp.autoplay.ai/mcp (no trailing slash). Some MCP clients are strict about trailing slashes — use the bare /mcp form.
Point any MCP client at it with the Streamable HTTP transport and the Bearer header. Exact config keys vary by client, but the three values are always the same — URL, transport, Authorization header:
The server is stateless — each request is self-contained, so your client never has to carry an mcp-session-id.

​
2. 🔑 Satisfy identity

Make your agent send the same user_id that activity is stored under — your activity source’s stable user id (the id you pass to posthog.identify(...), the Amplitude user_id, …). This is the step that most often gets skipped, and it’s why an active user comes back looking idle. See Identity for the full rule and the per-agent mechanisms for passing a verified id.

​
3. 🛠️ Call the tools

Once connected, your agent has the tool surface documented on MCP tools — reading activity and onboarding progress, checking whether it may interrupt, launching tours, and recording confirmed completions.
Start with get_recommendation_context. When the agent is deciding what to recommend next, that one call returns recent activity, onboarding progress, the next step, and the matching tour together — instead of three separate blocking reads. See MCP tools.
Not every product sees every tool. get_live_user_activity is always advertised. The onboarding, tour, and confirmation tools are advertised only once your product’s onboarding is configured with Autoplay — the server never offers a tool it can’t serve. If your client’s tool list shows only get_live_user_activity, onboarding isn’t wired up for that product yet.

​
4. 🤖 Follow the per-agent recipe

Each agent platform has its own way of registering an MCP server and passing a verified user identity. The endpoint, the tools, and the identity rule don’t change — only the wiring does.

Intercom Fin

Connect Fin to this server, plus the Messenger JWT identity verification Fin needs to pass a trusted user_id.

Other agents

Inkeep, Crisp, Plain, Rasa, Tidio and more — same endpoint, same tools, their own identity mechanism.

​
🧪 Test it with the MCP Inspector

The quickest way to confirm the server is reachable and your token works:
Then in the Inspector UI:
  1. Set Transport Type to Streamable HTTP.
  2. Set URL to https://mcp.autoplay.ai/mcp.
  3. Under request headers, add Authorization = Bearer YOUR_MCP_KEY.
  4. Click Connect. The tool list appears.
  5. Call get_live_user_activity with a real product_id and a user_id you’ve identified — you should get the activity envelope back.
The MCP Inspector won’t send the Authorization header unless you add it explicitly — by default MCP clients strip it. If a tool call returns “Invalid or missing API key”, the header isn’t reaching the server.

​
⏳ Before activity appears

The activity tools return something only once Autoplay has recorded activity for that user: your activity source must be wired up and the user must have generated events. With PostHog (the source used in the Quickstart): complete Quickstart Steps 1–3 — the snippet, posthog.identify(...), product registration, and the ingest webhook. Other sources (e.g. Amplitude) follow the same path through their own ingestion.
Identifying a user alone stores nothing. With PostHog, activity is built from $pageview and $autocapture events (page loads, clicks, form submits) — a user who has identified but not yet browsed returns an empty actions array.
Retention — live activity is short-lived memory, not an archive:
  • 4-hour TTL (ACTIVITY_TTL_S = 14400) — older activity expires.
  • 50 actions max per user (ACTIVITY_MAX_EVENTS = 50) — older ones are trimmed.
Onboarding progress is not subject to this TTL — it’s durable state, read through get_onboarding_context and get_recommendation_context.

​
🛟 Something not working?

See Troubleshooting for authentication failures, identity mismatches, empty activity, unavailable onboarding state, and failed tool calls.