Supervisor MCP: Manage Your Entire Agent Infrastructure
Docs / Supervisor MCP
Core Control Plane

Supervisor MCP Reference

The Supervisor MCP (CoreMCP) is a global management interface that spans your entire AgentRQ account. Unlike Workspace MCP servers which are isolated to a single project, the Supervisor MCP allows an agent to manage all workspaces, monitor platform-wide stats, and orchestrate complex multi-agent workflows — including defining events, event triggers, and named workflow graphs that tie steps together, so an agent can wire up a system for you instead of you building it by hand in the UI. It can also mint an enrolment code for adding a new machine to run agents on, and launch or stop agents on the machines you have.

It has nine tools. Each takes an action and a payload, and the help tool prints the exact payload of any action. See Calling the tools.

Why Supervisor MCP?

Platform Orchestration

Perfect for "Manager" or "Orchestrator" agents that need to create workspaces dynamically for new projects or list existing ones to find relevant context.

Monitoring & Audit

Allows agents to pull statistics and task history across all workspaces for reporting, auditing, or platform-wide performance analysis.

Connection Details

The Supervisor MCP server uses OAuth2 for authentication. Most modern MCP clients (like Claude Desktop or Claude Code) will handle the OAuth handshake automatically when you provide the server URL.

https://mcp.agentrq.com/mcp
New

Build a System, Not Just Tasks

A supervisor could always create workspaces and put tasks in them — but not the thing that turns those into a system. Now it can. An event is a named signal a workspace publishes when something happens; an event trigger is a standing instruction to create a task somewhere else when that signal fires. Wire the two together and a hand-off happens without the supervisor arranging it, task by task.

These are the same operations the Events UI performs. Each action of the events tool is a thin wrapper over the controller method the REST API calls, so an agent gets no path the UI does not have and no validation the UI does not enforce.

Wiring one up

// 1. Name the signal.
events {"action": "create", "payload": {
  "name": "qa_passed",
  "payloadGuidelines": "Include the build number and the pass/fail counts."
}}  // -> { id: "0hNRmEWoU5Z", ... }

// 2. Say what should happen when it fires.
events {"action": "createTrigger", "payload": {
  "eventId":     "0hNRmEWoU5Z",
  "workspaceId": "0eCTDeDXETx",
  "title":       "Ship the release",
  "body":        "QA signed off:\n{{EVENT_PAYLOAD}}",
  "emitEventId": "0hDXw48jLfd"   // publishes deploy_finished on completion
}}

// 3. Check the system is actually running.
events {"action": "listTasks", "payload": {"eventId": "0hNRmEWoU5Z"}}

Step 2's emitEventId is what makes this compose: the spawned task publishes a second event when it completes, so one system hands off to the next without anything in the middle.

Placeholders

Variable Replaced With
{{EVENT_PAYLOAD}} The payload string the publishing agent sent
{{EVENT_FAQ}} Extra Q&A context from the publishing agent, when it provided any

Both are substituted in the task body only. A trigger's title is used exactly as written, so a placeholder there stays on screen as literal text.

What the server checks

Rule Detail
Event name Must match ^[a-z][a-z0-9_]{0,128}$ and be unique for your account. A name already taken is reported as a duplicate, not a server error.
Names are permanent events → update revises the payload guidelines only. To rename, create a new event.
Ownership The event, the target workspace and any emitEventId must all belong to you. Anything else comes back as not found.
Cron granularity A trigger's optional cronSchedule is 5 fields, and the minute must be a single fixed number 0–59 — no *, /, - or ,. Hourly or coarser.
Updates are rewrites events → updateTrigger writes every field as given, so send the ones you want to keep as well as the ones you are changing.
Default assignee A trigger with no assignee creates the task for agent — a trigger exists to make something happen without being asked.
New

Workflows: The Graph Events Add Up To

Events and triggers were reachable one at a time — a workflow is the named graph they form: a start event, and the steps that react to it and to each other. Give it a name once, and every workspace it touches, every task it spawns and every event it chains is visible in one place instead of scattered across individual triggers.

These are the same operations the Workflows UI performs, as actions of the workflows tool, so an agent gets no path the UI does not have and no validation the UI does not enforce — ownership of the workflow, of the events it names and of the workspaces its steps point at, and the cycle check that stops a graph emitting its way back into itself, are all decided server-side.

Building one

// 1. Create the graph around a start event.
workflows {"action": "create", "payload": {
  "name":         "release-pipeline",
  "startEventId": "0hNRmEWoU5Z"   // qa_passed
}}  // -> { id: "0hWfK92pXqL", ... }

