Get Live User Activity), and a verified identity so Fin asks for the right user.
🎬 Watch the walkthrough
Prefer to watch first? This short Loom walks through the entire setup end to end — adding the MCP server, the tool, identity, and testing the full loop.Prerequisite: Intercom’s MCP connectors require a US-hosted Intercom workspace.
🔌 Add the Autoplay MCP server
In Intercom: Settings → Integrations → Data connectors. Click the Custom MCP tile (or New → Custom MCP) and enter:- Name:
Autoplay live activity - URL:
https://event-connector-luda.onrender.com/mcp
🧰 Add the Get Live User Activity tool
Click + New under the Autoplay live activity server. In the Add Autoplay live activity connectors modal, check Get Live User Activity and click Add connectors. The tool is added and the count updates to “(1)”.📝 Open the tool and edit it
Click the Get Live User Activity tool in the list to open it (it opens in Draft). Click Edit to configure it. The tool opens with tabs across the top — API (the endpoint, its inputs, and authentication) and Fin (the prompt that tells Fin when to use the tool). Set up the API tab first (inputs, then authentication), then the Fin tab (the prompt).🎛️ Configure the data inputs (on the API tab)
On the API tab, the tool has three inputs — product_id, user_id, limit. Set each:- product_id → set Data source to Custom value and enter your product id (the same one from your Autoplay SDK setup). Also set the Fallback value to that same product id — so the connector always receives it even if the custom value is ever missing.
- user_id → choose Use an attribute and select the User ID people attribute. This is the verified id from the Messenger JWT (set up under Verify identity with a Messenger JWT below) — it must equal the stable user id your activity source identifies the user with (e.g. the
posthog.identify(...)id, or the Amplitudeuser_id). - limit → optional; leave as Let Fin decide (or ignore it).
🔑 Add the authentication token (on the API tab)
Still on the API tab, find the Authentication section. The tool needs your Unkey token, so click New token (Authentication tokens → Custom) and fill in:- Type: Text
- Token value:
YOUR_UNKEY_TOKEN - Token prefix:
Bearer - Key for request header:
Authorization
The Token prefix field is why you do not type
Bearer into the token value — Intercom prepends the prefix for you. The final header sent is Authorization: Bearer YOUR_UNKEY_TOKEN. The token’s external_id must equal your product_id, or calls return 403.💬 Set the Fin prompt (on the Fin tab)
Now switch to the Fin tab (next to API at the top of the tool). This is where you tell Fin when to use the tool — the field that actually drives Fin’s decision to call it. (The API tab also has a technical description, but the Fin tab’s prompt is the one that matters here.) Replace the default with a clear, Fin-facing trigger description. Recommended:🔐 Verify identity with a Messenger JWT
What this is, in plain terms: Fin should only fetch the logged-in user’s activity, so Intercom needs proof of who that user is. A Messenger JWT is a short, signed token your app creates that tells Intercom “this visitor is userX.” You sign it on your server (using a secret from Intercom), then hand it to the Intercom Messenger in your frontend — the same place you already boot Intercom today.
The user_id you put in that token must equal the id activity is stored under — the stable user id your activity source identifies the user with (e.g. the one you pass to posthog.identify(...), or the Amplitude user_id). That match is the whole point (see Identity).
How the pieces fit: your frontend asks your server for a token → your server signs it with the Intercom secret → your frontend hands it to Intercom on boot → Intercom trusts the
user_id and passes it to Fin.1. Get your Unified Secret — in Intercom
Settings → Channels → Messenger → Security. Copy the secret used for identity verification.2. Sign the token — on your backend
This runs in your server code (where the secret is safe). Add an endpoint your frontend can call to get a token for the currently logged-in user. Node/Express is shown, but any backend works — only the claims (user_id, email, exp) and the HS256 signature matter:
3. Boot the Messenger with the token — in your frontend
Wherever you already initialize the Intercom Messenger (your app’s frontend, after the user logs in), fetch the token from the endpoint above and pass it as the sole identity source:4. Enforce Messenger Security — in Intercom
Back in Settings → Channels → Messenger → Security, turn on enforcement for the web Messenger. Enforcement is what makes Intercom trust and forward the verified identity to Fin — do this only after step 3 works and your tokens decode correctly.🧪 Test the connection
On the tool’s Test tab, set test values: product_id (your product) and user_id (a real user you’ve identified and browsed as). Run the live test — you want a 200 with a populatedactions array.
- 401 → the auth token isn’t selected/configured — revisit Add the authentication token above.
- 200 with empty
actions→ identity is fine but that user has no recent activity yet (browse as them first).
🚀 Set live
Click Set live. The tool flips from Draft to Live and Fin will call it in real conversations.On the Fin tab, ensure “Enable Fin to use this connector directly” is checked so Fin triggers it automatically based on the description.
✅ Test the full loop
- Log in to your app as a test user (fires your activity source’s identify — e.g.
posthog.identify(...)— with that user’s stable id). - Click around — visit a couple of pages, click a button, submit a form.
- Open the Messenger as that same logged-in user (the JWT boots with the matching
user_id). - Ask Fin: “What have I been doing in the app recently?”
- Fin calls Get Live User Activity and answers with what you actually just did.
“No recent activity” = identity mismatch. Confirm the same value in all three:
- the id your activity source identifies the user with (e.g.
posthog.identify), - the
user_idclaim in the Messenger JWT, - the User ID attribute you bound on the API tab.