What MCP is
MCP (Model Context Protocol) is an open protocol that gives an AI client access to your data and actions inside another service. Claude Desktop or Cursor connect to a server by address, ask for permission once, and from then on see whatever you allowed — no copying and pasting.
Before the protocol this problem had two poor answers: paste the transcript into a chat window by hand, or write an integration for every tool-and-assistant pair. MCP removes both. The server describes what it can do, the client reads that description, and any pair works.
The current specification revision is 2026-07-28, published on 28 July
2026. It replaced 2025-11-25 and moves the protocol to a stateless core: the
initialize handshake is gone, the version travels on every request,
and server capabilities are fetched with a server/discover call.
Clients stay compatible with earlier revisions, so connecting works regardless
of which revision a server speaks — version negotiation is part of the protocol
itself.
Why meetings need it
Conversations are the least accessible kind of work data. A decision is made out loud, a task is assigned out loud, an argument is made exactly once. A month later it lives in a transcript nobody will open, because opening it means opening twenty.
An assistant with access to your meetings answers questions that otherwise cost an hour of digging: what did we decide about pricing in July, which tasks did I promise and never finish, which objections came up with three customers in a row. The difference is not convenience. It is that these questions stop being too expensive to ask.
How this differs from "read my notes in Claude"
Plenty of tools now offer to connect meetings to Claude. Almost always it means one thing: the assistant gets read access — it searches transcripts, summarises, synthesises. That is useful, and it is half the job.
Whisperer exposes more than reading. The MCP server projects the same tool registry the built-in assistant uses, so Claude or Cursor can actually do what you asked: create a tracker task, put an event on the calendar, write a note, open a ticket.
| Area | Tools | What that means in practice |
|---|---|---|
| Meetings | 14 | Listing, transcript, meeting map, folders, notes, renaming |
| Account | 12 | Hotkeys, interface language, model catalogues |
| Tracker | 8 | Boards, columns, tasks — reading and creating |
| Files | 6 | Listing, reading text, CSV analysis, moving |
| Support | 6 | Tickets: list, thread, create, reply |
| Calendar | 5 | Events: read, create, reschedule |
| Prompts | 4 | Your own assistant templates |
| Leo | 4 | Assistant settings and what it remembers about you |
| Integrations | 3 | What is connected — read only |
| Context | 2 | Personal context: read, append |
| Knowledge base | 1 | Search across your own material |
That is 65 tools: 34 read and 31 write. Sharing one registry with the built-in assistant is deliberate — a second set of tools would inevitably drift from the first, and one day an external client would hold rights the internal one does not.
How it works
MEETING IN WHISPERER BOUNDARY EXTERNAL CLIENT
┌────────────────┐ ┌──────────────────┐ ┌──────────────┐
│ transcript │ │ 1. is the │ │ Claude │
│ notes │─────▶│ meeting │─────▶│ Desktop │
│ action items │ │ flagged? │ │ │
│ meeting map │ │ 2. is that data │ │ Cursor │
└────────────────┘ │ type enabled? │ │ │
│ 3. is the scope │ │ ChatGPT │
┌────────────────┐ │ granted? │ └──────────────┘
│ private │ └──────────────────┘
│ (no-logs) │─────────────╳ never
└────────────────┘
Transport: Streamable HTTP, JSON-RPC 2.0, POST https://whisperer.one/mcp
Auth: OAuth 2.1 + PKCE (S256), or a personal token from the web app
The three locks are sequential and all three must open. First, the meeting itself: only what you flagged leaves. Second, the data type: meetings, notes, transcripts and action items are enabled separately. Third, the scope: the client holds only the rights you explicitly approved on the consent screen.
Connecting
The server address is the same for every client:
https://whisperer.one/mcp. Only the place you paste it differs.
The recommended path. Claude finds where to authorise on its own and registers itself as a client — there is nothing to type but the address.
1. Whisperer → Settings → MCP → "Server" tab. Check which data types are enabled 2. Open the meetings you are willing to expose and turn on "External AI access (MCP)". Off by default on every meeting 3. Claude Desktop → Settings → Connectors → Add custom connector 4. Paste https://whisperer.one/mcp and name the connector 5. A browser opens with the Whisperer consent screen. Read the list of rights and approve — the connector appears in your chats
The consent screen runs on your Whisperer account: if you are signed out, a normal sign-in comes first. Approved clients are remembered by name, so the same client is not asked twice — and access can be revoked from the same section of the web app.
Cursor reads its configuration from a file. Globally at
~/.cursor/mcp.json, or per project at .cursor/mcp.json
in the project root.
{
"mcpServers": {
"whisperer": {
"url": "https://whisperer.one/mcp"
}
}
}
Save the file and open Settings → Tools & MCP. Cursor sees the server, works out that authorisation is required and opens a browser — the same consent screen follows. Cursor stores the token itself; there are no secrets in the config file, and there should not be.
The fallback for clients that cannot do OAuth, and for scripts. The token is static, so treat it exactly like a password.
1. Settings → MCP → "Server" tab → issue a token 2. The raw token is shown ONCE. After that the web app shows only the last four characters and a re-issue button 3. The client sends it as a header: Authorization: Bearer whmcp_…
The difference from OAuth is not cosmetic. A token issued through consent carries scopes and a lifetime — one hour, renewed with a refresh token. A personal token lives until you revoke it and works under its own, older access model for meetings. If the client can do OAuth, choose OAuth.
What the external client sees, and what stays inside
This is the central table of the article. Everything in it is code behaviour, not intent.
| Data or action | Leaves | Condition |
|---|---|---|
| A meeting flagged "External AI access" | Yes | Flagged per meeting, off by default |
| An unflagged meeting | No | Invisible in listings and by direct address alike |
| A private meeting (no-logs mode) | Never | Excluded at the query level; it cannot even be flagged |
| Transcript, notes, action items | Per toggle | Four data types enabled separately; action items off by default |
| Other people's meetings | No | A token belongs to one person; every query is scoped to the owner |
| Deleting anything | Never | Irreversible operations are not projected — not meetings, files or tasks |
| Sending email or chat messages | Never | See below: that consent was given to us, not through us |
| Scheduled errands | Never | Neither set nor cancelled: they fire when the client is long gone |
| Tools that accept keys and tokens | Never | Otherwise MCP would become a way to inject secrets into your integrations |
| Overwriting personal context, erasing memory | Never | Appending to context is allowed; replacing or wiping it is not |
"I connected my email to Whisperer, so let Claude send email through Whisperer too"
Actions inside your external services — email, chat, third-party trackers — are never projected, under any scope
You granted email access to us — a specific service, in a specific conversation, with a scope you understood. Projecting those tools into MCP would pass that same consent further down the chain: any external client connected to our server would gain the right to send mail as you. You never agreed to that and, more importantly, you would not see it happen — a sent email cannot be recalled. So the boundary sits here, not on a confirmation dialog.
How permissions are built
A scope looks like whisperer:meetings.read — a domain and a kind
of access. There are eleven domains and twenty scopes. There is no
*, all or full-access scope: on a
consent screen a person has to understand what they are allowing, and "full
access" does not tell them.
Rights and plan are separate things, and both must line up. The scope says what the client is permitted to do; the plan is checked independently at execution time. The MCP server requires a paid subscription — an unpaid account gets an honest refusal rather than an empty list.
Three more things that are rarely documented, and that decide how safe a connection actually is:
The registry of approved clients is kept per user. Without it, a static client identifier combined with an already-open session would let someone else's application slip past the consent screen — the classic confused-deputy attack.
The redirect address is compared by exact string equality. No prefixes, no patterns: prefix matching is a well-known way to divert an authorisation code to someone else's address.
Your token is never forwarded. We accept only our own tokens and never pass a client's token into an external API — the specification calls this explicitly forbidden.
What to ask, and what to delegate
The difference between "connected" and "using it" is whether you start asking questions you did not ask before. These are the ones worth the setup.
Search and synthesis
- "Find every meeting where we discussed price and list what we decided" — instead of opening twenty transcripts.
- "Which objections repeated across customers in July?" — a pattern only visible at volume, and impossible to assemble by hand.
- "What did I promise and never mark as done?" — action items live in the meeting map as their own nodes, and the assistant checks them against status.
Working with decisions
- "When did we decide against this option, and on what grounds?" — the question transcripts are kept for in the first place.
- "Draft a spec from the project meetings" — Claude reads the shared meetings and writes; in Cursor the same context sits next to the code.
Actions
- "Create tracker tasks from this meeting" — the assistant creates them itself. These are write tools, not advice to go and write them.
- "Schedule the follow-up for next week" — the event appears on the calendar.
- "Save the conclusion to the knowledge base as a note" — and search finds it later.
Limits
Five things better said now than discovered later.
Only flagged meetings leave. That is protection, but it is also work: connecting a client does not hand it your archive. The flag is set per meeting.
The server advertises revisions 2025-11-25 and 2025-06-18, while the
current one is 2026-07-28. Parts of the new revision
(server/discover and its error codes) already respond, but
advertising the newer revision is behind a separate setting pending a review
against the final text. Connecting is unaffected: clients negotiate a version and
settle on a shared one.
Rate limit is 60 requests per minute per token. Invisible in a conversation with an assistant, noticeable when sweeping an archive — which is the point.
Listings are paginated at 100 entries. The client pages through them with a cursor; returning an entire archive in one response is disallowed by the specification and by common sense.
Writes made by an external client are recorded in the audit log. Reads are not: there are far too many, and a line per listing would bury what matters. Changes to data are always visible.
Checklist before connecting
Frequently asked questions
Will Claude get access to all my meetings?
No. Only to those where you turned on "External AI access (MCP)". No meeting is flagged by default, and flagging happens one at a time. Meetings in no-logs mode are excluded entirely — they cannot be flagged at all.
How is MCP different from a SKILL.md skill?
A skill supplies method, MCP supplies access. A skill describes how to review a meeting; MCP brings the meeting itself and lets the assistant act. They complement each other — worked through in the article on skills without a terminal.
Is a subscription required?
Yes, the MCP server requires a paid plan. Revoking access already granted always stays available, though — locking someone in with a consent they cannot withdraw would be wrong.
Can I connect several clients?
Yes. Claude Desktop, Cursor and others connect independently, each with its own consent and its own set of rights. Revoking one leaves the rest untouched.
What happens when I revoke access?
The client stops receiving data immediately: the token is checked on every request, and a revoked one fails rather than degrades. Whatever the client already received stays with it — as with any downloaded file.
Can Whisperer itself connect to external MCP servers?
Yes, it works in both directions: the same settings section has a client tab where external servers are connected, and their tools become available to the built-in assistant.
Does this work with ChatGPT and other clients?
Yes, provided the client speaks MCP over HTTP and supports OAuth discovery — the server address is identical. That is the point of an open protocol: we keep no allowlist of applications, and the boundary is set by your flags and scopes.
Where to start
The fastest check takes five minutes: flag one meeting, connect Claude Desktop and ask it about that meeting. If the answer rests on what was actually said, the chain works — and the only remaining question is how many meetings you are willing to expose.
MCP settings live in the web app under My account → MCP. What connects in the other direction is covered in the integrations reference, and the mode where a conversation is never stored anywhere is described under no-logs.