Short answer
Two ways, and they do different jobs. Custom instructions, Projects and uploaded files make ChatGPT behave like a second brain, scoped to your account. Connecting it to a custom MCP server makes it the interface to one, reading and writing markdown files you keep. Use the first for private thinking, the second for anything a team relies on.
There are two different questions hiding inside "how do I use ChatGPT as a second brain", and almost everything written about it answers only the first. The first is how to make ChatGPT behave like one: give it standing instructions, keep a master context document, start a thread per project, upload your reference files. That advice is good and it works. The second question is where the knowledge ends up, and the honest answer to that one is: inside your ChatGPT account, where nobody else can open it. For one person that is a trade you might accept. For a team it is the whole problem.
Baalda exists for the second question. It keeps the notes as plain markdown files on your own disk, and lets ChatGPT reach them over the Model Context Protocol instead of holding them. The point of this post is that you want both halves, and they are not the same setup.
How do you use ChatGPT as a second brain?
Two ways, and you can run both at once. The first is to use what is already in the product: custom instructions so it knows who you are without being told again, a Project per area of work with its reference files attached, and the habit of putting things into it rather than into a document you will not reopen. This is what every guide on the subject describes, and for a personal second brain it is genuinely most of the answer.
The second is to connect ChatGPT to a store you control. OpenAI's plugin documentation describes this path directly: you add a custom MCP server, ChatGPT calls its tools, and the data lives wherever the server keeps it. In that arrangement ChatGPT is the thing that reads, searches and writes, and your files are the thing that remembers. It stops being the second brain and starts being the interface to one.
Why does the first way stop working at a team?
Because everything it accumulates is scoped to one account. A Project's files, the standing instructions, whatever the memory has picked up about how you work: none of it is a shared artifact. A colleague cannot open it, cannot correct the part that is wrong, and cannot see what it is relying on when it answers. You cannot diff it against last month. When the person leaves or the subscription lapses, it goes with them.
That is not a complaint about the feature. It is what the feature is for. ChatGPT's memory is designed to make your sessions better, not to be a document your team maintains. The failure is in using it as one, which is what "build your second brain in ChatGPT" quietly asks you to do.
The tell is simple. Ask whether anyone other than you can open the thing your second brain is stored in. If the answer is no, you have a better assistant, not a second brain.
What does connecting ChatGPT to your own notes actually involve?
ChatGPT talks to outside systems as a custom MCP server. OpenAI's requirements are specific: the server has to support the MCP streamable HTTP transport and respond at a stable URL, typically ending in /mcp. You add it from ChatGPT Plugins, select the plus button, then Add custom MCP server, give it a name, enter your Server URL or select Tunnel, configure authentication, acknowledge the risk warning and create it.
Baalda serves exactly that shape. It is a team second brain built on plain markdown files on your own disk, with real-time multi-user editing, per-file permissions, open source under Apache-2.0 and self-hostable. Its MCP endpoint is POST /api/mcp on the same server as everything else, speaking JSON-RPC 2.0 over streamable HTTP, with 22 tools behind it: search_notes, read_note, create_note, append_note, edit_note, manage_access and the rest. On the managed service that endpoint is https://api.baalda.com/api/mcp; self-hosted, it is your own server's URL plus /api/mcp.
What makes ChatGPT a different case from Claude Code or Cursor is the authentication. Those clients let you paste a bearer token into a config file. ChatGPT's connector offers OAuth, No authentication, or OAuth or no authentication, and nothing else. There is no field for a header you minted yourself. So the OAuth path is not the nicer option here, it is the only one.
Who decides which notes a ChatGPT connector can reach?
The person connecting it, on a consent screen, and then the server on every single call after that.
This is the part worth understanding, because it is where a connector either inherits a sensible boundary or quietly gets everything. Baalda has two ways in and they carry different amounts of information. A hand-minted mcp_ token already encodes its scope in its own database row: one user, inside one vault. An OAuth access token does not. As apps/server/src/mcp/oauth.ts puts it, an OAuth token "only tells us WHO the caller is", so the vault has to be chosen by the user during consent and recorded in a mcp_oauth_vault row keyed per client and user. Consent again later and you retarget the same connector at a different vault.
Three things follow from that, and they are the reasons this is worth doing properly:
- The connector is one person's, not the workspace's. The binding is per client and per user, so your ChatGPT reaches what you can reach, and a colleague who connects the same server gets their own reach, not yours.
- Membership is re-checked per request, not at connection time. The resolver calls
orgRoleon the way through and returns nothing if you are no longer a member, so removing someone from a vault kills their live connector on its next call rather than whenever a token happens to expire. - Both doors lead to the same place. The OAuth path and the token path resolve to one
McpAuthcontext, so, in the file's own words, "everything downstream (service.ts ACL checks) is identical either way". The per-folder permissions that govern a person govern the assistant, through the same code.
OpenAI's own guidance points the same direction: enforce authorization in the MCP server for every request, and never rely on the model to decide whether a user has access. That is a requirement a notes app either meets in its server or does not meet at all.
What can ChatGPT do once it is connected?
Read and write, with the writes gated. OpenAI's documentation states that ChatGPT supports both read and write tools from a server, that write actions require confirmation by default, and that it respects the readOnlyHint tool annotation.
Baalda sets that annotation deliberately on every tool. read_note, search_notes, list_notes and list_attachments are marked read-only. create_note, append_note and edit_note are writes. update_note, delete_note, delete_folder and manage_access carry a destructive hint as well, because each one can remove something a person wrote or change who can see it. So the confirmation prompt you get in ChatGPT is driven by how the tool was classified in apps/server/src/mcp/tools.ts, not by guesswork at the chat layer.
The writes land through the same sync path a human keystroke takes. If a teammate has that note open in the desktop app while ChatGPT is editing it, they watch the text arrive rather than finding a conflicting copy later. And because read_note hands back a revision, you can pass it back as expectedRevision on a write and have the write refused if somebody changed the note in between.
When is this the wrong answer?
Three places, and the first one is a real cost rather than a caveat.
ChatGPT cannot reach a server on your laptop. Baalda runs free and local on http://localhost:3010, and from chatgpt.com that address does not exist. Connecting ChatGPT means the managed endpoint, or your own deployment behind a stable HTTPS URL, or OpenAI's Secure MCP Tunnel, which runs a small client inside your network that makes an outbound HTTPS connection so the private side makes the first move. The tunnel is documented as supporting private custom MCP server testing but not public plugin submission. Either way, the purely local install that is otherwise the best way to run Baalda is the one configuration ChatGPT cannot use. A local agent that can read your disk directly, like Claude Code, has no such problem and needs no server at all.
Baalda's tools are not the standard `search` and `fetch` schemas. OpenAI's build guide says implementing those specific input schemas is what makes a plugin eligible as a company knowledge source. Baalda exposes search_notes and read_note instead, which a custom connector calls perfectly well, but that eligibility is a thing to check against current OpenAI documentation rather than assume.
A private scratchpad belongs in ChatGPT. Half-formed thinking, personal context, the things you would not write in a document your colleagues can open: those are better in ChatGPT's own memory, and moving them into a shared vault makes them worse. The split that works is the obvious one. What only you need stays in the account. What the team relies on goes in files, where it can be read, corrected and kept.
Is this better than Obsidian or Notion for the same job?
Not always, and the differences are worth being straight about. Obsidian is the better single-player writing environment, and if your second brain is yours alone, its plugin ecosystem and local vault are hard to beat. Notion is better at structured databases and at non-technical colleagues who want a page that looks finished. Both have AI connections of their own.
Baalda's case is narrower: markdown files you own, several people editing them live, permissions set per file, and an assistant reaching them through the same permission checks as the people. If you do not need the second and third of those, the comparison gets much closer, and the Obsidian comparison and the Notion one lay out where each of them wins.
If you want the longer version of the underlying argument, what a team second brain actually is covers why personal systems stop working at work, and connecting an AI to your notes over MCP covers the protocol side in more detail.