Let Claude Code Save What It Learns: bulk_ingest Over MCP
A working pattern for giving a coding agent a durable library it can write to — with real tool calls, not theory.
7 min read
A coding agent spends an hour in your repository. It reads the migration history, works out why the retry logic is shaped the way it is, finds the three Stack Overflow answers that explain the driver bug, and fixes the thing.
Then the session ends and all of that is gone; the fix below is checked against BrainTube's own published documentation, read on 5 September 2026.
Not the code — the code is committed. What is gone is everything the agent learned getting there. The next session starts from nothing and rediscovers the same context, at the same token cost, arriving at the same conclusions you already paid for once.
This is the most expensive habit in agent workflows right now, and it is not a model problem. It is a plumbing problem.
What actually gets lost
Watch what a coding agent produces in a long session and sort it into two piles.
The first pile is artifacts: diffs, files, commits. These survive, because your repository is a durable store and the agent knows how to write to it.
The second pile is understanding. Why the previous approach failed. Which library version introduced the breaking change. The comment on a GitHub issue that explained the whole thing. That pile has nowhere to go. It lives in the transcript, and a transcript is not a knowledge base — it is not searchable across sessions, not indexed, and not reachable by the next agent that needs it.
You already solved this problem for code. Nobody keeps source in a chat window. The fix was a durable store the tool can write to. Understanding needs the same fix.
The pattern
Give the agent a library it can write to, over MCP.
BrainTube's MCP server is read-write, which means an assistant can put things into your library rather than only pulling them out. Connecting Claude Code is a config block:
{
"mcpServers": {
"braintube": {
"type": "streamable-http",
"url": "https://mcp.brain-tube.com/mcp",
"headers": {
"X-BrainTube-Token": "bt_your_key_here"
}
}
}
}Create the key in Settings → API Keys. It is stored only as a hash, so if you lose it, revoke and make another. Claude.ai connects over OAuth instead and needs no key at all; CLI tools and Cursor need the header.
Note what you are not doing here: you are not writing API payloads. MCP clients discover the available tools and their parameters at runtime. You connect the server, and the agent works out which tool fits what it is trying to do. That is the entire point of the protocol, and it is why this is a config change rather than an integration project.
The tools that matter for this
Forty-four tools are live on the server. Four of them carry this particular pattern.
`ingest_content` saves a single item — a note, an article, a document — into your corpus. This is the one-at-a-time case: the agent finds something worth keeping and keeps it.
`bulk_ingest` takes up to 50 items in a single call, with deduplication and embedding handled server-side. This is the one that matters for agents, because agents do not find one useful thing, they find eleven. Fifty individual save calls is a rate-limit problem and a latency problem. One call is neither. Dedup running server-side also means an agent re-reading a source it already saved does not create a second copy — which matters a great deal when the thing doing the saving is not a careful human.
`add_note` writes a note or synthesis back onto an item already in your corpus. This is where the agent's own reasoning lands, attached to the source that prompted it, rather than floating free.
`tag_item` adds or removes tags after the fact, so organisation does not have to be decided at save time.
Closing the loop
Saving is only half a memory system. The other half is getting it back at the start of the next session, and for Claude Code there is a tool built exactly for that shape.
`export_claude_md` generates a CLAUDE.md-compatible knowledge context file for any Claude Code project, out of your corpus.
That is the loop closed. The agent saves what it learns during the session. Before the next session, the relevant part of your library becomes the context file the agent reads on startup. What was learned in session one is available in session four without anyone re-explaining it.
The read tools are there for mid-session work too — search_knowledge for full-text, deep_search for "multi-hop knowledge search: semantic search + graph traversal from top results", find_path to "find the shortest path between two items in your knowledge graph". But export_claude_md is the one that changes how a Claude Code project starts.
What this costs, honestly
Saving is not free, and it would be dishonest to describe this pattern without saying so.
Saving items, running searches and querying your library all spend BrainTokens. MCP access is included on every plan including Free, but Free starts with 30 BrainTokens a month, and a bulk_ingest of 50 items is not a rounding error against that. If you point an unattended agent at this and let it save everything it reads, you will feel it. Give the agent a rule about what is worth keeping, the same way you would give a junior researcher one.
Two other limits worth knowing before you build on this. The HTTP interface alongside MCP is not versioned and carries no stability guarantee — it is what our own web app and extension call, so it changes when they need it to. And there is no typed SDK. If you are building something substantial, use MCP rather than the HTTP interface, and tell us what you are building so we can warn you before anything moves.
The smaller point
There is a version of this argument that says every agent should save everything. That is wrong, and it produces a library full of noise that makes retrieval worse.
The useful version is narrower. When an agent works something out that took real effort — a root cause, a version constraint, a design decision and why the alternative lost — that finding has a value that outlives the session, and right now it usually does not outlive it. A write-capable library is the difference between an agent that learns and an agent that re-learns.
Whether you build that on BrainTube or somewhere else matters less than noticing the gap exists. Most people running coding agents today have not noticed, because the artifacts survive and the understanding disappearing is invisible until you watch the same investigation happen twice.
Where BrainTube stands
To be explicit about the boundary of the claim: BrainTube's MCP server is read-write, one server covering the whole library, and it is included on every plan including Free — the connection guide lists all forty-four tools and the setup for each client.
What it does not do belongs in the same breath. One server covers the whole library, so a client cannot be scoped to a subset of it. There is no bring-your-own-model option and no typed SDK. There are no native mobile apps. And saving is metered rather than gated: nothing described here sits behind a tier, but everything an assistant does spends BrainTokens, and the pricing page is where the current allowances live. If your agent runs unattended, that meter is the constraint you will hit first, not a feature limit.
How these figures were checked
The tool names, their quoted descriptions and the 50-item bulk_ingest limit were read from BrainTube's connection guide at brain-tube.com/connect.md on 5 September 2026 — a page generated from the MCP server itself. The tool count of forty-four is a count of that page's tool table on the same date. The configuration block is reproduced from the same page verbatim. BrainToken allowances and the Free tier figure are from brain-tube.com/pricing, read the same day; check current pricing before relying on them.
The stability and SDK caveats are quoted from brain-tube.com/developers, same date.
If anything here has gone stale, tell us and we will correct it with the date attached.
Try BrainTube on your own corpus
Free tier, no card. Export anytime.