Ask Claude, ChatGPT, or Cursor about your meetings with Assistly's MCP server
By The Assistly team ·
Your meeting history has always been searchable inside Assistly. The problem is that Assistly usually isn't the app you're working in. You're drafting the follow-up in Claude, writing the ticket in Cursor, or pulling the quarterly summary together in ChatGPT, and the thing you need is a sentence somebody said on a call three weeks ago.
So we built an MCP server. Point any AI tool at one URL and it can read your own meetings: search them, read the recaps, pull the transcript, and round up the action items. You ask in plain words, in whatever you're already using.
One meeting, end to end
Here's how it played out on a real afternoon, during a bug bash. That is the whole team on one call working down a list of things that need fixing.
During the call. Ninety minutes, five people. Assistly is running, filed
under that product's project. Half an hour in, someone asks why a piece of the
system was built to behave the way it does, and nobody on the call was part of
that decision. The answer is already on screen, pulled from a design session six
weeks earlier and cited back to it, while the question is still open. Nobody
opened a doc, nobody said "let me dig that up and get back to you," and the
meeting didn't stop. That is Assistly searching the project's own history
mid-answer, using the same retrieval the MCP server later exposes as
ask_meetings.
The call ends. Assistly writes the recap: what was decided, and each item to fix as an action item, with an owner against it where the call made one clear.
Then the work. Over in Claude Code:
Pull up today's call from Assistly and start on the items assigned to me.
It calls search_meetings to find the session and get_meeting for the recap
and the action items. Where a one-line action item isn't enough to act on, it
calls get_meeting_transcript for what was said about that specific item. Now
it has the list, the reasoning behind each decision, and the constraint
somebody mentioned out loud that never made it into a ticket. It starts doing
the work.
Nothing in that sequence involved transcribing by hand, pasting a wall of transcript into a chat window, or writing the meeting up before the work could begin. The meeting was the input.
None of that is specific to engineering. Swap the bug list for a client call and the same three steps apply: the answer arrives while you're still on the call, the recap gets written for you, and whatever you work in afterwards can read it.
Other things people ask it
Drafting a follow-up. "Write the recap email for this morning's Acme call, and include what we promised on timelines."
Picking up a thread. "When did we first talk about the migration, and what changed since?" That spans four calls across two months, and the words in the question don't match the words in the meeting, which is what semantic recall is for.
Answering for yourself. "What have I committed to and not done yet?"
Prepping the next one. "Pull every objection from my last five sales calls."
Why MCP instead of a per-app integration
The Model Context Protocol is the standard AI tools now use to reach outside data. Building on it means we don't ship an Assistly plugin for Claude, then another for ChatGPT, then wait to support whatever comes next. The same server works with every client that speaks the protocol, including ones that don't exist yet.
It also means setup is one URL:
https://api.tryassistly.com/mcp
No API key, no client ID, no secret to paste into a config file and rotate later. Your client registers itself, opens a browser, and you sign in to Assistly and click Allow. That's the whole setup. In Claude Code it's one line:
claude mcp add --transport http assistly https://api.tryassistly.com/mcp
The setup page has the exact steps for Claude, Claude Code, ChatGPT, Cursor, and Codex. Pick your app and follow three steps.
What a connected app can and can't do
This is worth being precise about, because you're granting an outside tool access to what was said in your meetings.
It can read. It can search across transcripts, recaps, and the questions you asked your assistant mid-call. It can browse your meetings by date or by project. It can open a single call's recap (summary, key points, participants) or its full transcript with speakers named, and pull action items across a stretch of calls.
It can't write. There is no tool to start a session, edit a recap, delete a meeting, or change anything at all. The server is read-only by construction: the write tools don't exist.
It only sees your account. A connection is tied to the sign-in you approved. It can't reach another user's meetings, and it can't be pointed at one by asking nicely.
You can cut it off. Every connected app is listed under Account → Connected apps with a Disconnect button. Access stops immediately rather than at the end of a token's lifetime.
This is the other direction from Integrations
Assistly has had MCP support in Settings for a while, and the two are easy to mix up. Integrations is you giving Assistly extra tools (a web search server, your company's data source, Notion, Linear) so it can use them while answering you on a call. This is the reverse: you giving another assistant read access to your Assistly meetings.
You can run both. They don't interact, and neither one is required for the other.
Getting started
If you already use Assistly, the server is live now. Pick your app on the setup page and you'll be connected before your next call.
If you don't yet: Assistly is a live meeting assistant for macOS and Windows. No bot joins your calls. It works from your computer's audio, tracks every speaker, answers questions in a private overlay while you're still on the call, and writes the recap after. The meetings it records are what the MCP server then lets every other tool you use read.