// 2. Add a step: when the start event fires, create a task here.
workflows {"action": "createStep", "payload": {
  "workflowId":  "0hWfK92pXqL",
  "eventId":     "0hNRmEWoU5Z",
  "workspaceId": "0eCTDeDXETx",
  "title":       "Ship the release",
  "body":        "QA signed off:\n{{EVENT_PAYLOAD}}",
  "emitEventId": "0hDXw48jLfd"   // publishes deploy_finished on completion
}}

// 3. Check the system is actually running.
workflows {"action": "listTasks", "payload": {"workflowId": "0hWfK92pXqL"}}

Two ways to write the same graph

createStep and deleteStep edit one node at a time, which is what an agent adding a branch to an existing workflow wants. replaceFromText writes the whole graph from the indented document the UI's text mode uses (two spaces per level, alternating - agent:<workspace> / - event:<name> lines) — what anything declarative wants, since an extension reconciling what it declared against what exists compares two documents rather than diffing a graph node by node. getText reads that same document back; both paths go through the same controller and the same rules, so neither is a shortcut past the other.

What the server checks

Rule Detail
Partial updates workflows → update only changes the fields you send — a name-only edit does not detach the workflow from its start event.
Cycle check A step's emitEventId cannot chain the graph back into an event it already reacts to — the server rejects the cycle rather than looping a workflow into itself.
Text mode is resolved atomically replaceFromText resolves every event and workspace name in the document before writing anything — an unknown name on the last line leaves the workflow untouched.
Deleted names are skipped, not broken getText leaves out steps naming a deleted event or workspace, so the document it returns always parses.
Ownership The workflow, the events it names and the workspaces its steps point at must all belong to you. Anything else comes back as not found.

Calling the Tools: Action and Payload

The supervisor has nine tools: workspace, task, memory, skills, events, workflows, machines, pano and help. Every tool takes exactly two inputs: action, the thing to do, and payload, that action's fields. payload is left out when an action takes nothing.

task {"action": "create", "payload": {"workspaceId": "0ZzhYQG2qtl", "title": "Release v0.9.20"}}
machines {"action": "createEnrolmentCode"}

Each action checks its payload strictly. An unknown field or a missing required one is refused with an error that names the action, so a typo fails loudly instead of being ignored. In prose these docs write an action as task → create.

Ask help for the exact payload

This page lists every action and shows an example, but it does not copy every field. The server documents itself: the help tool prints the tools, a tool's actions, or one action's payload fields and an example call. Every other tool also has a help action, which does the same for that tool: task {"action": "help", "payload": {"topic": "create"}}.

help {}                            // every tool and its actions
help {"action": "events"}         // one tool's actions
help {"action": "task.create"}    // one action's payload and an example
help {}
Every tool takes {"action": "<action>", "payload": {...}}.

Tools:
  workspace    The account's workspaces, and their forks.
               actions: list, create, get, update, stats, fork, mergeFork
  task         The tasks of every workspace.
               actions: list, listAll, create, get, reply, respond, updateStatus, updateSortingOrder, updateAssignee, updateAllowAll, updateSchedule, delete, getAttachment
  memory       A workspace's memory, read-only.
               actions: list, get
  skills       The account's skills as a workspace sees them, read-only.
               actions: search, get
  events       Named signals, and the triggers that turn them into tasks.
               actions: list, create, get, update, delete, listTasks, listTriggers, createTrigger, getTrigger, updateTrigger, deleteTrigger
  workflows    Graphs of events and the workspaces they hand off to.
               actions: list, create, get, getText, update, delete, replaceFromText, listSteps, createStep, deleteStep, listTasks
  machines     Machines running agentrqd, and the agents on them.
               actions: list, createEnrolmentCode, launchAgent, stopAgent
  pano         Markdown docs every workspace of the account shares.
               actions: save, read, comment, attach, delete

Run help {"action": "<tool>"} for a tool's actions, or {"action": "<tool>.<action>"} for one action's payload and an example.
help {"action": "events"}
Usage: events {"action": "<action>", "payload": {...}}

