Delegate work from Claude Code to Uno through MCP

What moves to the cloud?

The delegation creates a separate Uno session with your instructions and selected repositories. It is useful for a bounded task that can proceed while you continue other work: reproduce a bug, add a missing test, or implement a small change with clear acceptance criteria. The originating Claude Code conversation remains your place to request and inspect that work.

This connection does not transfer your terminal process or its full conversation into a cloud machine. Include the repository context, decisions, and relevant constraints in the task you delegate. If the work depends on uncommitted local edits, make those changes available through your repository workflow before asking a separate session to build on them.

Claude Code supports remote HTTP MCP servers and browser authentication. Uno's hosted endpoint uses Streamable HTTP and OAuth, with access scoped to the workspace you select. Claude Code MCP documentation; Uno MCP overview.

Connect Claude Code to Uno

Finish Uno sign-in and workspace onboarding first. Your account must belong to the workspace you want to use. Add the server from your terminal:

claude mcp add --transport http uno https://api.uno.engineering/mcp

Open /mcp inside Claude Code, select Uno, and authenticate. The browser flow asks you to sign in, choose a workspace, and review the permissions. Complete that flow before attempting a task. You do not need to paste an API key into the command. Connection instructions.

Start with a read: ask Claude Code to use Uno to list your tasks and repositories. Check the workspace name and repository list. A successful read confirms that you authorized the intended workspace before a session can consume its credits.

If the connection fails, check the client's MCP status and complete authentication again. The MCP troubleshooting guide covers connection and execution problems separately. A connected server can still encounter repository, billing, or model access checks when starting work.

Give the session enough information to finish

A good delegation names the repository, the observed problem, and a check the reviewer can repeat. For example, after confirming which repository contains your web app:

Use Uno to start a session in the web repository.
Fix the search results page when the API returns an empty list.
Keep the current permissions and response shape.
Add a regression test for the empty state and run it.
Report the session link and initial execution status.
When finished, report the pull request and test results.

The remote uno_create_session tool accepts the objective, selected repository IDs, and a request UUID. Your client should discover IDs from uno_get_workspace and follow the server's advertised tool schema. Let the tool supply valid structure; do not copy fixture UUIDs from an example into a real request.

Successful creation records the initial message and turn together. The returned execution_status can be queued before execution starts. Keep the session link, conversation ID, and initial turn ID so later checks refer to the same work. Start and follow work.

Confirm execution and recover uncertain responses

Ask your client to read the returned conversation's persisted status. Queued work has been accepted; running work has begun execution. A completed turn still needs its messages, activity, and resulting changes reviewed. Environment readiness alone cannot tell you whether the agent has started or finished.

If the creation call times out, retry with the same request UUID and identical arguments. A new UUID represents a new operation and can create another session and execution. Before recovering a partial result, inspect any returned session ID. The workflow documentation also covers older prepared sessions that have no initial turn.

To change work already running, use the documented steering flow. Read the active turn and runtime capability first; retain the steering request ID and check delivery. Acceptance confirms that Uno saved the guidance. Delivery confirms that the runtime acknowledged it. Inspect the eventual result before reporting that the requested change is complete.

Make status checks with backoff. While waiting, keep the summary precise: accepted and queued, executing, blocked, or completed with the evidence available. That is more useful to the person reviewing the task than treating every successful tool response as completion.

Keep the connection and the review policy clear

Connecting Claude Code to Uno lets the external client operate in Uno. A workspace MCP connection does the other job: it gives Uno tools from another service. Configure each direction only for the workflow you need.

To change workspaces, revoke the connection in Uno and authenticate again. Revoke it in Uno to end server-side access even if you already removed the server from Claude Code. Open MCP connections to manage that access.

Before merging the delegated change, inspect its diff and reproduce the acceptance check. Keep a session link beside the pull request so a teammate can understand the instructions and evidence. Use the verification guide to decide what evidence your particular task requires.