Read-Only vs Read-Write MCP Servers: The Distinction That Decides Agent Memory

Two products can both list "MCP server" on their feature page, both connect to Claude in about ninety seconds, and both be accurate in saying so. We read Recall's MCP and API documentation on 5 September 2026, and the difference it exposes is the kind you would otherwise only find after a week of use: two servers wearing that label can do fundamentally different jobs.

The difference is not speed, or how many tools they expose, or which clients they support. It is a single question: can the assistant put something back?

What read-only actually means

A read-only MCP server lets an assistant reach into your library and pull things out. It can search, retrieve a document, list what is there. What it cannot do is add anything. The library only ever grows through you — through the app, the extension, the manual paste.

For a large class of work, that is completely fine. If your library is already built and your use case is asking questions of it, read-only is all you need. It is also the safer default: nothing an assistant does can corrupt what you have saved, because it has no mechanism to write.

Recall is the clearest current example, and their documentation is admirably direct about it. As of their developer docs last updated 28 July 2026, and checked again on 5 September 2026:

The MCP server currently provides read-only access to your knowledge base. Write capabilities are coming soon.

The design follows through consistently. The OAuth flow requests exactly one scope, kb:read, described as "Read your saved content." The server exposes four tools — search, filter_by_metadata, get_document_content and explore_kb — and every one of them requires that single read scope. There is no write scope to grant, because there is nothing to grant it to.

That is a coherent product decision, not an oversight. It is also explicitly temporary: "coming soon" means this comparison has a shelf life, and if you are reading this months after publication, check their docs rather than trusting this paragraph.

What changes when the assistant can write

Now consider the same week of work with a server that accepts writes.

You ask a research agent to look into something. It reads twenty sources, and three of them are genuinely worth keeping. With a read-only server, the agent tells you which three, and then you go and save them yourself — in another tab, one at a time. The finding was produced by the agent; the filing is entirely manual.

With a read-write server, the agent saves them. The three sources land in your library, tagged, queryable in your next session. The work the agent did survives the conversation it happened in.

BrainTube's MCP server is read-write. Its write tools are listed on its public connect page: ingest_content for saving a single item, bulk_ingest for saving many at once, add_note for the assistant's own observations, and tag_item for organising after the fact. Those sit alongside the read tools you would expect — search_knowledge, list_recent, get_stats.

We are describing the shape of the surface here, not claiming a scoreboard win. A read-write server is more capable and correspondingly less safe. An assistant with write access can save the wrong thing, tag inconsistently, or fill your library with material you did not want. Read-only servers cannot make that mistake, which is precisely why some teams prefer them.

Why this decides agent workflows specifically

For a human sitting at a keyboard, the gap is an annoyance. You read the agent's summary, you copy the links, you save them. Thirty seconds.

For an agent running unattended, the gap is fatal. There is no human in the loop to do the filing. If the server is read-only, the agent's findings exist only in the transcript — and transcripts are not a knowledge base. They are not searchable across sessions, not indexed, not reachable by the next agent that needs them. The work evaporates when the context window closes.

This is the part that gets missed in feature comparisons. "Has MCP" is treated as a binary, and it genuinely is not. A read-only MCP server makes your library available to agents. A read-write one makes agents contributors to it. Those are different products wearing the same three-letter label.

The practical test: if you are building anything that runs without you watching — a scheduled research job, a coding agent that should remember what it learned, a pipeline that files documents — read-only is not a limitation you can work around. There is no write endpoint to call.

The questions worth asking

Before you commit an archive to any tool with an MCP server, three things are quick to check and rarely advertised:

Which scopes does the OAuth flow request? This is the fastest tell, and you see it at connect time whether or not the docs are clear. A single read scope means read-only, regardless of how the feature page is worded.

What do the tool names suggest? Tools called search, get, list and explore are a read surface. If nothing in the list implies creation, nothing creates.

Is write on the roadmap, and dated? "Coming soon" without a date has an unbounded meaning. A vendor willing to put a quarter on it is telling you something more useful than one who is not.

None of this requires trusting a comparison page, including ours. Every claim in this post came from a vendor's own public documentation, which is a thing you can go and look at yourself.

The honest summary

Read-only MCP is the right answer if your library is built and you want to ask it questions. It is simpler, safer, and for most people using an assistant interactively, sufficient.

Read-write MCP is the right answer if you want the things your assistants learn to accumulate somewhere durable. That is a narrower need today. It is also, we would argue, where the category is going — the volume of reading done by agents rather than people is only moving in one direction, and none of it is worth much if it cannot be filed.

Pick according to which of those describes your week. Just do not assume that "supports MCP" answered the question, because it did not.

Where BrainTube stands

BrainTube runs one read-write MCP server covering the whole library, at https://mcp.brain-tube.com/mcp. Reading the connect page on 5 September 2026 lists 44 tools, ingest_content and bulk_ingest among them, and MCP access is included on every plan including Free — so the write half can be tested on a $0 account rather than taken on trust.

The other side of that design is worth stating plainly. One server covers the whole library, so there is no per-brain scoping: a client you connect reaches the library, not a slice of it. There is no bring-your-own-model option. And social-post capture is not something we have verified, so it is not a capability to plan around. What read-only means in practice for one specific client, we went through in can Claude save to Recall.

How these figures were checked

Recall's read-only status, the kb:read scope and the four-tool list were read from their MCP documentation at docs.recall.it/developer/mcp on 5 September 2026; that page states it was last updated 28 July 2026. Their MCP write capability is described on that page as "coming soon", with no date attached. Their separate REST API reference at docs.recall.it/developer/api, which states it was last updated 27 July 2026 and which we read the same day, is also read-only — three GET endpoints, no POST, PUT or PATCH — and states that a write API is "on the roadmap". Either may well have shipped by the time you read this, and their docs are the authority, not this page.

Claims about BrainTube's MCP tools describe the tools published on brain-tube.com/connect.md, read on 5 September 2026. We have named the specific write tools alongside the published total.

If anything here has gone stale, tell us and we will correct it with the date attached.