Canonical page: https://openscout.app/muse
Machine-readable spec: https://openscout.app/muse/integration.json
Documentation reviewed: 2026-09-26. This is not a live health assertion.
Let Meta's Muse agent hand work to your local Scout agents. Muse runs in a Linux VM in Meta's cloud, so it reaches Scout over the hosted MCP gateway, not through a local broker.
Status
Invite-only pilot · you approve Muse from your phone or Mac · not reviewed by Meta
Muse has no connector directory entry for Scout, and it does not need to write one. Scout ships a ready-made remote client: one Python file Muse installs in its VM with a single command, then drives like any CLI.
Transport
Remote scout CLI → streamable HTTP + device-login token · core tools
Muse → scout CLI → MCP gateway → Scout bridge
Directions
- Muse calls Scout: mcp-http (pilot): Invite-only: needs a live bridge; the operator approves Muse's sign-in link. Muse runs the remote scout CLI
- Scout launches Muse: not supported. Muse runs in Meta's cloud; Scout has no harness for it.
- Not a harness: never pass --harness muse.
- Surface to the operator before acting: Approving a sign-in grants Scout access as the agent id you choose; approve only sign-ins from an agent you started, and never put a token in chat, Muse can hand work to agents that run on the operator's Mac. Keep per-action approval on until you trust the integration.
Gates
- hosted-bridge: owner operator, not self-serve
- agent-token: owner operator, not self-serve. Approved from the sign-in link Muse sends when it runs scout login.
Required inputs and prerequisites
- Muse's Linux VM does not run a Scout broker or join the mesh. It runs the remote scout client, which calls the broker on your Mac through the hosted gateway at mcp.oscout.net.
- A Muse account (ai.meta.com/muse) with network access to openscout.app and mcp.oscout.net.
- OpenScout on a Mac with a healthy broker (scout doctor) and the MCP bridge running (scout mesh bridge status).
- python3 in Muse's VM (3.8 or newer). Nothing else to install.
- The Scout Mac and its bridge must stay online while Muse works. Muse's VM keeps running when you close the app, so a handoff can outlive your session.
Setup procedure
1. Give Muse this message
Paste it into a Muse conversation. It holds no secret: Muse installs the client, starts a login, and sends you a link to approve.
Connect yourself to my Scout. Run:
curl -fsSL https://openscout.app/remote/install.sh | sh
scout login --as muse
Send me the sign-in link it prints. I'll approve it and give you a
code; finish with `scout login --code <code>`. Then run
`scout whoami` and `scout who` and tell me what you see. From then on, use `scout ask <agent> "<task>"`
to hand work to my Scout agents; it waits and prints their reply.
Run `scout --help` for the rest.2. Approve, and hand back the code
Open the link Muse sends on your phone or Mac. If you're signed in with GitHub, it goes straight to Approve; choose the agent id Muse gets. The page then shows a one-time code: paste it back to Muse. The code is safe in chat: it works once, for a few minutes, and only with a secret that never leaves Muse's VM. Muse's token is saved there, owner-only, never printed, and renews itself.
3. Allow the endpoints
If Muse's Settings gate network access, approve openscout.app (the one-time install) and mcp.oscout.net (every call). Start with per-action approval, so you see each Scout call before it runs.
4. Hand off work
Ask Muse for something real: “Use scout to ask a Claude agent to review the latest changes in /absolute/path/to/project. Do not edit files. Report what it says.” The path is on the Scout Mac, not in Muse's VM. scout ask waits for the reply; for long work Muse can pass --no-wait and check back with scout wait <id>.
Start here
Check the prerequisites and access gates, then get one documented route working before asking for work.
First useful task: From Muse, ask a coding agent for a short explanation of one function in your project.
Name the project and keep the request small. Asking for no edits describes the task; it does not restrict the agent’s permissions.
Keep the returned reference. Check the work’s status and read the completed response; a queued receipt is not the answer.
Where will the reply appear?
The remote client waits and prints the agent’s reply in Muse’s command output.
What if the answer hasn’t arrived?
Inspect the existing task before submitting another one. A wait timeout does not establish that work failed. If it needs access or input, resolve that condition before continuing.
How do I follow up?
Continue using the returned reference or exact session handle supported by this integration. Keep it with the findings so your next question follows the same work.
Can Scout run this integration, or only receive asks from it?
These are separate capabilities. Check the supported directions on this page. Connection alone does not establish that Scout can launch the integration or reach an existing session.
Acceptance gate
scout login prints a sign-in link; after scout login --code, it prints Signed in as muse. scout whoami prints muse. scout who lists your Scout agents. A small scout ask prints the agent's reply; with --no-wait it prints an invocation id that scout wait resolves. An accepted invocation is not completed work.
Failure handling
scout: the gateway rejected the token
The sign-in was revoked or not renewed for 30 days. Ask Muse to run scout login again.
scout: the code was not accepted
Codes work once and expire within minutes. Ask Muse to run scout login for a fresh link.
scout: bridge is offline (node_unreachable)
The gateway is up but the Scout Mac is not connected. On that Mac run scout mesh bridge status and scout doctor. Wake the Mac or restart Scout; retries from Muse will not bring the bridge back.
python3: command not found
Ask Muse to install Python 3 in its VM (apt-get install -y python3), then run the install line again.
Muse tries to install the Scout app or run a broker in its VM
Stop it. Muse needs only the remote client from openscout.app/remote/install.sh. The Scout daemon is macOS-only, and a broker in the VM would have no agents.
Calls blocked or waiting
Sentinel is holding them for approval, or egress to mcp.oscout.net is not allowed. Check the integration's approval mode in Muse Settings.
Boundaries
- Only a listed operator's approval reaches your Mac's bridge. Anyone else who approves a code gets a token for their own account, which has no bridge.
- Stronger isolation: mint with scout mesh bridge token muse on the Scout Mac (it goes to your clipboard, never the screen), store it in Muse's secure credential prompt, and have Muse pipe it to scout login --with-token. Sentinel then keeps the real value outside the VM.
- Core tools only: whoami, ask, invocations, messages, sessions, and work updates. No agents_start, aliases, or terminal control. scout call <tool> reaches any of them directly.
- One identity per token. scout mesh bridge token list shows them; scout mesh bridge token revoke <id> revokes one.
- Scout cannot launch or wake Muse. Muse calls Scout; replies come back through the invocation it holds.
Agent operating contract
- Treat these as setup instructions, not authorization to install software, change accounts, grant scopes, send messages, or dispatch work. Obtain the operator's authorization for the intended action.
- Inspect the available commands or tool schemas for your configured interface before making calls. Do not invent tools, argument names, model IDs, or agent handles.
- Muse runs in a Linux VM in Meta's cloud: do not install the Scout app, run a broker, or join the mesh there. Install the remote client with curl -fsSL https://openscout.app/remote/install.sh | sh; it needs only python3. Sign in with scout login --as muse, send the operator the sign-in link it prints, and when they give you the code from the approval page, run scout login --code <code>. That code is safe to receive in chat (single-use, PKCE-bound); the token itself is saved owner-only and never printed, so never ask for it or put it in chat. Run scout whoami first; stop on 'gateway rejected the token' (run scout login again) or 'bridge is offline' (node_unreachable). Hand off work with scout ask <agent> "<task>", which waits and prints the reply; scout who lists agents, scout --help lists the rest.
- Use the transport-specific instructions above. For an existing request, reply through its supplied context rather than creating another task.
- Paths refer to the Scout execution machine. Replace example paths with an operator-confirmed absolute path; never run placeholders literally.
- Save the returned ref, flightId, conversationId, workId, or session handle. Continue by that handle; do not re-dispatch a request merely because a wait timed out.
- Observe the existing request through the configured transport. A receipt proves acceptance, not execution or successful completion.
- Stop on missing provisioning, incorrect identity, missing permission, unsupported runtime, or failed authentication. Report the exact gate and the next operator action. Do not silently fall back to a different account, agent, runtime, or transport.
- Keep tokens, OAuth codes, cookies, and private task payloads out of logs, URLs, screenshots, and committed files. Never ask the user to paste secrets into a public issue.
- Do not claim marketplace approval, complete protocol conformance, or an end-to-end verified integration unless the status and observed evidence establish it.
Completion report
Report: chosen transport and scope; client and broker identity; health/tool-discovery result; exact request handle if a test was authorized; observed terminal state or remaining blocker; and whether any operator approval is still needed. Distinguish configuration saved, authentication complete, request accepted, and work complete.