Muse Code connectors: adding MCP servers

How connectors work in Meta's Muse Code: the mcp_servers settings format, both transports, the sandbox caveat, and a first server worth adding.

Meta's Muse Code, the terminal coding agent released in beta on August 5, 2026, can reach beyond its own repository the same way every serious agent now does: through MCP servers. If you are coming from a chat product, an MCP server is what Grok, ChatGPT and Claude surface as a "connector": an outside system the agent can call as tools.

This page is the complete picture for Muse Code. What counts as a connector, exactly how to add one, where Meta's own documentation says the risk sits, and a first server worth adding. It corrects one piece of launch coverage along the way: several day-one articles claimed the beta shipped without MCP support, and that is wrong. The shipped binary supports it, and the configuration below is Meta's own documented format.

What counts as a connector in Muse Code

Muse Code has no connectors screen and no connector catalog. It ships **zero built-in connectors**: every outside system it can reach arrives as an MCP server you declare yourself, in a settings file. That is a real difference from the chat products, where a first-party catalog (Gmail, Calendar, Drive) sits next to a custom option, and it cuts both ways. Nothing is listening until you add something, and everything you add is a deliberate act with a config line to show for it.

Connectors are also only one of three ways to extend the agent, and knowing which layer you are on matters, because they have different security properties:

Skills and hooks are the subject of their own pages ([agent skills](/glossary/agent-skill) have one here). The rest of this page is about the first row.

How to add one

Connectors live in ~/.config/muse/settings.json, under mcp_servers. The file must declare "schema_version": 1 or Muse Code refuses to start; a missing file is fine, a malformed one is not.

Two transports, and the fields differ by transport:

A local tool is a stdio entry:

{ "mcp_servers": {
    "my-tools": { "transport": "stdio", "command": "my-mcp-server", "args": [] }
} }

A hosted service is a streamable_http entry with its address and, when it needs one, an auth header:

{ "mcp_servers": {
    "workerkit": {
      "transport": "streamable_http",
      "url": "https://mcp.workerkit.ai/workers",
      "headers": { "Authorization": "Bearer pe_mgr_..." },
      "mode": "optional"
    }
} }

The one setting worth a deliberate choice is mode. It defaults to required, which aborts the run when the server is unreachable. That is the right default for a connector the task depends on and the wrong one for everything else: mark a nice-to-have server "mode": "optional" and an outage becomes a warning instead of a dead coding session.

One open question to know about: whether the beta walks MCP's browser sign-in flow for remote servers is not yet documented. Static headers are documented and work, so for a service that offers key-based auth, create the key by hand and paste it as a header. A key added by hand keeps working either way.

The gap Meta names itself

Meta's documentation is unusually direct about where the risk sits:

MCP tools are not sandboxed. Unlike shell commands, an MCP server runs as an ordinary child process or a direct network connection, outside the filesystem and network sandbox.

That asymmetry is the detail most people miss. Muse Code's shell actions run inside an OS-enforced sandbox (Seatbelt on macOS, bubblewrap on Linux) with the workspace writable and .git read-only, and its approval modes review dangerous commands stage by stage. None of that applies to a connector. An MCP server runs with whatever reach its process and its credential have, and hooks share the same exemption.

So the security review for a Muse Code connector is not "is the agent sandboxed", it is four questions about the server:

1. What can its credential reach? The whole risk is here. A connector holding a raw OAuth grant to your mailbox can read your mailbox, whatever the agent intended.
2. Can you scope it? A credential that carries named, opt-in scopes can be granted narrowly and widened deliberately. One that cannot is all or nothing.
3. Does the server hold state? A stateless server that forwards requests and forgets is a smaller target than one that stores sessions or data.
4. Can you revoke it cleanly? A per-client key you can kill without side effects beats a shared credential someone is afraid to rotate.

Any connector that answers those four well is a reasonable thing to hand a coding agent. Which brings us to a concrete example.

A first connector worth adding

