Short answer
Yes. n8n's MCP Client Tool node is an MCP client, and Baalda serves the Model Context Protocol at POST /api/mcp over Streamable HTTP. Set Server Transport to HTTP Streamable, authenticate with a Bearer token minted in Baalda, and the AI Agent node can read, create and append to your team's markdown files.
An n8n workflow produces something almost every time it runs: a summary, a triage decision, a piece of research, a reason it skipped a record. Almost all of it goes to Slack, to an email, or to a row in a database. None of those is a place knowledge accumulates. A Slack message scrolls away in a day, and a database row is not something a person reads, disagrees with, and corrects. The work happens and nothing is left behind. Point the workflow at a Baalda vault over MCP instead and the output lands as markdown on your own disk, in the same files your team is already editing.
Which n8n node connects to an MCP server?
The MCP Client Tool node. It is a sub-node: it has no main input, it outputs a Tools connection, and you attach it to an AI Agent node. The agent then calls the remote server's tools the same way it calls any other n8n tool.
There is a second node going the other way, the MCP Server Trigger, which exposes n8n's own tools to an external agent. That is the opposite problem and not what this post is about.
n8n also keeps an MCP servers registry you can connect to straight from the node panel without adding a credential. Baalda is not in it, so this is the manual path, which n8n's own docs describe as what the node is for: "Use this node for MCP servers that aren't in the registry yet."
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 notes in real time over a CRDT, permissions are set per file, and it is open source under Apache-2.0 and self-hostable. It serves the Model Context Protocol at POST /api/mcp over Streamable HTTP, which is the door n8n walks through. It is free to run locally, with an optional managed Team plan for hosted sync.
How do you connect n8n to Baalda over MCP?
1. Mint a vault token. In the Baalda desktop app, open Vault Settings and create an MCP connection token. The plaintext is shown once. It is minted for one user and one vault.
2. Add the credential in n8n. Create a Bearer Auth credential and paste the token in. Baalda accepts the token as a Bearer header.
3. Add an MCP Client Tool node and attach it to your AI Agent node. Set:
Endpoint: http://localhost:3010/api/mcp
Server Transport: HTTP Streamable
Authentication: Bearer Auth
Credential: the Baalda token from step 2
Tools to Include: Selectedhttp://localhost:3010/api/mcp is the default local address. If you self-host or use the Team plan, swap in your server's URL.
4. Pick the tools. Leave "Tools to Include" on Selected and choose the few you want. More on why below.
Why does my node only show an "SSE Endpoint" field?
Because it is pinned at the old version, and in that state it will never connect to Baalda.
The MCP Client Tool node has shipped as typeVersion 1 through 1.4, and the current default is 1.4. At typeVersion 1 the transport is hardcoded to SSE and the field is labelled SSE Endpoint. From 1.1 the field is labelled Endpoint and a Server Transport select appears, offering "HTTP Streamable" and "Server Sent Events (Deprecated)". From 1.2 onward that select defaults to HTTP Streamable. HTTP Streamable transport was added to the node in n8n PR #15454, merged 18 July 2025 and released in n8n 1.104.0.
This matters because Baalda does not speak SSE at all. POST /api/mcp is the whole surface; GET /api/mcp and DELETE /api/mcp both answer 405 Method Not Allowed, deliberately, so that clients fall back to POST-only instead of waiting on a stream that is never going to open. An SSE-only node cannot complete a handshake against it.
A node already sitting on an old canvas keeps the version it was created at. This exact confusion was reported against n8n in July 2026, where the MCP Client node connected over HTTP Streamable and the MCP Client Tool node on the same instance would not. The n8n nodes team found the tool node was running version 1.0 rather than 1.4, and the fix was to delete it and re-add it from the sidebar. If you see "SSE Endpoint", do that before you start debugging the token.
Which tools should the agent actually get?
Baalda exposes 22 tools, and six of them carry a destructive hint: update_note (it replaces the whole body), delete_note, delete_file, delete_folder, manage_access and set_access_default. An automation that files notes has no business holding the last two.
For a workflow that writes things down, this is usually the whole list:
| Tool | What it is for |
|---|---|
search_notes | Find the note before writing a second copy of it |
read_note | Read it, and get back a revision |
create_note | Start a new note when none exists |
append_note | Add to the end of a running log |
edit_note | Change one passage without resending the body |
Set "Tools to Include" to Selected and name those five. The alternative, All Except, works too, but a deny list quietly grows holes every time the server adds a tool.
The tool catalog is the same for every token, so this selection is a convenience, not a security boundary. The real boundary is the next section.
What can an n8n workflow see in the vault?
Exactly what the person who minted the token can see, and nothing else.
A Baalda MCP token is minted for a (user, vault) pair, and every tool call runs through the same access-control resolver as the rest of the app. Reads need view on the file, writes need edit, and creating or deleting a folder needs edit on its parent. Owners and admins have edit everywhere. Members can only delete what they created. So an automation pointed at a vault is not a new principal with its own scope: it is a teammate, wearing one specific teammate's badge.
That is the useful half and the awkward half at once. Useful, because per-file permissions mean you can give a workflow a token from an account that only has access to one folder, and the agent genuinely cannot read the rest of the vault no matter what the model decides to try. Awkward, because there is no separate bot identity. Mint the token from the founder's account and the automation inherits the founder's reach. An MCP server over a team's notes has to know who is asking, and here the answer is whoever clicked the button.
The practical move is to create a real account for the automation, invite it to the vault, grant it the folders it needs, and mint the token from there.
What stops a retried run from writing the same note twice?
n8n's node settings include Retry On Fail: "When an execution fails, the node reruns until it succeeds." That is the right behaviour for a flaky HTTP call and the wrong behaviour for an append that already landed before the timeout.
Baalda's append_note takes an optional idempotencyKey. A repeat call with the same key returns the first result instead of appending again. edit_note and append_note both also take an expectedRevision, the value read_note hands back, and refuse the call outright if the note has changed since you read it. For edit_note the anchor has to match exactly once as well, so an ambiguous match refuses the whole call with nothing written rather than guessing.
The honest limit: those guards only work if the same values come back on the retry. An LLM-driven AI Agent node that invents a fresh UUID on each attempt defeats the idempotency key completely. You get the guarantee by passing a key the workflow derives deterministically, from the execution ID or the source record ID, not by hoping the model repeats itself. If the write has to be exactly-once, do it from a deterministic branch of the workflow rather than from the agent's own judgement.
What you do get for free is that a write from n8n and a person typing in the same note at the same time do not fight. Baalda merges with a CRDT, so the agent's paragraph and the human's sentence both survive. A write also broadcasts a tree change, so the new note appears in open sidebars immediately instead of surfacing on someone's next restart. The design intent in the server is that an MCP write should be indistinguishable from a teammate's edit, and it is.
Can n8n Cloud reach a vault on my laptop?
No, and this is the part that stops most people.
n8n Cloud runs on n8n's infrastructure. http://localhost:3010 from there means n8n's own container, not your machine. There are three ways out of it, in order of how much work they are:
- Self-host n8n on the same network as the vault server. If n8n is in Docker and Baalda is on the host, the endpoint is
http://host.docker.internal:3010/api/mcp, notlocalhost, because each container has its own localhost. On Linux you need--add-host host.docker.internal:host-gatewaywhen you start the container. - Run Baalda somewhere always-on, self-hosted or on the managed Team plan, and point n8n at that URL over HTTPS.
- Expose your local server through a tunnel. This works and it is the option to think hardest about, because you are putting a door to your team's notes on the public internet for the sake of an automation.
A scheduled workflow is always-on by definition, so a vault that only exists while a laptop is open was never going to be the right pairing. If the automation runs nightly, the server needs to be up nightly.
Where this is the wrong tool
Three cases.
If the output is genuinely disposable, leave it in Slack. A daily "12 records synced" message does not belong in a knowledge base, and routing it into a vault produces a folder nobody opens. The test is whether a person would ever want to correct it. Notes are for the things with judgement in them.
If your team's knowledge already lives in Notion, Notion's hosted MCP server is easier to reach from n8n Cloud than anything self-hosted: OAuth, no infrastructure, and it is up whether or not your machine is. The trade is the one our Notion comparison spells out, that the files are theirs. If you are not ready to make that trade in the other direction, do not move your automations first.
And if you want structured records rather than prose, use a database. Baalda holds markdown that a human reads. A workflow that needs to query "every lead from last Tuesday with status X" should write to Postgres and, at most, write the weekly interpretation of it into a note. Connecting an assistant to notes over MCP is about the prose half of what a team knows, not a replacement for a table.