Does pointing an MCP server at one folder keep it out of the rest of my files?

Not by itself. The same guide calls these "cooperative boundaries": "a well-behaved server respects them, but nothing in the protocol stops a malicious or compromised one from reading whatever the process can reach." Its advice is that enforcement has to come from an isolation layer, a container or sandbox where the allowed directory is the only filesystem that exists, rather than from the allowlist in the config.

How does Baalda's MCP endpoint avoid running on a team member's machine?

It is Streamable HTTP rather than stdio. The endpoint is a single route on the Baalda server, `POST /api/mcp`, speaking JSON-RPC 2.0: `https://api.baalda.com/api/mcp` on the managed service, or your own server URL plus `/api/mcp` when self-hosted. A client registers a URL and a bearer token, so no package is installed and no child process is spawned on the member's machine. The token authenticates as one user within one vault and is stored as `sha256(token)` only.

Does hosting the notes server remotely protect me from other MCP servers?

No, and this is the limit worth stating. The guide notes that "Every server you configure shares the same model context, so a malicious server can influence how the agent uses the tools of every other server." A poisoned third-party server in the same client can steer the agent into misusing Baalda's write tools, including `update_note`, `delete_note` and `delete_folder`. The fix is the guide's: keep the roster small, read the tool descriptions, and prefer a client that re-prompts when a definition changes.

Can I run the endpoint on my own infrastructure?

Yes. Baalda is Apache-2.0 with no CLA and the server is self-hostable on Node and Postgres, so the MCP route is a path on a host you operate rather than on someone else's. That does not make the guide's advice irrelevant, it relocates it: you are now the one operating a server, with the advantage that it is one deployment to patch and audit instead of one per person.

The team's vault is the one MCP server that should not run on a laptop

Q: Is a local MCP server sandboxed?

No. The MCP project's Local Server Security guide, merged into its documentation on 5 October 2026, states that a local server is "an ordinary operating system process" which "inherits your environment variables, can read anything your account can read", naming SSH keys, cloud credentials, browser profiles and your home directory, and "can open outbound network connections to anywhere". It adds that "the client and a stdio server share one trust domain" and that "The stdio transport is not a sandbox." Isolation is the deployment's responsibility, not the protocol's.

There are two shapes for putting an AI in front of a team's notes, and until this week the choice between them read as a matter of taste. Either a notes server runs as a process on each person's machine, or the team runs one and everybody dials into it. On 5 October 2026 the MCP project merged a guide into its own documentation that makes the first shape much harder to recommend, because it writes down, in the project's own words, what that process can reach while it is reading your vault. Baalda has only ever shipped the second shape. This is the week to say why, and to be clear about what it does not buy you.

What does MCP's local server security guide actually say?

The guide is Local Server Security, merged into modelcontextprotocol/modelcontextprotocol on 5 October 2026 as PR #3072, described in that PR as an action item from the MCP Dev Summit in NYC. It is not a third-party opinion piece. It is the protocol's own documentation, and it covers the one threat model the existing security pages skipped: not OAuth flows or session hijacking, but your machine.

Its core statement is that a local MCP server is an ordinary operating system process launched by your client. In the guide's words, that process "inherits your environment variables, can read anything your account can read", with its own examples being SSH keys, cloud credentials, browser profiles and your home directory, and it "can open outbound network connections to anywhere". Then: "None of that is governed by the protocol."

Three further lines matter for anyone whose MCP server is pointed at a folder of notes.

On the transport almost every local server uses: "the client and a stdio server share one trust domain", and "The stdio transport is not a sandbox." The guide is explicit that this is by design, because a server launched as a subprocess already has code execution on your machine.
On the directory allowlist that most notes servers advertise as their safety feature: "Configuration-level allowlists are cooperative boundaries: a well-behaved server respects them, but nothing in the protocol stops a malicious or compromised one from reading whatever the process can reach."
On what to do instead: "Prefer the remote version where one exists. A server offered over Streamable HTTP runs no code on your machine, uses the protocol's authorization flow instead of a token in a local config file, and is patched in one place."

The guide also makes a point that gets lost when people read this as a single-server problem. "Every server you configure shares the same model context, so a malicious server can influence how the agent uses the tools of every other server. Each install extends the surface all the others are exposed to."

Why does this land harder on a team's notes than on other servers?

Because the vault is the one server everybody needs, and the local shape means one copy of it per person.

Take the standard recipe for giving an assistant your team's knowledge. You find a community notes server on npm, you add it to your client config with the vault folder as its root, and you paste a token. Now run that across a team of five to fifty people. The guide's fleet section describes the result from the administrator's side: "a centrally managed remote deployment gives you one instance to patch, audit, and control instead of hundreds."

Count what a team of twenty has actually built there. Twenty copies of a third-party package, each resolving its own transitive dependencies at install time, each pinned to whatever version that person happened to install. Twenty processes with twenty people's full account access, not twenty folders. Twenty plaintext tokens sitting in client config files at known, predictable paths. Twenty separate decisions about whether to update when an advisory lands, and no inventory telling anyone which machines are affected.

