Can Claude Actually Save to Recall? What a Read-Only MCP Means

You connect Recall to Claude, following their setup guide. The connector authorises, the tools appear, and Claude confidently tells you it has saved the article to your knowledge base.

It has not. It cannot.

This is not a bug, and it is not Recall being cagey — it is written plainly in their own documentation. But the failure mode is confusing enough, and the assistant's confidence convincing enough, that it is worth spelling out exactly where the wall is.

What read-only actually means here

When an MCP client connects to Recall, it requests a single scope: kb:read. Their documentation describes it as "Read your saved content," and the page carries a plain notice that the server "currently provides read-only access to your knowledge base. Write capabilities are coming soon." That documentation was last updated on 28 July 2026.

The server exposes four tools, all of which require that one scope:

• search — find cards by meaning or keyword
• filter_by_metadata — list cards matching date, tag or source filters
• get_document_content — read the full content of a specific card
• explore_kb — get an overview: stats, tags, sources

Read them as a set and the shape is obvious. Every one is a way of getting things out. There is no tool for putting anything in — no create, no update, no tag, no annotate. The REST API tells the same story from the other side: three GET endpoints, and a notice that the API "currently supports read-only operations. A write API is on the roadmap, stay tuned," last updated 27 July 2026.

So when an assistant says it saved something to Recall, one of two things happened. Either it called a search tool and narrated the result loosely, or it simply asserted the action because that is what you asked for. Neither put anything in your library.

Why this matters more than it sounds

For a lot of workflows, read-only is completely fine. If your pattern is "I save things by hand in the app, then ask my assistant questions about them," a read scope does everything you need, and Recall's implementation is a clean one.

The wall shows up when the assistant is the thing doing the finding.

That is increasingly the shape of real work. You point an agent at a problem, it reads twenty pages, and three of them are worth keeping. In a read-only world, those three findings exist only in that conversation. Close the tab and they are gone. The agent could search your library all day but could not contribute a single thing back to it, which means your library only ever grows at the speed of your own manual saving — exactly the bottleneck you connected the assistant to escape.

The asymmetry is the problem. An assistant that can read everything you know and remember nothing it learns is a research tool with amnesia.

What read-write looks like

BrainTube's MCP server is read-write, and the tool list is the difference:

• search_knowledge — semantic search across everything saved
• ingest_content — save a new item into the library
• bulk_ingest — save many at once
• add_note — attach your own thinking to an item
• tag_item — organise what is already there
• get_stats — overview of the corpus

Same reading capability, plus a way in. In practice that means an assistant can finish a research session by putting what it found where you will find it again next month, tagged, in the same place as everything else.

Concretely: you ask an assistant to look into a topic, it reads and reasons, and at the end it saves the three sources worth keeping directly into your library with tags — no copy-paste, no switching apps, no "I'll file this later" that never happens. The next session, a different assistant on a different day can search that same library and find them.

Those tools are not hypothetical. They run in production and are the most-used write path on the server, with content ingestion, tagging and note-writing all firing regularly from live assistant sessions.

How to check any MCP server yourself

This distinction is going to matter across every tool that ships an MCP server, so it is worth knowing how to check rather than trusting a marketing page. Three ways, in order of speed:

Read the scopes. An OAuth consent screen that asks only to "read your content" is telling you precisely what you are getting. A scope named something like kb:read is unambiguous.

Read the tool list. Look for verbs. Search, get, list, filter and explore are read verbs. Create, save, ingest, update, tag and delete are write verbs. A tool list with no write verbs is a read-only server, whatever the surrounding copy implies.

Ask the assistant to prove it. Tell it to save something specific, then go and look in the app yourself. This is the only test that cannot be argued with, and it takes thirty seconds.

The honest summary

Recall's MCP server works well for what it does, and a read scope is a defensible first release — it is the safer half to ship, and shipping it early is how their users got connected assistants at all. Their documentation is upfront that writes are coming. When that lands, this particular gap closes.

Until it does, the answer to "can Claude save to Recall?" is no — not through MCP, not through the API. It can read your library beautifully and add nothing to it.

If the agent doing the work needs somewhere to put what it finds, that requires a server that accepts writes today.

How these figures were checked

Scope names, tool lists, endpoint counts and the read-only notices were read directly from Recall's developer documentation for both MCP and the REST API on 25 August 2026; those pages carry their own last-updated dates of 28 and 27 July 2026 respectively. The BrainTube tool list and its production usage describe the server as it runs on the same date.

Recall's changelog shows a release roughly every two weeks, and a write API is explicitly on their roadmap, so this comparison has a shelf life. If it has gone out of date by the time you are reading, tell us and we will correct it with the date attached.