What's inside Pricing FAQ Blog Documentation Sign in

Cursor can read the call the decision came from

Code carries the decision but not the reason. The reason was spoken on a call and then evaporated. One line in the MCP config and the editor's assistant can look up why the architecture is what it is before it suggests changing it.

Config file · consent per area · paid plans

Add to the MCP config
{
  "mcpServers": {
    "whisperer": { "url": "https://whisperer.one/mcp" }
  }
}

The gap

The commit message was never the whole story

Six months later the question is not what the code does — that is readable — but why it does it that way, when the obvious approach was rejected, and by whom. That conversation happened on a call, and unless somebody wrote it up, it is gone.

An editor assistant with access to those calls can answer it in place, which is a different thing from you switching to another tool to go looking.

Without it The assistant guesses
  • Reads the code and infers intent from shape
  • Suggests the textbook approach that was already rejected
  • Has no idea a constraint came from the client, not from you
  • You go looking through chat history to explain it back
With it The assistant looks
  • Searches the meetings you shared for the decision
  • Quotes the moment and the reason given at the time
  • Knows which constraints are external and non-negotiable
  • You stay in the editor

Setup

Config file, not a connector screen

Cursor and similar editors read servers from configuration rather than offering an interface for them. The address is the same one every client uses.

  1. Add the server

    Put the JSON above into the MCP configuration your editor reads, then restart it so the server is picked up.

  2. Approve the areas

    The first connection opens Whisperer in the browser with the list of areas requested. For an editor, meetings and knowledge base are usually all it needs.

  3. Share the right meetings

    Architecture reviews and planning calls. Sharing the whole archive with an editor buys you nothing and widens the blast radius for no reason.

Limits

What it will not do inside your repository

  1. First Whisperer does not touch your code

    The connection runs one way: the editor reads meetings from Whisperer. Whisperer has no view of your repository, your branches or your files on disk.

  2. Second Only calls that Whisperer heard

    An architecture decision made on a call you did not run Whisperer on does not exist as far as MCP is concerned. There is no way to import it afterwards from a recording.

Questions

Cursor and MCP questions

Can Cursor search my meeting knowledge?

Yes — the meetings you shared, and their transcripts, within the areas you approved. That is usually enough to answer why a decision was taken.

Does Whisperer see my code?

No. There is no repository access in either direction. The editor reads from Whisperer; Whisperer reads nothing from the editor.

Will it work in other editors?

Any MCP-capable client that reads a config file takes the same JSON. The server does not care which editor is on the other end.

Should I share every meeting with it?

No. Share the technical calls. An editor has no use for a pricing negotiation, and a narrower grant is easier to reason about later.

Can it create tasks from what it finds?

If you approved the tasks area, yes — it can create and update cards. Deletion is not available to any external client under any approval.

Share the last architecture call

Then ask the editor why the current approach was chosen. If the answer quotes the call, the loop between deciding and building is closed.