AI assistant integration (MCP)
How Overshow will expose your captured history to AI assistants like Claude, Cursor, and local LLMs through the Model Context Protocol, with privacy-first defaults.
Last updated: 18 April 2026
Availability. This integration is a developer-only capability available in local development builds. Shipping macOS releases do not include it. This page describes the planned integration shape for developer builds and future opt-in release contexts.
What MCP is, in one paragraph
Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools and data. An assistant connects to Overshow and is offered a set of tools it can call to retrieve your local context. Think of it as a well-defined bridge between a chat interface and a data source, replacing ad-hoc copy-paste with a consistent, auditable contract.
For Overshow, this means an assistant could search your captures, answer questions grounded in your own history, and review meetings, all without Overshow itself needing a chat UI for that particular assistant.
Compared with pasting large raw exports into a chat, tools return bounded, filterable snippets (time range, app, speaker, meeting, and so on), so assistants spend fewer tokens on noise and more on answering your question.
What MCP lets you do
| You want to | The assistant can |
|---|---|
| Recall what you were working on last Tuesday | Search your captures with time and app filters and surface the relevant moments |
| Get a meeting recap without opening the desktop app | List recent meetings, fetch the summary, and return it inline |
| Pull context into an IDE session | Fetch recent captures matching a topic and cite the sources |
The shared thread: you stay in the assistant you already use, and Overshow becomes one of the grounded sources it can cite.
MCP is most useful when your assistant is allowed to cite the tool results back to you. You can then verify the underlying captures in the desktop app before acting on anything, just like with Ask.
What the tools cover
The integration offers a fixed, documented set of tools. Assistants choose which to call; they cannot execute arbitrary code against your data. Everything runs against your local database through Overshow on your machine. At a high level the tools let an assistant:
- Search your captures by keyword, meaning, or both, and scope to a person, organisation, or project.
- Review meetings, including the decrypted summary for a specific meeting.
- Look up people, organisations, and projects inferred from your history.
- Read stored action items and decisions you have captured.
- Inspect capture status to explain whether capture is running or paused.
Most tools are read-only. A few can update local metadata. The integration cannot create arbitrary records or change your capture settings.
Privacy model
The integration is designed around a simple rule: where your query and results end up depends on which assistant you connect.
| Assistant type | What leaves your machine |
|---|---|
| Local LLM (built-in Overshow AI, Jan.ai, LM Studio) | Nothing. Queries, tool calls, and responses stay on device. |
| Cloud assistant (Claude, Cursor, others) | Query text and any tool results returned to the assistant are sent to that provider's servers. |
Because tool results can include verbatim OCR text, transcripts, and UI snapshots, sending them to a cloud assistant effectively ships that content to a third party. Overshow therefore treats cloud assistants as an explicit opt-in:
- Setup favours local LLM clients by default.
- Connecting Claude, Cursor, or similar cloud clients requires an explicit opt-in.
- That choice is auditable in the desktop app so you can see what was enabled and when.
If you connect a cloud assistant, treat every captured moment as potentially leaving your device the first time the assistant calls a tool. Use window exclusions and capture pauses before you would normally rely on them, not after.
Separately, the server runs on localhost only. It is not exposed to the network. An assistant has to be running on the same machine (or explicitly tunnelled by you) to call it.
How it fits into your machine
You install Overshow as usual. When the integration is enabled in a developer build, an assistant connects to Overshow on demand and reads only what each tool call returns. There is no extra background service to keep healthy beyond the desktop app you already run.
Setup, at launch
The exact steps will be confirmed when the integration is ready more widely. The intended shape is:
| Step | What you will do |
|---|---|
| 1. Install Overshow | Install the desktop app and complete onboarding as normal. |
| 2. Connect an assistant | A simple setup step points a supported assistant at Overshow. |
| 3. Confirm cloud consent | Cloud assistants only connect when you explicitly opt in. |
| 4. Restart the assistant | Most assistants read their configuration at startup. |
| 5. Ask your first question | The assistant can now draw on your captures and cite them in its replies. |
Local-only setups need no extra consent. Cloud setups require the opt-in described above.
What to expect in practice
A few realistic scenarios, assuming the integration is enabled and connected:
| Scenario | What happens |
|---|---|
| You ask Claude about yesterday's standup | The assistant looks up the meeting, fetches its summary, and replies with it inline. |
| Cursor drafts a commit message | The assistant searches recent work on the touched files and cites the relevant captures. |
| A local LLM helps you write a follow-up | The assistant searches meeting transcripts by participant and drafts an email you can edit. |
| You check why capture missed an app | The assistant checks capture status to explain the gap. |
In each case the assistant sees only what the tool returns for that specific call, not the entire database.
Trade-offs worth knowing now
- Tool results are bounded. Each call returns a limited window (for example, a page of search hits or a capped number of events). Assistants may need to call more than once for broad questions, which costs latency and, on cloud assistants, tokens.
- Grounding depends on retrieval. The assistant's answer is only as good as the captures surfaced by the tools it chose. Vague prompts tend to trigger broad searches with mediocre results.
- Cloud assistants can be verbose. Some clients will read large tool outputs into their context repeatedly. If that matters for cost or privacy, prefer a local LLM for day-to-day work and reserve cloud assistants for tasks that clearly need them.
- MCP is still maturing. Clients differ in how they display tool calls, cite sources, and handle errors. Overshow follows the protocol closely, but the experience also depends on the assistant you pair with it.
What it does not do
- It does not give assistants write access to your Overshow data.
- It does not stream captures in real time; it answers on-demand queries.
- It does not replace the desktop Ask feature. Ask stays the primary grounded-answer surface inside Overshow itself.
- It does not bypass capture controls. Paused or excluded content is not indexed, so MCP cannot retrieve it.
Register interest
If you would find MCP useful, the beta signup page is the best way to tell us. That also helps us prioritise which clients to polish first (local LLMs, Claude Desktop, Cursor, and others are all in scope, but launch support may roll out in stages).
See also
- Ask: the grounded-answer surface inside Overshow that uses the same local retrieval signals.
- Search: the filters and modes the integration's search tools map onto.
- Privacy: on-device processing, capture controls, and encryption, which together define what the integration can ever see.
- Security: how cloud assistant integrations are treated as an explicit opt-in.