Factories > Integrations

Factory MCP for coding agents

Connect any coding agent to create and operate your team's factories, send in work, continue tasks locally, and hand results back.

Factory MCP is a hosted Model Context Protocol (MCP) server that connects coding agents to your team’s factories. An agent can send work to a factory, pull down a task to continue locally, and return the result.

What you can use it for

Send work in - Turn anything from your local session into a factory task: a bug you found, review feedback, or a half-finished change.
Continue a task locally - Pull a task’s context into your own checkout, work with your own tools, and return the result to the same task.
Stay in sync - List and search tasks, read a task’s conversation, and message its foreman, the agent that orchestrates each task inside the factory.
Create a factory - Let your coding agent guide you through choosing a team, code host, repositories, factory agents, and integrations.
Edit a factory’s definition - Read the definition schema and validate a factory’s definition files before opening a pull request.

Connect and authenticate

In Warp

There is nothing to configure. When your account has access, Warp connects agent sessions to Factory MCP and handles authentication for you. To create your first factory, ask the agent to set one up — the setup prompt below is for agents outside Warp.

Set up with your coding agent

Paste this prompt into a coding agent that can run commands and configure MCP servers:

Set up a factory for me. Read https://docs.warp.dev/factories/factory-mcp.md, follow the setup instructions for your coding environment to connect to and authenticate with Factory MCP, then use Factory MCP to onboard me.

The agent connects to Factory MCP, opens a browser sign-in where you log in or create a Warp account, then walks you through the same choices as the setup wizard: team, code host, repositories, agents, and integrations. It finishes by linking your new factory’s dashboard. If the Warp Factories web app is still open to its setup screen in your browser, refresh the page to pick up the new factory.

In other MCP clients

Factory MCP is a streamable HTTP server at https://app.warp.dev/api/v1/mcp/factory. Point any MCP client that supports remote servers at that URL; on first connect, the client opens a browser so you can sign in and approve access.

With Claude Code:

claude mcp add --transport http --scope local warp-factory https://app.warp.dev/api/v1/mcp/factory

In clients that use the mcpServers JSON format, such as Cursor:

{
  "mcpServers": {
    "warp-factory": {
      "url": "https://app.warp.dev/api/v1/mcp/factory"
    }
  }
}

warp-factory is the server’s name in your client. One connection reaches every factory you can access.

For Codex and other clients, follow the client’s own remote-server instructions with the same URL.

Automation that runs without a person present, such as a CI pipeline or a headless server, can’t complete the browser sign-in. For those cases, authenticate with an agent API key instead, passed as a bearer token:

{
  "mcpServers": {
    "warp-factory": {
      "url": "https://app.warp.dev/api/v1/mcp/factory",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Send new work to a factory

To create a task, your agent calls send_task with the target factory, a title, and a note. The note is what the foreman starts from, so a good one states the goal, the relevant context and constraints, and any work already done. The foreman takes it from there and reports progress on the task’s conversation.

If the new task builds on local changes, push the branch or open a pull request first and reference it in the note, so the factory can see that work.

Pick up a task and work on it locally

Find the task. Your agent locates it with list_tasks or search_task, or resolves a reference you give it with get_task: a task or run URL, a GitHub pull request, a Slack permalink, a Linear or Jira issue, or a branch name.
Pull down the context. Calling get_task with start_working=true returns the task’s status, run history, and suggested Git commands for setting up an isolated worktree in a local clone. Factory MCP never modifies your files; your agent runs the setup itself.
Coordinate while you work. message_foreman sends progress, questions, and blockers to the task’s foreman, and get_conversation reads the replies. Messaging keeps the factory informed but doesn’t move the task or hand anything back.
Commit and push. Validate the change, then push the branch. The factory can’t see uncommitted or unpushed work.
Hand the task back. Your agent calls send_task with the task’s ID, the pushed branch or pull request URL, and a note covering what changed, what was validated, and what remains. The work returns to the same task, and the foreman decides the next step.

When nothing remains for the factory to do, complete_task closes the task out. Handing work back doesn’t complete a task by itself.

Get notified when a task needs you

Sending work to a factory means you’re no longer watching it. To be notified when a task needs attention or finishes, ask for a notification when sending or returning work: your agent calls list_notification_routes to see the destinations available to you in that factory, such as a Slack DM or a Linear issue, and passes your choice to send_task. Delivery is best-effort, so treat notifications as a convenience rather than a guarantee.

Tool reference

Your MCP client fetches the full input schemas from the server, and tool results include links that open the corresponding task or run in the factory’s factory dashboard. The onboarding tools from list_teams through create_factory require browser sign-in.

Tool	What it does
`list_factories`	Lists the factories you can access.
`get_factory_file_schema`	Returns the JSON Schema documents for factory definition files, as a catalog or one document at a time.
`validate_factory_files`	Validates a complete factory definition tree without saving or applying it.
`list_teams`	Lists current memberships and first-time joinable team choices.
`create_team`	Creates the authenticated user’s first team with a confirmed name.
`join_team`	Joins a team selected from the first-time discovery choices.
`get_team_funding_status`	Checks first-team credit readiness and returns the browser checkout step when required.
`list_forge_repositories`	Lists repositories available through a team’s connected GitHub or GitLab account.
`list_tracker_scopes`	Lists the Linear teams or Jira projects that can be scoped to route issues to a new factory.
`start_connection`	Starts or checks setup for GitHub, GitLab, Slack, Linear, or Jira.
`get_connection_status`	Checks whether a browser authorization flow completed.
`create_factory`	Creates a factory with the selected repositories, integrations, and optional factory agents.
`list_tasks`	Lists the tasks in one factory, with filters such as creator, stage, and date.
`search_task`	Searches task titles across all factories you can access.
`get_task`	Reads a task’s status, run history, and outputs. Accepts a task ID or a reference such as a URL, issue, pull request, or branch. With `start_working=true`, also returns local setup guidance.
`message_foreman`	Sends a message to a task’s foreman.
`get_conversation`	Reads a task’s foreman conversation.
`send_task`	Creates a new task, or hands work back to an existing one.
`list_notification_routes`	Lists the notification destinations available to you in a factory.
`complete_task`	Marks a task complete.

Definitions as code - Every file and key in a factory definition, the JSON Schema behind them, and how to validate a change.
Factory agents - The foreman and the other agents that carry out a factory’s tasks.
How Warp Factories work - The task lifecycle and the agents that move work through it.
Warp Factories quickstart - Create a factory and send it its first work item.