Your meeting memory in every AI tool
You are in the tool you write in, asking it for a project update. What comes back is a competent update about nothing in particular, because the only thing it knows about the project is the four hundred words you pasted in before you asked. Everything that would make the update true was said out loud in three meetings it was not in.
That is not a tool failing at its job. It is a tool doing its job without a way to reach the place the answers are. The material exists — you recorded those three meetings — and there is a standard way to let something ask for it.
The connection, in one paragraph
The Model Context Protocol is an open way for an AI application to ask an outside system for context. Ona runs one of those systems for your account. Ona MCP means any client that speaks the protocol can put a question to your meetings and get an answer back, with nothing custom written on either side. Setting it up is a connection you create in settings and a key you paste into the client.
Get the shape of it right before anything else, because every interesting decision follows from the shape. This is a reading arrangement. A connected tool can ask your meeting memory questions. It cannot start a recording, it cannot edit or remove anything you hold, and it does not arrive in the other application as a second assistant sitting beside the first. The application you connected stays exactly what it was. It gains a source.
What a connected tool can see
It sees what you have recorded, when it asks, and only as far into that as the question reaches. There is no bulk copy and no standing feed. Every request is served on its own, at the moment it is made, and written to a log. A client granted search can query your conversations and receive the parts that match; between one question and the next it is holding nothing of yours at all.
That makes the answers narrow, which is the useful property and not a shortfall in it. Four requests, and what each one produces:
| What the other tool asks for | What comes back | What does not |
|---|---|---|
| What did we settle about the supplier's lead times? | The passages where that was discussed, and the meeting each one belongs to | The conversations that had nothing to do with it |
| Summarise the last three conversations on the migration | A summary drawn from those three meetings | Anything nobody recorded, including the corridor version of the same argument |
| Give me that line the way she actually said it | The line, and the conversation it sits inside | Any judgement about whether it should be repeated outside the room |
| Everything you have, as one copy | Nothing of the kind. Questions are answered one at a time, as they arrive | A standing feed of your account, which does not exist to be granted |
It is as useful to be precise about the other direction, because a protocol people have not used before tends to be imagined either far too small or far too large. No scope on any connection covers the following, and none is coming:
- Starting, stopping or scheduling a recording. Capture begins where you are standing, not in a client somewhere else.
- Altering a transcript, a summary or an action item, or removing any of them from your account.
- Reaching a conversation you never recorded, or one a colleague recorded into their own account.
- Your other connected services. Ona holds meetings; a connection to it is not a route through into your drive or your tracker.
- Watching. Nothing subscribes to your account and pushes new meetings outward as they land.
Notice what the middle column keeps doing. An answer arrives with the conversation behind it named, which is the difference between a tool that knows something and a tool that sounds as though it does. Inside Ona the same memory is read through Ask Ona, which keeps the transcript an answer stands on within reach of the answer. Over the protocol the same rule holds for a client that is not ours.
What you are handing over
Scopes are the first half of the answer and they are the straightforward half. Each connection gets its own key and only the grants you give it — searching, summaries, drafting — so a client that only ever needs to look things up is never given more than looking. Nothing is shared by default. Every query a connected tool makes lands in an access log: what was asked, what was returned, and when.
The three grants differ in how much of a conversation one request can pull across, which is the thing to hold in mind when you pick between them. Search hands back the parts that match what was asked, so a narrow question moves a narrow slice. Summaries work from a conversation as a whole and return it condensed, which is a good deal more of the meeting crossing in one go. Drafting is the widest of the three, because the client is composing something and pulling what it needs to compose it, so what crosses is shaped by what it is writing instead of by what you asked. Grant them in that order.
The second half is the one worth sitting with for a minute. Read access describes what the connection permits a tool to do to Ona. It says nothing whatever about what becomes of the answer once it arrives. An excerpt handed to another application is now inside that application — its context, its conversation history, whatever it keeps and for how long, whatever its own policy says about training. The protocol stops at the answer. Everything past that point is governed by the thing you connected, and choosing what to connect means looking at that side too.
Connecting one tool, carefully
None of this takes an afternoon. It takes a decision about which client and which scope, and then five minutes of setup you will not repeat.
The decision is worth more thought than the setup, and there is a question that settles it quickly: what would this tool do differently if it could reach the meetings? A client you draft long documents in has an obvious answer — it would stop inventing the backstory. A client you use to rename files has none, and connecting it is a door opened for no return at all. Where the answer is vague, that is the answer, and the connection can wait until a week when you notice yourself pasting a transcript into it by hand.
One connection, made deliberately
- Start with the tool you are already in all dayOne, not the five you have open. Every connection is a separate key and a separate place your transcripts can be read from, and the value of the second one is rarely the value of the first.
- Grant the narrowest scope that does the jobSearching, summaries and drafting are separate grants. Begin with search: a client that can look things up covers most of what you wanted it for, and you can widen it later on evidence, once you have some.
- Name the connection after the clientA key you cannot identify six months from now is a key you will not revoke. Name it for the thing it belongs to, on the machine it belongs to, and the access log becomes readable instead of theoretical.
- Ask it something you already knowMake the first query one you can check yourself. Ask about something you were present for and still remember clearly, then open whatever the answer points at. You are checking the route back, not the prose.
- Read the log at the end of the first weekTwo minutes. You are looking for a client asking more often, or more widely, than you pictured when you connected it. That is worth knowing early, while the connection is still one you can drop without rearranging anything.
Taking it back
Revoking is one action in settings and the key stops working immediately, including for a request already in flight. If what you want is a fresh credential rather than an ended connection, rotate the key and leave the connection standing. In a shared workspace an admin can see every connection across the team and revoke any of them.
What revoking does is stop the next read. It does not reach into the other tool and take back the last one. Plan around that sentence rather than around the button: the question to settle before you connect anything is not whether you can undo it, but what you would be comfortable having already been read by the time you changed your mind.
One client, search only, named after the laptop it runs on. Most days it changes nothing at all. Then somebody asks why a limit is set where it is, and I put the question in the window I am already sitting in instead of going to find the meeting myself.
Hugo P., Platform Engineer, medical devices company
Ona for technical and product teams sets this beside the rest of it — what a fortnight of design reviews, incidents and planning leaves behind, and which parts of that are worth reaching for again later.
What the wire does not carry
The memory holds conversations and nothing else. A decision reached in a message thread, or in a conversation nobody started anything for, is not in there — so a connected tool will not find it, and it will not mention that it was looking in a place with a hole in it. An answer built on a partial record does not arrive marked partial.
Deletion behaves the way you would want and no further. Remove a recording and it is gone from what any connection can reach from that moment on, along with the transcript and the summaries Meeting Notes built from it. A copy already answered into another tool, though, is that tool's to get rid of, on that tool's terms.
An access log is a record rather than a control. It tells you what a client asked for after it asked, which is worth having and is not the same as a thing that would have stopped it. And connections accumulate the way browser extensions accumulate: two chosen on purpose is a different arrangement from six that simply happened, and nobody ever decides to have six.
One fact belongs here rather than on a policy page, because a protocol that hands your words to another application invites the question directly: on our side, nothing you record is training material for any model. What the tool at the far end does with the same words is that tool's policy, which is the whole of the paragraph above.
Before you connect anything
No. A connection is created in settings and the address and key are pasted into the client, which is copying two strings into a box.
The part that takes thought is not the setup. It is deciding which client, and how much of your memory it needs to see to be worth having.
No. Recording starts in Ona and only in Ona: the phone, the web, and the Ona RecordPen, a Bluetooth pen you put on the table. Nothing over the protocol can begin one, stop one, or reach a conversation nobody captured.
MCP is the reading end of the arrangement. The making end stays where you can see it.
It stops working there and then, and the client will tell you it can no longer reach Ona. Nothing is queued up to arrive afterwards.
If the connection itself is fine and you only want a new credential, rotate the key instead. Same connection, new secret, nothing to set up again.
Connect the tool you already work in
Record this week's meetings, give one client search access, and ask it about a conversation you remember well enough to mark the answer.