Use coding agents from an MCP client

An MCP-capable client can use Scout to ask a coding agent for work and retrieve its answer. Your client supplies the instruction. Scout routes it to an agent with access to the project. The returned work handle lets you inspect progress and read the result.

That means a conversation in one tool can reach a coding agent in another environment. You might ask what a component does, investigate a product requirement, or request an independent opinion on a change. You need a supported connection and appropriate project access; the title of your job does not change those requirements.

This guide explains that round trip, including what we observed while preparing it. For a specific pairing, see Claude Code and Grok or the coding-agent collaboration field guide.

Choose your starting point

A tool exposing an MCP server lets clients call its tools. To initiate the workflow here, your starting tool must be an MCP client, or have another supported way to call Scout. A design tool exposing documents through MCP does not, by itself, establish that you can invoke coding agents from inside its interface.

Muse is included to make another distinction clear: a remote CLI can reach the same coordination system without Muse acting as a native MCP client. Follow its specific setup instructions rather than pasting a local stdio configuration into a cloud environment.

The four pieces of the connection

Your client conversation
        |
        | Scout tools through a supported connection
        v
Scout broker: routes and records the request
        |
        v
Agent session: reads the project and performs the task
        |
        v
Recorded result: retrieved by your client using the work handle

For the hosted route, an authenticated gateway and online bridge connect the client to the broker. The project directory belongs to the machine doing the work. A path on your laptop does not automatically identify an accessible directory in a cloud VM or on another host.

The agents collaborate as peers. Either can ask a question, propose an approach, inspect an artifact, or perform an agreed change. Choosing Claude Code, Codex, Grok, or another runtime determines the execution environment and available tools; it does not assign a permanent role.

Connect once, then verify the identity

Use the quickstart to prepare Scout, then follow the MCP setup guide for your client and transport. Preserve existing client connections when adding Scout.

Before requesting work, ask your client to list the available Scout tools and call whoami. Check that the identity and project context are the ones you intended. Tool availability can differ between local and hosted connections.

Hosted access has an additional prerequisite: the Scout machine and its provisioned bridge must be online. An OAuth login authorizes a connection; it does not install Scout or create the bridge. If the hosted route cannot resolve a worker and the required start tool is unavailable, have the operator prepare an appropriate target on the Scout machine. Do not assume every local launch capability is exposed remotely.

Make the first request small and useful

Here is a prompt you can adapt for a product question:

Use Scout to ask a Claude agent in /absolute/path/on/scout-machine:
Find where the invitation dialog's role options are defined. Explain what
each option changes, and cite the relevant files. Do not edit files or
run tests. If the project doesn't establish an answer, mark it unknown.
Keep the returned work handle and retrieve the completed answer.

For a designer, the question might be which screens use a shared component. For a PM, it might be how the current product handles an expired invitation. These are examples, not claims that Scout already understands your product or has access to your planning tool.

The corresponding arguments to Scout's ask tool look like this. Replace the project path and instruction with your own:

{
  "projectPath": "/absolute/path/on/scout-machine",
  "harness": "claude",
  "body": "Explain the invitation role options with file references. Do not edit files or run tests.",
  "replyMode": "notify"
}

An agent-card or project request can create fresh work. It does not necessarily reach a conversation you already have open. Use an exact session or returned continuation reference when that distinction matters.

The instruction to avoid edits defines the task; the receiving environment's permissions determine what it can actually do. Keep those permissions appropriate to your pilot.

Read the result, not just the acknowledgment

An accepted request returns identifiers such as flightId and bindingRef. Save them. A queued state means Scout accepted the work; it says nothing yet about the answer.

If a completion notification is not scheduled, call invocations_wait or invocations_get with the returned flightId. Inspect the terminal state and response. A bounded wait timing out only ends that wait. Inspect the same work before creating another request.

For a useful result, look for the answer, supporting file references or artifacts, and any unresolved questions. If the agent reports a file, confirm that it is accessible from the environment where you intend to read it.

What we observed on October 2, 2026

While preparing this article, we used the local Scout MCP interface to request a read-only investigation from a Claude agent. The request returned a queued receipt with a flight and binding reference. The receipt said no MCP notification was scheduled. Reading the same flight later returned a completed state and the requested source-referenced answer.

That demonstrates the local request-and-result path. It does not verify a Grok Bot or Muse client, cross-machine artifact transfer, or automatic return to every host's open conversation.

We also attempted a follow-up through the binding reference. It failed closed with an ambiguous-session response. A retry using the exact route suggested by the broker timed out without a receipt, leaving that follow-up unconfirmed. We recorded the issue for investigation. The first answer remained retrievable.

This distinction matters when you try the workflow: a successful first answer and a successful continuation are separate observations.

Continue with an explicit target

For the MCP interface, the normal continuation form is an ask with to set to ref: followed by the receipt's binding reference:

{
  "to": "ref:YOUR_BINDING_REF",
  "body": "Which part of your answer is established by the code, and which part is an assumption? Do not edit files.",
  "replyMode": "notify"
}

Replace the placeholder with the reference from your own receipt. If the broker reports ambiguity, inspect the suggested exact session route and confirm its identity. If a call times out without a receipt, determine whether work was created before retrying; otherwise you risk duplicate work.

A new agent request will need the relevant context again. Provide the question, accepted decisions, source artifacts, and allowed actions. Scout coordination does not automatically give one agent another agent's entire transcript.

Where this is useful

Start with a question that benefits from project access or a second agent's tools. The receiving agent might inspect the actual implementation while you remain in the conversation where the product or design question arose.

For longer work, keep three things visible: the current question, the exact artifact or revision being discussed, and the returned work handle. Those make it easier to resume after the first answer and to distinguish a completed result from a waiting task.

Choose your entry point: local MCP, Claude Code, Cursor, Grok Bot, or Muse. Each setup page documents its prerequisites, connection direction, and limits. OpenScout remains a high-trust developer pilot; a connected client retains its own permissions, provider, and execution environment.