The WorkerKit MCP server is a hosted remote server that answers all four questions cleanly, and it happens to solve the problem a coding agent actually has: the work around the code. Muse Code edits the repository; AI workers do the standing jobs the repository exists to serve, on their own schedules, with their own scoped app access. The server is how an MCP client reads, runs and maintains a fleet of them.

Two endpoints, one host:

Against the four questions: the fleet credential **grants no app access at all** (no tool on the server reads a mailbox, a calendar or a CRM; only workers reach apps, under their own app firewall); its scopes are named and opt-in, so a first key carrying only readWorkers and readRuns lets the agent describe the fleet and change nothing; the server **holds no state**; and keys are per client, revocable, and optionally expiring.

What Muse Code does with it once connected: run a worker out of cadence after a merge that touches what it parses, and read the receipt before leaving the terminal; debug a worker's failed run through its step-by-step event feed; set a schedule by describing it; search the public directory for a kit like Engineering Pulse before writing bespoke automation for a job a worker already does. The full walkthrough, including the AGENTS.md manners worth seeding, is in Connecting Meta's Muse Code to your AI workers.

Tips for using Muse Code connectors safely

1. Start every credential read-only. Most of the first session's value is the agent describing what exists. Widen scopes when you want it to act, not before.
2. Mark non-essential servers `"mode": "optional"`. A required server that is down aborts the run. Reserve required for connectors the task cannot proceed without.
3. Prefer scoped keys over raw account grants. A connector that can only offer "sign in as you, everywhere" fails the credential question. Look for one that names what the key unlocks.
4. Keep `--yolo` out of connector sessions. It disables the approval layer and the sandbox together. Meta recommends it only in disposable CI containers, and a session holding live credentials is the opposite of disposable.
5. Give each client its own key. Revoking a key nobody else shares is a decision with no side effects.
6. Review `mcp_servers` the way you review dependencies. It is one JSON block, and every entry is something running outside the sandbox. Prune what you stopped using.

FAQ

Does Muse Code support connectors?

Yes. Muse Code supports MCP servers, the same protocol behind custom connectors in Grok, ChatGPT and Claude, in the beta that shipped on August 5, 2026. Servers are declared under mcp_servers in ~/.config/muse/settings.json, over stdio for local processes or streamable HTTP for remote services. Some launch-day coverage claimed MCP support was missing from the beta; it is not.

How do I add an MCP server to Muse Code?

Edit ~/.config/muse/settings.json, make sure it carries "schema_version": 1, and add an entry under mcp_servers with a transport: stdio with a command for a local server, or streamable_http with a url and optional headers for a hosted one. Restart the session and the server's tools are available.

Are Muse Code MCP servers sandboxed?

No, and Meta says so plainly: MCP servers run outside the filesystem and network sandbox that contains shell commands, as do hooks. Judge a connector by what its credential can reach, whether its scopes can be narrowed, whether the server holds state, and whether you can revoke it cleanly.

Does Muse Code have built-in connectors like Grok or ChatGPT?

No. There is no first-party connector catalog and nothing is pre-connected. Every system Muse Code can reach is an MCP server you add yourself, which also means the full list of what your agent can touch is one readable JSON block.

Can Muse Code use the same MCP servers as Claude Code?

Yes, that is the point of the protocol. A remote server like mcp.workerkit.ai works from any MCP client; only the config syntax differs. Muse Code can also import agent skills from an existing .claude/skills directory, but skills are instructions, not connectors.

Does this work on Windows?

Muse Code has no native Windows build and requires WSL2. Remote connectors are unaffected by that: a hosted server like the WorkerKit MCP server runs nothing on your machine, so any environment that runs Muse Code can reach it.

The bottom line

Muse Code's connector story is bring-your-own by design: no catalog, no pre-wired accounts, one settings block that is the complete inventory of the agent's outside reach. That makes the setup slightly more manual than a chat product's connectors page, and it makes the audit far easier. Add servers whose credentials you can scope and revoke, mark the optional ones optional, and give the coding agent reach that was designed for an agent to hold, starting with the systems that keep working after the terminal closes.