Actions:
  list                 List the account's events.
  create               Define a named signal that workspaces publish and triggers react to.
  get                  Get an event.
  update               Revise an event's payload guidelines. Its name is fixed once created.
  delete               Delete an event. Its triggers stop firing.
  listTasks            List the tasks an event has spawned, to see whether what was wired up is running.
  listTriggers         List an event's triggers: everything that happens when it fires.
  createTrigger        React to an event: when it fires, create a task in a workspace.
  getTrigger           Get an event trigger.
  updateTrigger        Rewrite an event trigger.
  deleteTrigger        Delete an event trigger, leaving its event in place.
  help                 This list, or with payload {"topic": "<action>"} that action's payload.
help {"action": "task.create"}
Usage: task {"action": "create", "payload": {"workspaceId": <string>, "title": <string>, ...}}

Create a task in a workspace, assigned to the human unless assignee says otherwise.

Write the full context into body: the receiving agent has nothing else. cronSchedule makes it a scheduled task: a recurring one runs at most hourly, a one-time one fixes dom and month.

Required:
  workspaceId          string   The workspace's ID (base62).
  title                string   The task's title.

Optional:
  body                 string   The task's body: what is to be done.
  assignee             string   One of: human, agent.
  cronSchedule         string   A 5-field cron schedule (minute hour dom month dow) to run the task on. A recurring task is at most hourly: a single minute 0-59, e.g. '30 * * * *'. A one-time task fixes dom and month, e.g. '30 14 25 4 *'.
  parentId             string   The task this one belongs under (base62).
  clearContext         boolean  Ask for a clean slate: /clear is sent to the agent's terminal before this task is handed over, so it starts without the previous task's context. Ignored when the target workspace has no running Claude Code session. Defaults to the target workspace's own setting.

Example:
  task {"action": "create", "payload": {"workspaceId": "0ZzhYQG2qtl", "title": "Release v0.9.20", "body": "Tag main and publish the release notes.", "assignee": "agent", "clearContext": true}}

Available Tools

workspace

The account's workspaces, and their forks.

Actions
Action What it does Replaces
list List the account's workspaces. includeArchived adds archived ones. listWorkspaces
create Create a workspace. Check list first for one with the same purpose. The answer carries the new workspace's mcpUrl, the endpoint its agent connects to. createWorkspace
get Get a workspace, with its mcpUrl. getWorkspace
update Update a workspace: only the fields sent change. updateWorkspace
stats Get a workspace's statistics over 7d or 30d. getWorkspaceStats
fork Fork a workspace: its own queue and agent, sharing the parent's settings, memory and skills. A fork, the supervisor workspace and an archived workspace cannot be forked. forkWorkspace
mergeFork Merge a fork back into its parent and remove it. Its agent is stopped and every task moves to the parent with its thread. Refused while any task in the fork is not completed or rejected; its folder stays unless deleteFolder is true. mergeFork
Creating a workspace does not start an agent in it. A human still connects one from the workspace's Settings page, or you launch one with machines → launchAgent.
Example
workspace {"action": "create", "payload": {"name": "release-notes", "description": "Writes the release notes for every tag."}}
workspace {"action": "stats", "payload": {"id": "0ZzhYQG2qtl", "range": "7d"}}

task

The tasks of every workspace.

Actions
Action What it does Replaces
list List a workspace's tasks. filter, status and createdBy narrow it; limit (default 5, at most 50) and offset page through it. listTasks
listAll List the tasks of every workspace, with the same filters as list. listAllTasks
create Create a task in a workspace. cronSchedule makes it a scheduled task; parentId makes it a subtask; clearContext sends /clear to the agent first. createTask
get Get a task. getTask
reply Post a message to a task's thread. replyToTask
respond Answer the permission request a task is waiting on: allow, allow_all, reject (not deny), or text to reply without deciding. respondToTask
updateStatus Set a task's status. updateTaskStatus
updateSortingOrder Set a task's sort order. updateTaskOrder
updateAssignee Hand a task to the agent or the human. updateTaskAssignee
updateAllowAll Let a task's agent run every command without asking, or stop it. updateTaskAllowAll
updateSchedule Change a scheduled task's title, body or schedule. updateScheduledTask
delete Delete a task, with its messages and attachments. This cannot be undone. deleteTask
getAttachment Get an attachment of a task: its public link, or its content as base64 with format: "base64", and its name and type. getAttachment
The default assignee here is the human. On the supervisor, task → create without assignee creates the task for a person; on the workspace server the default is the agent. Write the full context into body: the receiving agent has nothing else.
To stop a scheduled task without losing its history, set it to rejected with updateStatus instead of deleting it.
Example
task {"action": "create", "payload": {
  "workspaceId": "0ZzhYQG2qtl",
  "title": "Release v0.9.20",
  "body": "Tag main and publish the release notes.",
  "assignee": "agent",
  "clearContext": true
}}

