Scout
DocsBlogToolsContact

What your agent reads / grokbot/agents.md

Scout + Grok Bot: agent setup contract

This is the file an agent fetches, shown with a little styling. Agents read the raw Markdown; nothing here is added or left out.

agents.md integration.json Grok Bot guide

Canonical page: https://openscout.app/grokbot
Machine-readable spec: https://openscout.app/grokbot/integration.json
Documentation reviewed: 2026-09-26. This is not a live health assertion.

Bring your local Scout agents into a Grok Bot conversation. Delegate a review, read replies, and follow a tracked result through the hosted MCP gateway.

Status

Invite-only pilot · you need an operator-provisioned bridge · Cursor Marketplace review pending (submitted 2026-09-21)

Grok Bot runs on Cursor's cloud and signs in with a Cursor account, so its connectors are Cursor Marketplace plugins. The openscout publisher application was submitted through cursor.com/marketplace/publish on September 21, 2026. Review pending; no approved listing URL is confirmed. Custom MCP setup is available for provisioned pilots.

Transport

Streamable HTTP + OAuth · mcp:core scope

Grok Bot → MCP gateway → Scout bridge

Directions

  • Grok Bot calls Scout: mcp-http (pilot): Invite-only: needs an operator-provisioned bridge
  • Scout launches Grok Bot: not supported. scout ask --harness grok-acp launches the Grok CLI, not this connector.
  • Not a harness: never pass --harness grokbot.

Gates

  • hosted-bridge: owner operator, not self-serve
  • marketplace-listing: owner Cursor review, pending. Submitted 2026-09-21.

Required inputs and prerequisites

  • Before you start: this connector reaches a Scout broker on a specific machine through a bridge that the Scout operator provisions for your GitHub account. There is no self-serve sign-up yet. If you have not been told your bridge is live, the connector will authorize and then return node_unreachable.
  • Grok Bot with custom MCP support.
  • OpenScout installed and a healthy local broker (scout doctor).
  • A provisioned Scout MCP bridge associated with your GitHub account. Provisioning is currently operator-assisted.
  • The Scout machine and its bridge must stay online. Adding an MCP server does not install Scout or provision a bridge.

Setup procedure

1. Add Scout in Grok Bot

Open Plugins settings and add a custom MCP server named OpenScout. Enter this endpoint and leave custom headers empty.

https://mcp.oscout.net

2. Authorize the connection

Sign in with the GitHub account associated with your provisioned bridge. Choose your Scout agent identity and approve core tool access.

3. Verify before delegating

Ask the client to list Scout tools, then call whoami. Confirm that the identity belongs to your intended Scout account before requesting work.

4. Make your first handoff

Ask Grok Bot: “Use Scout to ask a Claude agent to review the latest changes in /absolute/path/to/project. Do not edit files. Keep the work handle and report the result.” The directory is on your Scout machine.

Start here

Check the prerequisites and access gates, then get one documented route working before asking for work.

First useful task: Once access is provisioned, ask Grok Bot to have a coding agent explain one function in a specified 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?

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

Call whoami first. Confirm the expected identity, then run a small ask and follow its returned handle. Do not treat an accepted invocation as completed work.

Failure handling

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. Confirm HTTP transport and the exact endpoint; do not substitute a local stdio command in a remote client.

Boundaries

  • Invite-only: bridge provisioning needs the operator's relay credential. Operators run scout mesh bridge install and scout mesh bridge status on the Scout machine; see /mcp.
  • Because Grok Bot signs in with a Cursor account, connector credentials are shared across bots on the same Cursor account.
  • scout ask --harness grok-acp launches the Grok CLI, not this connector. The Grok CLI execution harness is separate; see /grok.

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.
  • Use the hosted connector's Scout MCP tools with their current schemas. Call whoami first and stop on node_unreachable: it means no provisioned bridge is online, and OAuth will not create one. scout ask --harness grok-acp launches the Grok CLI, not this connector.
  • 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.

Sources and next reads