Short answer
Yes. Raycast AI is an MCP client, so pointing it at a Baalda vault over HTTP gives it your team's markdown notes. Raycast auto-approves read-only tools and asks you to confirm the rest, so the server's own tool annotations decide which calls skip the prompt. Nine of Baalda's twenty-two are read-only.
Every agent that reaches a team's notes negotiates two separate permissions, and almost nobody notices that different software decides each one. The client decides when to stop and ask you. The server decides what asking is even required for. Raycast is a clean case because it publishes its rule, and the rule puts the interesting half on the other side of the connection.
Raycast's manual states it plainly: MCP tools follow the same permissions as AI Extensions, which means Raycast auto-approves read-only tools and requires user confirmation for the others. That is a sensible default for a launcher. It also means the list of things your launcher may read without stopping to ask is written by whoever wrote the MCP server, in the server's own tool definitions, not by you at setup time.
So the useful question is not whether Raycast can reach your notes. It can, over MCP, and the setup is a form. The question is which calls it will make silently once it can. Baalda is a team second brain where that answer is checkable: notes are plain markdown files on your own disk, several people edit the same file at once over a CRDT, access is set per file and per folder, and it serves MCP at POST /api/mcp. Nine of its twenty-two tools are marked read-only, which is exactly the set Raycast will wave through.
What does Raycast actually remember on its own?
Less than people assume, and about a different subject.
Raycast AI has a Memory feature. Its manual describes what goes in: your role and professional context, projects you are working on, technical preferences and the tools you use, and your communication style. The mechanism is a summariser. Every few hours Raycast collects your recent AI Chat and Quick AI conversations, sends them to the model along with your current memory, and the model distils the lot into an updated summary. It is stored locally, synced through Cloud Sync when that is on, and you can read and edit it in Settings, AI, Personalization.
Read that list again and notice what is absent. It is a profile of a person. It is built from your own chats, by a model, on a timer. There is no step at which a colleague's decision enters it, and no step at which yours leaves for anyone else. Raycast is explicit that only chat contents are used to build it.
That is the correct design for a launcher's assistant and the wrong shape for a team's knowledge. The same split shows up in every agent we have looked at: Claude Code's memory never leaves the machine it ran on, and the fix is always the same one, which is that the durable half has to live in a file a person can open and correct. What makes Raycast worth a post of its own is the speed of the capture surface. Two keystrokes from anywhere in macOS is the lowest-friction way to write something down that most teams have installed. If that path writes into a per-account summary, the friction saved is spent twice over later.
How do you connect Raycast to a vault of markdown notes?
Through the same form every MCP server uses. Run the Install MCP Server command, or use Install New Server inside Manage MCP Servers, and fill it in.
Raycast offers two transports. Standard Input/Output is a local process Raycast launches and pipes JSON-RPC over stdin and stdout, which covers anything you would run from a terminal. HTTP is a remote endpoint speaking MCP over HTTP, including the Streamable HTTP variant, and it is the only transport available on iOS. Baalda is the second kind: one route on the server that already holds the notes, so you pick HTTP and give it the URL.
Name Baalda
Transport HTTP
URL https://your-server.example.com/api/mcp
OAuth Type DynamicFor HTTP servers Raycast handles the whole auth flow, in one of two modes. Dynamic OAuth uses Dynamic Client Registration with PKCE: you choose Sign In and Raycast registers itself as a client. Static OAuth takes a Client ID and optional Secret that you supply, which is what services like Slack require. Either way, tokens are stored encrypted, per server, and an HTTP server with OAuth prompts you to sign in before any of its tools become available.
Dynamic is the path to use here, because the discovery it depends on is already wired. A 401 from Baalda's MCP endpoint carries a WWW-Authenticate header naming the server's protected-resource metadata, per RFC 9728, and the origin serves both /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server. That chain is what lets a client find the authorization server and register itself without a human pasting anything. The alternative stays available: the form has an HTTP Headers field, and a per-person token minted in Vault Settings, MCP works as a plain bearer. Baalda's own MCP setup docs cover both.
Once a server is installed, you scope a query to it by typing @ and the server's name, the way the manual's own example does with @linear what's assigned to me?.
One cost worth stating before you plan around it: MCP in Raycast is marked Pro Exclusive. Raycast Pro is $8 a month and Teams Pro is $12 per user a month, both read from Raycast's pricing page on 13 October 2026. MCP arrived in Raycast 1.98.0 on 8 May 2025 with local stdio servers only; HTTP servers, which is what a remote vault needs, landed in 1.100.0 on 11 June 2025.
Which calls will Raycast make without asking?
The ones the server has declared read-only. This is where the two halves meet, and it is the reason to care what a server's tool definitions say.
MCP lets a server attach annotations to each tool, including readOnlyHint and destructiveHint. They are hints, not enforcement: nothing stops a badly behaved server from marking a delete as read-only, which is why a client's auto-approval is only as good as the server it is pointed at. Baalda sets all five annotation fields explicitly on every tool, and groups them, so the classification is one short list rather than twenty-two separate judgements:
| Group | readOnlyHint | destructiveHint | Tools |
|---|---|---|---|
| Read | true | false | list_vaults, list_folders, list_notes, read_note, search_notes, list_attachments, read_attachment_text, list_resource_access, get_access_default |
| Create | false | false | create_note, append_note, edit_note, create_folder |
| Move | false | false | move_note, move_folder, move_file |
| Replace | false | true | update_note |
| Delete | false | true | delete_note, delete_file, delete_folder |
| Access | false | true | manage_access, set_access_default |
Nine read, thirteen not. Applied to Raycast's rule, that means a @baalda query which searches the vault and reads three notes runs start to finish without interrupting you, and the moment it wants to write, move, replace, delete or change who can see something, you get a confirmation. Replacing a note's whole body is flagged destructive even though nothing is deleted, because it can drop existing text. Moving one is not, because the same move twice lands in the same place.
That is the behaviour you want from a launcher. It is also why the grid above is worth reading for any MCP server you install, not just this one.
What does the consent screen actually grant?
One vault, chosen by you, at the moment you connect.
An OAuth access token says who the caller is and nothing about where it may act, so the vault has to come from somewhere. In Baalda it comes from the consent screen. Sign in during Raycast's Dynamic OAuth flow and you get a page listing every vault you are a member of, each with your role in it, and you pick one. It states the grant in three lines: read and search notes you can access, create, edit and organize notes on your behalf, and only within your existing sharing permissions.
Three details make that more than a dialog box.
- The picker is not skippable. The underlying OAuth plugin issues a code straight away unless the request asks for consent, and MCP clients generally do not ask. Baalda forces the consent prompt on every authorize itself, which is the fix for a real bug: a client whose user was already signed in in the browser used to get a token with no vault attached, and every call it made then failed once that person belonged to two vaults.
- The binding is written before consent completes, and only after the server re-checks that you are genuinely a member of the vault you selected, because the selection is user-supplied input. It is stored per client and per user, so consenting again retargets that same Raycast install at a different vault rather than accumulating grants.
- Membership is re-checked on every request, not once. Lose access to the vault and the live token stops working on the next call.
Downstream of that, nothing is special about OAuth. The resolved caller is the same shape a hand-minted token produces, so every permission check is identical either way, and the per-file access that makes a team second brain workable applies to the launcher exactly as it applies to the desktop app.
Where does this not help?
Four places, and they are not small.
Two of the auto-approved tools read the access list itself. list_resource_access returns every member's effective access to a folder or file, and get_access_default returns what a new member sees on the day they join. Both are genuinely read-only, both are correctly marked so, and both are therefore in the set Raycast runs without a prompt. They are owner and admin only, so the ceiling is your own role. But if you are an admin, "who can see this" is a question a launcher can answer silently, and that is worth knowing before you connect one.
The grant is shaped like a person, not like a job. A Baalda connection resolves to one user in one vault, and there is no per-connection tool list or path prefix. Raycast sees what you see. If you want it to see less, the answer is a member account with narrower access that connects on its own, not a cleverer token. The difference from a workspace-wide connector is only that access in Baalda is already per folder and per file, so a narrow account is something you can actually build.
There is no free path. MCP is Pro Exclusive in Raycast. Baalda is free to run locally and open source under Apache-2.0, but the client side of this setup is a subscription, and no amount of self-hosting changes that.
The phone will not reach your laptop. Raycast on iOS supports HTTP transport only, which is fine in principle, but a vault served from a machine on your desk is not reachable from a phone on cellular. Mobile capture into a self-hosted vault means the server is somewhere with an address, which is a deploy decision, not a setup field.
And the honest comparison: if you are one person who wants fast capture and does not need anyone else in the notes, Raycast's own Memory plus a local Obsidian vault is less machinery for the same result, and Obsidian is better at the single-player parts than anything we would claim. The case for routing a launcher through a shared vault starts at the second person, and it is really about the third, when nobody can remember who decided what.