MCP access

The MCP server gives cloud or hosted agents a standard way to work with Overlord missions without the desktop app. A supported assistant can read mission context and use approved Overlord actions from its own interface, still following workspace permissions and the mission lifecycle.

Use the connector setup flow for your assistant, then confirm access with ovld doctor. Do not paste user tokens into prompts or source files.

What it does

The MCP server exposes the mission workflow to remote agent runtimes. Use it for:

• listing and reading missions
• creating missions from agent workflows
• posting updates and deliverables
• integrating Overlord into a broader orchestration system

Available tools

The hosted server advertises these mission-lifecycle tools:

Tool	What it does
overlord_resolve_project	Resolves a project the user identifies by id, slug, name, or repository metadata.
overlord_create_project	Creates a workspace project (asks the user to choose a workspace when memberships are ambiguous).
overlord_list_project_statuses	Lists one project’s board columns (names and order are per project; the status type is not).
overlord_search_missions	Searches mission groups with matching objectives and deliveries; compact detail is the default.
overlord_load_mission_context	Shows one mission’s objectives, history, artifacts, and shared context. Pass objectiveId to read a specific objective.
overlord_list_deliveries	Reads normalized delivery summaries for one mission. A display id such as coo:756.k7xm supplies the mission.
overlord_create_mission	Creates a draft mission in a project you specify, or an account-owned inbox item when no project is given (never chooses a project for you).
overlord_create_inbox_item	Creates a private, account-owned unassigned task capture.
overlord_add_objectives	Appends draft objectives to an existing mission.
overlord_update_objective	Turns auto-advance on or off and/or edits instruction text on a draft or future objective. Requires objectiveId (UUID or display id).
overlord_launch_objective	Queues the normal execution request for one objective. Requires objectiveId (UUID or display id) and agent. Does not attach this agent.
overlord_reorder_future_objectives	Replaces one mission’s complete future-objective order.
overlord_delete_missions	Soft-deletes 1–100 missions (also soft-deletes their live objectives) atomically. Requires confirm: true after the resolved list is shown to and approved by the user.
overlord_delete_objectives	Soft-deletes 1–100 objectives (also removes their live Run Queue membership) atomically. Requires confirm: true after the resolved list is shown to and approved by the user.
overlord_list_run_queues	Reads compact or full live Run Queue state before a mutation.
overlord_reorder_run_queue	Atomically replaces every entry in one Run Queue.
overlord_queue_objective	Adds, moves, or removes one objective in the project Run Queue, including front or rank placement. Requires objectiveId.
overlord_manage_run_queue	Creates, updates, deletes, or reorders queue definitions (full-scope token), or retries one held entry with action: 'retry_entry'.
overlord_attach_session	Starts requested work on a mission and opens an MCP session. Pass objectiveId to pin which objective runs.
overlord_update_session	Posts progress, decisions, or discussion updates to an attached session.
overlord_deliver_session	Delivers completed work for an attached session.
overlord_add_artifact	Creates a mission artifact mid-turn without delivering.
overlord_update_artifact	Revises an existing mission artifact in place (label, Markdown content, and/or URL).
overlord_record_work	Records already-finished chat work as a review-column mission.

Most mission-scoped tools accept objectiveId — an objective UUID or a display id such as coo:756.k7xm — next to missionId. A display id already names its mission, so missionId is optional whenever you pass one, and a client holding only the objective can call the tool with it. An objective UUID names no mission and still needs missionId. overlord_reorder_future_objectives is the exception: it only takes missionId, since it replaces the mission’s entire future-objective order rather than acting on one objective.

overlord_launch_objective, overlord_queue_objective, and overlord_update_objective require objectiveId as the primary argument — a display id is enough on its own. overlord_list_deliveries can take that same display id in place of missionId. This matters most on a mission running several objectives at once, where “the active objective” is ambiguous and must be named.

Read tools may also render Overlord MCP Apps widgets (ui://overlord/*) for project selection, mission lists, objective viewers, and file-change summaries. Hosted MCP does not expose local filesystem, runner, or branch actions — those stay on the desktop CLI and connectors.

For Run Queues, read with overlord_list_run_queues before changing state. overlord_reorder_run_queue requires every live entry exactly once and reports the current order when it cannot safely apply a request. Entry membership and ordering use execution_request:create, as does the retry_entry action; queue-definition lifecycle through overlord_manage_run_queue uses project:update, so a mission-lifecycle token cannot create, rename, pause, delete, or reorder queues.

Who it is for

• cloud agents
• headless runtimes
• connector-style integrations
• external automation that needs mission access

Connect an assistant

Add the Overlord MCP URL (copy it from Settings → Agents & MCP) to your assistant’s connector settings and complete the OAuth flow, or provide a USER_TOKEN for runtimes where OAuth is unreliable. If your platform enforces an outbound domain allowlist, allow the Overlord apex domain and its subdomains so the connector can reach the server.

For the full hosted MCP surface — endpoints, OAuth, tools, and boundaries — and the deeper agent-facing walkthrough, see Docs for agents → MCP access and Authentication & troubleshooting.

Related: Agents and connectors · CLI