And the vault folder in the config is not a boundary. That is the "cooperative boundaries" line, and it is the part most teams get wrong, because the allowlist is usually the exact feature that made the server feel safe enough to install.

The guide's honest framing of all of this is that "no check proves what a server will do." Provenance tells you who you are trusting. It does not tell you the trust is warranted.

What does a vault server look like when it is not a process on your machine?

Baalda is a team second brain: plain markdown files on your own disk, edited by several people at once in real time, with an AI reading and writing those same files over MCP. The piece relevant here is the transport, and it is not stdio.

Baalda's MCP surface is Streamable HTTP, a single route on the Baalda server: POST /api/mcp, speaking JSON-RPC 2.0. On the managed service that endpoint is https://api.baalda.com/api/mcp; self-hosted, it is your own server URL plus /api/mcp. Registering it with a client means pointing at a URL, not installing anything:

bash

claude mcp add --transport http context https://api.baalda.com/api/mcp \
  --header "Authorization: Bearer mcp_…"

Nothing in that command runs on the member's machine. There is no package, no dependency tree resolved at install time, no child process inheriting their environment. When a vulnerability is announced, there is one deployment to patch, which is the thing the guide's fleet section is asking for.

The token is narrower than the usual one too. Baalda's apps/server/src/mcp/tokens.ts documents it as authenticating a client "AS one user WITHIN one vault", and the server stores only sha256(token), with the plaintext shown to the person exactly once at creation. Two people pointing the same client at the same URL are not reaching the same material, because each token carries its own identity and its own vault.

The guide's preference for "the protocol's authorization flow instead of a token in a local config file" is also available rather than theoretical. Every 401 from the endpoint returns a WWW-Authenticate header carrying resource_metadata pointing at /.well-known/oauth-protected-resource, per RFC 9728, so an OAuth-capable client can discover the authorization server and run the flow instead of having a long-lived secret pasted into a file on disk.

What the client is handed at the other end is a fixed catalog of 22 named tools, from read_note and search_notes through edit_note and manage_access, and not a shell. Every one of those calls is re-checked server-side against the same per-folder permission resolver that governs people, so the answer to "what can this agent reach" is the answer to "what can this person reach", resolved on each call rather than declared in a config file. How MCP works for notes covers the tool surface in more detail, and the self-hosting docs cover running the whole thing on your own infrastructure under Apache-2.0.

What does moving the server off the laptop not fix?

Three things, and the first is the guide's own best point.

The trust domain is cumulative, and remote does not opt you out of it. If the same client also has a poisoned third-party server configured, that server's tool descriptions are in the model's context alongside Baalda's. It can steer the agent into misusing tools it does not own, and Baalda ships write tools: update_note, delete_note, delete_folder, move_folder. Hosting the vault server remotely removes it from the list of things that can read your SSH keys. It does nothing about what the rest of the list can talk the agent into doing with your notes. The mitigation there is the guide's, not ours: keep the roster of configured servers small, read the tool descriptions, prefer a client that re-prompts when a tool definition changes.

A leaked bearer token is still a leaked bearer token. Scoping it to one user and one vault bounds the damage to that person's reachable notes. It does not prevent it. The protection is revocation, and revocation only works if somebody looks.

Baalda's other path is local filesystem access, and that is the same access the guide is about. The README is direct about it: a local agent needs no setup at all, because the notes are .md files on disk and Claude Code or any CLI tool edits them in place. The distinction worth drawing is narrow but real. No third-party package gets installed, and no new process gets your account; the agent you had already granted filesystem access uses the access you already granted it. That is a better position than adding a notes server from npm to the same machine, but it is not sandboxed, and anyone reading the guide and feeling uneasy about stdio servers should feel equally uneasy about a broadly scoped coding agent. The guide's containment advice applies to both.

When is a local notes server still the right call?

When there is no team, and you do not want to operate anything.

If you are one person with one vault on one machine, a local stdio server is genuinely the simpler build. There is no host to run, no certificate to renew, no bill. And the guide gives you a real answer rather than a shrug: run it in a container with nothing mounted except the vault directory, read-only where possible, pin the image by digest, and deny network egress with --network=none if the server does not need it. Its own closing default is "grant access to a single project directory, read-only". Do that and the blast radius is close to the thing you actually wanted to share.

This is also where Obsidian sits today, and it is worth being fair about it. Obsidian is the better app for a solo vault, and its ecosystem of community MCP servers is larger and more varied than anything we have. The cost is that those servers are the local shape by default, which is the pattern this guide is written about, and that the pattern multiplies by headcount rather than staying flat. For one person it is fine. For twenty it is twenty of everything.

The dividing line is not local versus cloud, and Baalda is local-first on both sides of it: the markdown lives on each member's disk either way. The line is whether the piece of software that an AI client authenticates to is something each person installs or something the team operates. For most software that is an implementation detail. For the server holding what your team knows, the MCP project has now written down why it is not.