Where does Cline keep its MCP configuration?

In the VS Code and JetBrains extensions it is `cline_mcp_settings.json` in the extension's global storage, opened from the Cline panel with the MCP Servers icon, the Configure tab and the Configure MCP Servers button rather than by path. Cline's CLI reads `~/.cline/mcp.json` instead. The extensions also have a Remote Servers tab that writes the same entry through a form.

Why does leaving out the type field break the connection?

Because Cline falls back to SSE, and SSE expects to open a long-lived `GET` on the endpoint. Baalda returns 405 on `GET /api/mcp` and `DELETE /api/mcp` deliberately, since there is no server-initiated stream and every message goes over `POST`. Writing `"type": "streamableHttp"` is what makes the server start.

Should the memory-bank folder move out of the repo entirely?

No. Keep whatever is only true of this codebase and should be reviewed alongside the diff, because git is a good fit for that. Move the decisions, product context, incident write-ups and cross-repo conventions to the vault, then leave one short file in the repo pointing at where the rest lives.

Can Cline write to the vault while it is in Plan mode?

Cline's docs say Plan mode reads the codebase and runs searches without modifying files or running commands, and they do not spell out which MCP tools each mode may call. Treat that as unsettled: leave `autoApprove` empty and every write request is shown to you before it lands, whichever mode you are in.

What stops the agent overwriting a note a teammate just changed?

`read_note` returns a `revision`. Pass it back as `expectedRevision` and a write against a note that moved in between is refused instead of merged over the top. `edit_note` adds a second guard: its anchors must match exactly once, and an anchor matching zero times or more than once fails the whole call with nothing written.

A memory bank Cline can reach from any repo

Cline is one of the few agents that already admits it forgets. Its own documentation says the memory resets completely between sessions, and the answer it ships for that is a folder of markdown called the memory bank, read at the start of every task. It is a good answer. The limit is where the folder sits: inside one repo, on one laptop, written by one person. The agent remembers. The team still does not.

What is Cline's memory bank, and what does it hold?

It is six markdown files in a memory-bank/ folder at the root of the project:

projectbrief.md, the foundation the rest builds on
productContext.md, why this exists and who it is for
activeContext.md, what is being worked on right now
systemPatterns.md, the architecture and the decisions behind it
techContext.md, the stack and its constraints
progress.md, what works and what is left

Cline reads all of them before it starts a task, and the phrase update memory bank triggers a full review and rewrite. Nothing about the files is special. They are ordinary markdown you can open, edit and argue with, which is exactly why the pattern caught on.

Why does the memory bank stop working the moment a second person opens the repo?

Three ways, and none of them are Cline's fault.

It is scoped to a repo, and decisions are not. Why the team picked one queue over another, what the client said in the call that changed the schema, the incident that produced the retry policy: that reasoning is relevant in four repos and lives in one. In the other three, Cline re-derives it, and sometimes derives something different.

Everyone's copy drifts. activeContext.md is, by design, a file about right now. Two developers on two branches both have a right now. Whoever merges last wins, or the file collects both and stops being a summary of anything. Git is very good at telling you two people edited a line. It is not good at telling you which of two true statements about the current state is the one you meant.

The people who hold the context do not open the repo. The product decision, the support pattern, the thing sales promised: the memory bank cannot hold any of it, because writing to it means cloning the project. So the agent's memory is bounded by who has a checkout.

The fix is not to abandon the memory bank. It is to put the part that outlives the repo somewhere the whole team writes, and let Cline reach it the same way it reaches anything else, over MCP.

What is Baalda, in one paragraph?

Baalda is a team second brain built on plain markdown files on your own disk. Several people edit the same note at once over a CRDT, permissions are set per folder and per note, and the core is open source under Apache-2.0 and self-hostable. It serves the vault over MCP at /api/mcp, so an agent works on the same files a person does, held to the same permissions that person has. Running it locally is free, with an optional managed Team plan for hosted sync. If the category is new to you, what a team second brain is covers the idea before any of the plumbing.

How do I connect Cline to a Baalda vault?

One entry in Cline's MCP settings.

1. Mint a token. In Baalda, open Vault settings and then MCP, and create a token. It comes back once, starts with mcp_, and encodes both the user and the vault it belongs to. Each person on the team mints their own. That is the whole permission model: the agent carries your access, not a shared one.

2. Open the MCP config. In the VS Code and JetBrains extensions, open the Cline panel, click the MCP Servers icon, go to the Configure tab and use the Configure MCP Servers button. That opens cline_mcp_settings.json in the extension's global storage, so you do not have to hunt for the path. Cline's CLI reads ~/.cline/mcp.json instead.

