Run Devin on your project.Let it call your agents.
Scout runs Devin on a local project. The Devin CLI and Devin cloud can call your agents (unvalidated).
Scout → Devin: available (devin_acp, auto-approve) · Devin CLI → Scout: local MCP, unvalidated · Devin cloud → Scout: unvalidated (hosted MCP, invite-only)
Use supported agents you have installed, authenticated and connected.
~/dev/app $ scout ask --project ~/dev/app --harness devin --notify "Fix the flaky test."
working…accepted · ref 6a3c
~/dev/app $ scout wait 6a3c
working…completed · 3m 02s
devin replied with a diff for you to review:
tests/wait.test.ts+4 −2 · awaits the ref before asserting.
~/dev/app $
Devin calls Scout
Unvalidated
MCP (local) · unvalidated, MCP (hosted) · unvalidated
Let the Devin CLI call Scout ↓Replies reach your open session
Not documented
The guide doesn't say. Follow the returned ref.
Start here
- 01 · Connect
Get one route working
Check the prerequisites and access gates, then get one documented route working before asking for work.
Follow the setup → - 02 · Try
Your first useful task
Use the local Devin route to inspect one small change. Broker-run Devin auto-approves tools; a request for no edits is not a permission restriction. Check the separate access gates before trying Devin cloud.
Name the project and keep the request small. Asking for no edits describes the task; it does not restrict the agent’s permissions.
- 03 · Read
Wait for the answer
Keep the returned reference. Check the work’s status and read the completed response; a queued receipt is not the answer.
Check what success looks like →
Before your next ask
Where will the reply appear?
Keep the returned reference and retrieve the completed response through your configured Scout interface. Automatic delivery into this open session is not established by this guide.
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.
Set it up
Fastest
Give this to Devin
Connect yourself to Scout for me. Read openscout.app/devin/agents.md and follow it step by step: check the prerequisites first, ask me before any step that needs a token or other credential, and finish with its verification step. Tell me what you verified.
- reads agents.md
- checks prerequisites
- asks before any credential
- runs the verification
You need
- OpenScout installed and a healthy local broker (scout doctor).
- To run Devin from Scout: the Devin CLI installed on the Scout machine and signed in once, interactively. Scout reads the stored CLI credentials or WINDSURF_API_KEY.
- For the local MCP door: the Devin CLI running on the Scout machine, with scout on PATH.
- For the hosted MCP door: permission to manage MCP servers at the selected Devin scope, plus an operator-provisioned Scout MCP bridge associated with your GitHub account. Hosted access is invite-only.
- For the hosted MCP door: the Scout machine and its bridge must stay online. Adding an MCP server does not install Scout or provision a bridge.
Run Devin from Scout
Start here- 01
Door 1 · Run Devin from Scout (available)
Install the Devin CLI, sign in once, and confirm devin is ready in runtime discovery. Scout then starts devin acp as a fresh session it owns. Warning: Scout runs Devin with tool approvals auto-accepted. Devin can edit files and run commands in that project without asking. Only point it at a checkout you are willing to let it change, or say 'do not edit' in the task and review the diff.
brew install --cask devin-cli # or: curl -fsSL https://cli.devin.ai/install.sh | bash devin --version # then sign in with the Devin CLI once, interactively scout runtimes --json # confirm "devin" is ready scout ask --project /absolute/path/to/project --harness devin --model swe-2-high --notify "Review the latest changes; do not edit files."
Let the Devin CLI call Scout
- 01
Door 2 · Let the Devin CLI call Scout (local MCP, unvalidated)
Register scout mcp as a stdio server in the Devin CLI on the Scout machine. -s project writes .devin/mcp_config.json; -s local keeps it out of commits. This path needs no hosted bridge. It has not yet been verified end to end for Scout; record the result of your first run.
devin mcp add -s local scout -- scout mcp --context-root /absolute/path/to/project devin mcp list
Connect Devin cloud
Unvalidated and invite-only.
- 01
Door 3 · Connect Devin cloud (hosted MCP, unvalidated, invite-only)
Setup candidate · not yet verified end to end · needs an operator-provisioned bridge (invite-only). In Devin open Customize → MCPs, then Add MCP → Add custom MCP. Name it Scout and select HTTP (Streamable HTTP).
https://mcp.oscout.net - 02
Door 3 · Choose OAuth and access scope
Select OAuth authentication. Choose Personal for your individual pilot account where available. Organization access shares a connection: involve the administrator and use an appropriate shared account.
- 03
Door 3 · Save, then connect
Save the configuration, choose Connect, and complete GitHub OAuth with the account associated with your Scout bridge. Do not supply an invented client ID or static token. OAuth does not create a bridge.
- 04
Door 3 · Test listing tools
Use Devin’s Test listing tools after saving. Then start a small session, call Scout whoami, and confirm the account. If this fails, stop and record the exact error before attempting any work.
Done when
- Door 1: the ask returns a ref and scout wait reports a completed Devin reply; review any diff Devin produced.
- Doors 2 and 3: successful tool listing, correct whoami identity, and one tracked ask with a retrievable result.
- Doors 2 and 3 have not yet been verified end to end for Scout in Devin.
If it breaks
- devin is not ready in scout runtimes
- Confirm devin is on PATH (or set DEVIN_CLI_BIN), then sign in with the Devin CLI interactively once. Scout skips ACP authentication because the browser sign-in cannot run headless.
- Devin changed files you did not expect
- Broker-owned Devin runs auto-approve tool calls. Review the diff in the checkout, and say 'do not edit files' in review tasks. Use a disposable checkout for anything else.
- node_unreachable
- On the Scout machine run scout mesh bridge status. Confirm the broker, machine, and bridge are online. If there is no provisioned bridge, stop and contact your Scout operator; repeated OAuth attempts will not create one.
- OAuth fails or the wrong identity appears
- Check the signed-in GitHub account and connector authorization. Reconnect to the intended account before running tools. Never paste tokens into a chat.
- No tools appear
- Save the MCP configuration, reconnect, and refresh the client tool list. For Door 3 confirm HTTP transport and the exact endpoint; do not substitute a local stdio command in a remote client.
- Add custom MCP is missing
- Ask the Devin administrator for Manage MCP Servers permission or use Suggest MCP Integration. Do not change organization settings without authorization.
Where it stops
- Scout runs Devin with tool approvals auto-accepted (permissionMode auto_approve); Devin otherwise waits indefinitely on its first ACP tool call. There is no per-ask permission switch yet.
- Doors 2 and 3 are candidates based on documented MCP support, not verified Scout integrations.
- Hosted MCP access is invite-only: it needs a bridge your operator provisions.
- Installing a plugin and authorizing its MCP connection are separate steps.
- Do not claim a Devin marketplace listing or approval.
- High-trust local developer pilots. Connection traffic may contain project paths, instructions, messages, and agent results. Data and privacy.