Canonical page: https://openscout.app/cursor
Machine-readable spec: https://openscout.app/cursor/integration.json
Documentation reviewed: 2026-09-26. This is not a live health assertion.
Cursor calls Scout over MCP for agent discovery, tracked handoffs, and following work. Scout can also run cursor-agent over ACP to do project-scoped work.
Status
Cursor → Scout: local MCP available · hosted HTTP invite-only (operator provisions your bridge) · Scout → Cursor: available (cursor_acp, safe-reject)
No Scout listing in the Cursor Marketplace. The openscout publisher application (submitted 2026-09-21 for the grok-scout plugin) is awaiting review; see /grokbot. For Cursor itself, use the local MCP entry below or the cursor-scout installer.
Transport
Cursor → Scout: MCP stdio (hosted HTTP invite-only) · Scout → Cursor: cursor_acp (cursor-agent acp)
Cursor → Scout MCP → Local broker
Directions
- Cursor calls Scout: mcp-stdio (available); mcp-http (pilot): Invite-only: needs an operator-provisioned bridge
- Scout launches Cursor: available (harness cursor, transport cursor_acp, permissionMode safe_reject)
Gates
- hosted-bridge: owner operator, not self-serve. Hosted HTTP only; local stdio has no gate.
Required inputs and prerequisites
- OpenScout installed, scout on PATH, and scout doctor passing.
- For local setup, Cursor must run on the Scout machine.
- For remote setup, all hosted-bridge requirements apply, including an operator-provisioned bridge; see /mcp. Hosted access is invite-only.
- To launch Cursor from Scout: the cursor-agent CLI on PATH, signed in with cursor-agent login or CURSOR_API_KEY.
Setup procedure
1. Choose local or remote
Use local stdio when Cursor and Scout share a machine. Remote access uses the hosted HTTP configuration in the MCP guide and works only if your operator has provisioned a bridge for your GitHub account. Do not install both under the same server name.
2. Configure local MCP
Merge this entry into .cursor/mcp.json for the project, or ~/.cursor/mcp.json for your user. Preserve other MCP servers. Replace the project path with an absolute path on this machine.
{
"mcpServers": {
"scout": {
"command": "scout",
"args": [
"mcp",
"--context-root",
"/absolute/path/to/project"
]
}
}
}3. Reload and confirm tools
Open Cursor MCP settings / Customize, enable Scout, and refresh the tool list. Call whoami and confirm the intended project context.
4. Ask for a small review
Use Scout ask with the project path and a supported harness. Keep the returned handle and inspect completion before declaring the review finished.
{"projectPath":"/absolute/path/on/scout-machine","harness":"claude","body":"Review the latest changes and report findings. Do not edit files.","replyMode":"notify"}5. Or launch Cursor through Scout
This is the other direction: Scout runs cursor-agent acp (cursor_acp) as a fresh session it owns. No --model flag: the runtime uses your Cursor plan's model, and the catalog lists no Cursor models. Broker-launched Cursor runs use safe-reject permissions, so tool calls that need approval are declined.
cursor-agent login
scout runtimes --json
scout ask --project /absolute/path/to/project --harness cursor --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 Cursor’s chat, ask a coding agent to review the change you are working on without editing it.
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
Success means Scout tools are visible, whoami returns the intended identity, and a small ask produces a durable invocation/flight handle. A handle proves acceptance; inspect the flight for the eventual result.
Failure handling
scout is not found / bun: scheme error
Check scout on PATH and its installed runtime. The cursor-scout installer can probe the local command and repair a stale Node-backed shim. From a clone of oscout/cursor-scout, preview the write with bun run install:global -- --dry-run, then run bun run install:global -- --force to replace a stale entry (bun run install:project targets one project).
Remote connection cannot reach the machine
Use the MCP guide bridge checks. A successful OAuth login does not prove the local bridge is online, and OAuth does not create a bridge. If no operator has provisioned one for you, stop.
A Scout-launched Cursor run stops at a tool approval
Expected: broker-owned Cursor runs use safe-reject permissions and decline tool calls that need approval. Use them for read-only review, or run the edit in your own Cursor session.
Boundaries
- Cursor local MCP and the hosted Grok Bot connector are separate setup paths.
- Hosted HTTP access is invite-only: it needs a bridge your operator provisions. There is no self-serve sign-up.
- Broker-launched Cursor runs use safe-reject permissions. Tool calls that need approval are declined, so use them for read-only review unless you attach an approval consumer.
- Cursor's ACP mode does not load team-level MCP servers configured in the Cursor dashboard.
- Marketplace submission is not marketplace approval.
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.