3. Add the server.

json

{
  "mcpServers": {
    "baalda": {
      "type": "streamableHttp",
      "url": "https://api.baalda.com/api/mcp",
      "headers": {
        "Authorization": "Bearer mcp_your_token_here"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Self-hosted, swap the host for your own domain and keep the /api/mcp path. Running the server on your own machine, it is http://localhost:3010/api/mcp. The extensions also have a Remote Servers tab that takes a name, a URL and a transport through the UI and writes the same entry for you.

Leave autoApprove empty to start. It is the list of tools that skip the approval prompt, and the first week is when you want to see every write before it lands.

Why does the transport type matter more here than it usually does?

Because Cline's default is the one that will not work.

Cline treats a remote entry with no type as SSE, which is the legacy transport. SSE expects the client to open a long-lived GET on the endpoint and receive messages back down it. Baalda does not offer one. GET /api/mcp and DELETE /api/mcp both return 405 on purpose, so a client can tell immediately that there is no server-initiated stream and fall back to plain request and response. Every message goes over POST.

So "type": "streamableHttp" is not a preference here, it is the thing that makes the connection work. Omit it and you get a server that appears in the list and fails to start, with an error that points at the network rather than at one missing line of JSON.

If you would rather not put a token in a config file at all, the endpoint also accepts it as a ?key= query parameter. That is worse, not better: URLs end up in logs and shell history. The header is the right place.

What can Cline do once it is connected?

The vault arrives as a set of tools rather than a folder: list_notes, list_folders, read_note, search_notes, create_note, update_note, append_note, edit_note, move_note, delete_note, plus list_attachments and read_attachment_text for files that are not markdown.

Two of them are worth understanding before you approve a write:

read_note returns a revision. Pass it back as expectedRevision and a write aimed at a note that changed in the meantime is refused rather than merged over the top.
edit_note works on anchors. An anchor that matches zero times, or more than once, fails the whole call and writes nothing.

search_notes also reaches into attached documents and spreadsheets, and every hit says whether it came from a note or a file. And writes go through the same sync engine as human typing, so if a teammate has the note open they watch the paragraph appear. It is not a copy that gets reconciled on the next pull.

How does this fit Plan mode and Act mode?

Fairly neatly, which is the reason this agent is worth the setup.

Cline's Plan mode, in its own documentation, lets it read the codebase, run searches and discuss strategy without modifying files or running commands. Act mode executes against the plan, and the conversation history carries over, so the reasoning is still in context when the edits start. A shared vault gives Plan mode something to read that the repo cannot supply: the decisions, the constraints, the last three attempts at this and why they were abandoned.

The other half is what happens at the end. Right now update memory bank rewrites six files that only this checkout will ever see. Pointed at a vault, the same instinct writes the decision where the next person finds it, including the people who never clone anything.

One honest gap: Cline's published docs are explicit about what Plan mode cannot do to your files, and are not explicit about which MCP tools are available in each mode. Treat that as unsettled, keep autoApprove empty, and you will see each write request as it happens regardless of the answer.

What should stay in the repo?

Not everything should move, and a post that told you otherwise would be selling you something.

Keep in memory-bank/: anything that is only true of this codebase and should be reviewed with the code. Build quirks, the local dev setup, the module boundaries, whatever a pull request would want to see change alongside the diff. Version control is a genuinely good fit for that, because the file moves through the same review as the change it describes, and git log tells you when it stopped being true.

Move to the vault: the decisions, the customer and product context, the incident write-ups, the conventions that span repos, and anything a non-engineer has to be able to edit. Then keep one short file in the repo that says where the rest lives, so a fresh clone still finds the door.

Teams already doing this with an editor assistant will recognise the split. It is the same one the Cursor version of this setup lands on, and the reasoning carries over to any MCP client.

Where is this the wrong setup?

If you work alone on one repo, the memory bank is already the right size and an MCP server is a moving part you do not need. Cline's file-based answer is genuinely good, and adding a server to it buys you nothing.

Obsidian deserves the credit here too. Its plugin ecosystem is far deeper than ours, community MCP servers for it exist, and for one person it is excellent software. What it does not have is several people editing the same note at once or permissions below the vault, which is the specific gap the multiplayer post goes through. If your team is fundamentally one person with a sync bill, stay where you are.

Baalda is the wrong choice if you want database views, or if plain files on disk are not something you would pay anything to keep. It is the right one when the reasoning behind the code has to outlive the branch, several people write it down at once, and the agent that reads it should be held to the same permissions as the person who ran it.