Your Agent Found Something. Where Does It Put It?

Retrieval is solved. Retention is not.

We read Recall's MCP documentation on 4 September 2026, and the sentence that settles the whole question is one line long: "The MCP server currently provides read-only access to your knowledge base. Write capabilities are coming soon." That is a fair description of where most connectors in this category sit today, and it names an asymmetry that anyone running research agents will already have noticed.

The reading half of the job is in good shape. Recall's own docs describe it well: no API key required, authentication handled in the browser over OAuth, a requested scope of kb:read, and once connected the assistant "can search your cards, read their content, and explore your knowledge base on your behalf", with setup documented for Cursor, Claude, ChatGPT, Perplexity and Gemini. That is a genuinely good connector, and it is available on their $0 Free plan alongside API access.

The writing half is where the work stops. At the end of a long research session, the useful output is a few paragraphs of synthesis and a dozen sources that turned out to matter. Unless a person copies that somewhere by hand, it is gone when the context window closes. The agent that reads everything keeps nothing.

What a save path has to do to be worth having

"Let the agent write things down" sounds simple and is not. Four properties separate a save path that earns its place from one that produces a mess you delete in a month.

It has to be reachable from inside the session. If saving means the human opens another application afterwards, the save does not happen. The whole point of a connector is that the write is one tool call at the moment the finding exists, not a chore queued for later.

It has to deduplicate. An agent that saves is an agent that saves the same canonical blog post four times across four sessions, because it has no memory of the previous three. Deduplication is not a nicety here; without it, agent-driven capture degrades a library faster than manual capture ever could.

It has to survive the session. Anything written into scratch context or a chat transcript is not saved, only postponed. Durable means a store with its own identity and lifecycle, independent of the client that wrote it.

It has to be findable again by a different agent. This is the requirement most easily skipped. A note written by yesterday's agent, in yesterday's client, is only worth writing if today's agent — possibly a different model in a different tool — can retrieve it by meaning rather than by remembering the filename. That means embedding and indexing happen at write time, not as a manual step afterwards.

Where the connectors stand on 4 September 2026

Recall's MCP is read-only today, by their own documentation, read live on 4 September 2026. Their 23 July 2026 changelog entry, which rebuilt social saves and added table view and more AI languages and models, describes that work as the "first step in the development of the write API". As of that date there is no entry on their public changelog board announcing a shipped write API. Being clear about this: read-only is a legitimate design choice, not a defect. A connector that cannot write cannot corrupt, and a great many useful agent workflows are pure retrieval. Their search release, titled 30 July 2026, also reaches reader content, notes and quizzes rather than card titles alone, with a text-versus-AI search toggle.

Rescroll, on thesecondbrain.io, does not raise the question at all: the string "MCP" appears zero times on their page. They have repositioned towards creators chatting with social media content, and a connector is simply not part of that offering today.

Heptabase ships a first-party MCP server, documented in their support article. We link the article rather than the endpoint, because an MCP endpoint hit with a browser is not a page anyone can read.

We have written about the read-only question at more length in Can Claude save to Recall?.

The half nobody has solved: provenance

Here is the honest limit of this whole argument. A save path is one half of the problem. The other half is that a note written by a machine has to be trustworthy when a human — or another agent — reads it back six months later, and nobody in this category has really solved that.

When you save an article yourself, the provenance is implicit: you chose it, you were there, you remember why. When an agent writes a synthesis, the resulting item carries a claim with no obvious way to check which source it came from, or whether it summarises something read or stitches an inference between two things. Retrieval then treats that machine-written paragraph exactly like a quoted passage from a paper. Over a few hundred items, that is how a library quietly becomes unreliable.

Nobody ships a good answer to this, us included. Timestamps and source links help and are the minimum; they do not distinguish a verbatim extract from a model's gloss on it. It is the next real problem in agent-facing knowledge tools, and it is worth saying plainly rather than pretending the write API is the finish line.

Where BrainTube stands

BrainTube's MCP server is read-write today. One server covers the whole library at a single endpoint, and it connects to Claude.ai over OAuth with no API key, or with a bt_ token if you prefer headers. On the write side, ingest_content writes a single item; bulk_ingest, in its published description, will "Ingest up to 50 items in a single call with dedup and embedding"; and add_note writes a note back to an item that already exists. That covers the four requirements above: in-session, deduplicated, durable, and indexed for later retrieval by whichever client comes next. MCP access and bt_ API keys are included on every plan, including Free. The full tool list, 44 tools as of 4 September 2026, is published at brain-tube.com/connect.

What it does not do, specifically. There are no SDKs — MCP and the documented HTTP auth headers are the integration surface, and if you want a typed client you are writing it yourself. There is no per-brain MCP server: one server covers the whole library, which is convenient and also means you cannot hand an agent a connector scoped to a single brain. There is no bring-your-own-model option. And social-post capture is unverified on our side, so it is not something to plan a workflow around — if that is your ingestion path, treat it as unproven rather than as a feature. On the provenance problem in the section above, BrainTube is in the same position as everyone else: it records what was written and when, and it does not yet mark machine-written text as distinct from captured text.

How these figures were checked

Recall's read-only statement, the OAuth and scope details, and the client setup list were read from https://docs.recall.it/developer/mcp on 5 September 2026, which returned HTTP 200; the separate REST API reference at https://docs.recall.it/developer/api, read the same day, is read-only as well — three GET endpoints, and a note that a write API is on the roadmap. The Free-plan MCP and API entitlement came from https://www.recall.it/pricing on the same date. The 23 July 2026 "first step in the development of the write API" wording, and the absence of any shipped-write-API entry, came from https://feedback.recall.it/changelog on the same date; the search release is titled 30 July 2026 and carries a board date of 4 August, so we have named it by its title rather than asserting one date. The Rescroll observation is from https://www.thesecondbrain.io/ on 4 September 2026. The Heptabase MCP article returned 200 on the same date; we link only the article, because an MCP endpoint is not a page a reader can open in a browser. Claims about BrainTube describe functionality running in production on 4 September 2026, with the tool count and tool descriptions read from https://brain-tube.com/connect.md that day. If you spot something here that has gone stale, tell us and we will correct it with the date attached.