Canonical page: https://openscout.app/opencode
Machine-readable spec: https://openscout.app/opencode/integration.json
Documentation reviewed: 2026-09-26. This is not a live health assertion.
Scout runs OpenCode over ACP with any model OpenCode is configured for; OpenCode can also call Scout over local MCP or shell tools.
Status
OpenCode → Scout: available (local MCP) · Scout → OpenCode: available (opencode_acp)
Use native MCP configuration and the shared Scout skill. No dedicated Scout marketplace package for OpenCode is claimed.
Transport
Scout → OpenCode: opencode acp (ACP over stdio) · OpenCode → Scout: local MCP (type: local)
OpenCode → Scout → Coding agents
Directions
- OpenCode calls Scout: mcp-stdio (available)
- Scout launches OpenCode: available (harness opencode, transport opencode_acp)
Required inputs and prerequisites
- OpenScout installed and a healthy local broker (scout doctor).
- OpenCode installed and authenticated on the Scout machine.
- An authorized project path and a supported destination runtime.
Setup procedure
1. Configure the local MCP server
Merge this into opencode.json without replacing other settings. OpenCode uses the mcp key and a command array; replace the project path.
{
"mcp": {
"scout": {
"type": "local",
"command": [
"scout",
"mcp",
"--context-root",
"/absolute/path/to/project"
],
"enabled": true
}
}
}2. Confirm tools and identity
Restart or refresh OpenCode’s MCP connection. Ask it to call Scout whoami and verify that the intended project and actor are represented.
3. Ask for a small review
Ask the connected agent to use Scout for a review in your actual project directory. Route by project and capability, keep the returned handle, and inspect the result. Use the current tool schema instead of guessing a recipient name.
4. Or ask Scout to run OpenCode
Check the installed runtime and authentication (opencode auth login) before dispatch. Scout runs opencode acp (opencode_acp) as a fresh session it owns, separately from configuring OpenCode to call Scout. opencode-go/glm-5.2 is the catalog default; pick another model from scout runtimes --json.
scout runtimes --json
scout ask --project /absolute/path/to/project --harness opencode --model opencode-go/glm-5.2 --notify "Review the latest changes; do not edit files."Start here
Check the prerequisites and access gates, then get one documented route working before asking for work.
First useful task: From OpenCode, ask another agent to explain one failing test and return a suggested next step.
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?
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.
Acceptance gate
Confirm the expected identity and project context, request one small authorized review, and retain its handle. Observe the terminal result before reporting success.
Failure handling
Scout is not found or cannot connect
Check scout on PATH and run scout doctor in the same environment as the client. A desktop app may have a different PATH from your terminal.
Requested runtime is unavailable
Inspect scout runtimes --json and finish that runtime’s setup. Do not silently choose a different harness or model.
OpenCode drops the Scout server at startup
OpenCode gives a local MCP server 5000 ms to start by default. If scout mcp starts slowly (cold start or a broker wake), add "timeout": 15000 to the scout entry and restart OpenCode.
Boundaries
- This is a local developer pilot. Client permissions and runtime availability still apply.
- Installing a host package does not provision hosted access.
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.
- For requested work or a reply, use Scout ask. Prefer projectPath plus a supported harness for fresh work. Use replyMode: notify for asynchronous work.
- Use messages_send only for one-way FYIs with no owned next step. Respond to an existing ask through its supplied reply context.
- 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 an ask through invocations_get / invocations_wait using the returned handle and current tool schema. 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.