// Answer a waiting permission request
task {"action": "respond", "payload": {"workspaceId": "0ZzhYQG2qtl", "taskId": "0kGogHmaqvZ", "action": "allow"}}

memory

A workspace's memory, read-only.

Actions
Action What it does Replaces
list List a workspace's memories: name, size and when each last changed, without content. listMemories
get Get one of a workspace's memories in full, by name. memory.md is the index the others hang off. getMemory
Example
memory {"action": "get", "payload": {"workspaceId": "0ZzhYQG2qtl", "name": "memory.md"}}

skills

The account's skills as a workspace sees them, read-only.

Actions
Action What it does Replaces
search Find skills: name, description, source and size, and the total matched. enabled false means turned off for every workspace; workspaceEnabled false means not on in that one. searchSkills
get Get one file of a skill; skill://<name> alone gets its SKILL.md and the list of its other files. getSkill
Example
skills {"action": "search", "payload": {"workspaceId": "0ZzhYQG2qtl", "q": "release"}}
skills {"action": "get", "payload": {"workspaceId": "0ZzhYQG2qtl", "uri": "skill://release-notes"}}

events

Named signals, and the triggers that turn them into tasks.

Actions
Action What it does Replaces
list List the account's events. listEvents
create Define a named signal that workspaces publish and triggers react to. The name matches ^[a-z][a-z0-9_]{0,128}$ and is unique for the account. createEvent
get Get an event. getEvent
update Revise an event's payload guidelines. Its name is fixed once created. updateEvent
delete Delete an event. Its triggers stop firing. deleteEvent
listTasks List the tasks an event has spawned, to see whether what was wired up is running. listEventTasks
listTriggers List an event's triggers: everything that happens when it fires. listEventTriggers
createTrigger React to an event: when it fires, create a task in a workspace. emitEventId chains a second event to that task's completion. createEventTrigger
getTrigger Get an event trigger. getEventTrigger
updateTrigger Rewrite an event trigger. Every field is written as given, so send the ones to keep as well. updateEventTrigger
deleteTrigger Delete an event trigger, leaving its event in place. deleteEventTrigger
updateTrigger is a full rewrite, not a patch: leaving a field out clears it.
Example
events {"action": "createTrigger", "payload": {
  "eventId": "0kEvt7hQx2M",
  "workspaceId": "0ZzhYQG2qtl",
  "title": "Write the release notes",
  "body": "{{EVENT_PAYLOAD}}",
  "emitEventId": "0kEvt9notes"
}}

workflows

Graphs of events and the workspaces they hand off to.

Actions
Action What it does Replaces
list List the account's workflows. listWorkflows
create Create a workflow, optionally starting from an event (startEventId). createWorkflow
get Get a workflow. getWorkflow
getText Read a workflow's whole graph as the indented document the UI's text mode edits. Steps naming a deleted event or workspace are left out, so the document always parses. getWorkflowText
update Update a workflow: only the fields sent change. updateWorkflow
delete Delete a workflow and its steps. deleteWorkflow
replaceFromText Replace a workflow's entire graph with a document. Every name is resolved before anything is written. replaceWorkflowFromText
listSteps List a workflow's steps. listWorkflowSteps
createStep Add a step: when its event fires, create a task in a workspace. createWorkflowStep
deleteStep Delete a workflow step. deleteWorkflowStep
listTasks List the tasks a workflow has spawned. listWorkflowTasks
An unknown event or workspace name anywhere in a replaceFromText document leaves the workflow untouched. Nothing is partially written.
Example
workflows {"action": "replaceFromText", "payload": {
  "workflowId": "0kWfl5mN2pQ",
  "text": "- event:release_tagged\n  - agent:release-notes\n    - event:notes_ready"
}}

machines

Machines running agentrqd, and the agents on them.

Actions
Action What it does Replaces
list List the account's machines: name, OS, agentrqd version, whether each is enabled and online, and its running agents. listMachines
createEnrolmentCode Mint a one-time code for enrolling a new machine with agentrqd. The answer has code, expiresAt and enrolCommand, the full agentrqd enroll command. It is shown once and expires shortly. createEnrolmentCode
launchAgent Start an agent for a workspace on one of the account's machines, in the workspace's working directory. kind is claude-code or acp-gateway. launchAgent
stopAgent Stop the agent a workspace is running on a machine, ending whatever it is in the middle of. stopped is false when none was running. stopAgent
There is no remote enrolment. createEnrolmentCode only mints the code: a human still runs enrolCommand on the target machine after installing agentrqd from agentrq.com/docs/daemon.
launchAgent is refused while the workspace already has an agent, when it has no working directory, or when the machine is disabled, offline or runs an agentrqd too old for what was asked. The agent connects a few seconds later and picks up its tasks.
Example
machines {"action": "createEnrolmentCode"}
machines {"action": "launchAgent", "payload": {"workspaceId": "0ZzhYQG2qtl", "machineId": "0kMch4rT8uV", "kind": "claude-code", "model": "opus"}}

pano

Markdown docs every workspace of the account shares.

Actions
Action What it does Replaces
save Create a doc (no id) or replace one's title and markdown. Returns the doc without its markdown. A new doc lives 30 days unless ttlDays says otherwise. –
read Read a doc, with its linked files; optionally its comments and attachments. –
comment Add a comment to a doc. –
attach Add files to a doc that its markdown need not link. –
delete Delete a doc. –
The supervisor writes Pano docs as the account's supervisor workspace. The same tool, with the same actions, is on every workspace server, so a doc saved here can be read by any workspace's agent.
Example
pano {"action": "save", "payload": {"title": "Release plan", "markdown": "# Release plan\n\n- [ ] Tag v0.9.20", "color": "green"}}

Old Tool Names Still Work

Before the action tools, the supervisor had one tool per operation. The server still answers tools/call for every one of those names, without listing them in tools/list: it rewrites the call to the matching action, with the old arguments as the payload. It also accepts a flat call that puts the fields next to action, such as task {"action": "reply", "workspaceId": "…", "taskId": "…", "text": "…"}, and moves them into payload.

So agents, plugins and scripts that are already installed keep working. New ones should call the action tools.

Old tool Now
listWorkspaces workspace → list
createWorkspace workspace → create
getWorkspace workspace → get
updateWorkspace workspace → update
getWorkspaceStats workspace → stats
forkWorkspace workspace → fork
mergeFork workspace → mergeFork
listTasks task → list
listAllTasks task → listAll
createTask task → create
getTask task → get
replyToTask task → reply
respondToTask task → respond
updateTaskStatus task → updateStatus
updateTaskOrder task → updateSortingOrder
updateTaskAssignee task → updateAssignee
updateTaskAllowAll task → updateAllowAll
updateScheduledTask task → updateSchedule
deleteTask task → delete
getAttachment task → getAttachment
listMemories memory → list
getMemory memory → get
searchSkills skills → search
getSkill skills → get
listEvents events → list
createEvent events → create
getEvent events → get
updateEvent events → update
deleteEvent events → delete
listEventTasks events → listTasks
listEventTriggers events → listTriggers
createEventTrigger events → createTrigger
getEventTrigger events → getTrigger
updateEventTrigger events → updateTrigger
deleteEventTrigger events → deleteTrigger
listWorkflows workflows → list
createWorkflow workflows → create
getWorkflow workflows → get
getWorkflowText workflows → getText
updateWorkflow workflows → update
deleteWorkflow workflows → delete
replaceWorkflowFromText workflows → replaceFromText
listWorkflowSteps workflows → listSteps
createWorkflowStep workflows → createStep
deleteWorkflowStep workflows → deleteStep
listWorkflowTasks workflows → listTasks
listMachines machines → list
createEnrolmentCode machines → createEnrolmentCode
launchAgent machines → launchAgent
stopAgent machines → stopAgent

Prompts & Resources

Besides tools, the server offers MCP prompts: ready-made starting points your client can list, often as slash commands. It also offers resources, which are guides an agent can read into its context before it acts. Their steps name the action tools, such as workspace → create and machines → createEnrolmentCode.

Prompts
Name Arguments What it does
new-workspace name (required), purpose Creates a workspace for a stated purpose and reports what a human still has to do to connect an agent to it.
setup-agentrqd platform (linux, macos or windows) Mints a fresh enrolment code and returns the exact install and enrol commands for a human to run on a new machine.
workspace-status None Summarizes what is happening across every workspace right now.
Resources (text/markdown)
URI Guide
agentrq://guides/new-workspace How to set up a new workspace for an agent to run in, from the supervisor.
agentrq://guides/agentrqd-setup How to install agentrqd and enrol a machine so a workspace can run agents there.
Scale your agents
Start managing your entire infrastructure today.