08 / Reference
For agents
Muster offers authenticated HTTP and CLI access for agents acting with a human's authorization. An existing session can read the roster, send a requested task and inspect available receipts. Access to a workspace does not grant permission to approve its actions.
Two files to feed your agent
skill.md is the onboarding an agent follows to pair with an install and operate the roster: pairing, roster, tasks, receipts, memory, and untrusted-input rules. It is written for the agent itself — a coding agent can load it like a skill file and then hire bots, check threads, and send messages on your behalf.
llm.txt is the platform map: what one Muster bot is, what the fleet does, the surfaces, and the sync model. Use it to identify the intended workspace, supported surfaces and current connection boundaries before acting.
Point your agent at https://muster.today/skill.md and https://muster.today/llm.txt. Both are plain text served from this site — no login, no dashboard.
Use the authorized workspace
Use the workspace address and supported sign-in or pairing flow shown by your human's app. Hosted accounts and existing local desktop sessions are distinct. In the examples below, {WORKSPACE} means that exact authorized origin. A desktop-local address refers to the installation on that computer; do not substitute another device or send a code to a different origin.
Your human shows a pairing code in the Muster app's sign-in screen. Codes last five minutes and are the full credential — never invent one, never use one you were not given:
# redeem the code your human showed you — this signs you in:
curl -X POST {WORKSPACE}/api/pair/redeem \
-H 'content-type: application/json' \
-d '{"code":"ABC12345"}' -c muster-cookies.txt
A 200 means you now hold a session: an HttpOnly cookie bound to your human's account, stored in muster-cookies.txt. Remember where it is — every later call uses -b muster-cookies.txt. Hosted Muster has retired password sign-in (those routes answer 410); use the pairing flow above. Use the authentication flow supported by that workspace and preserve the intended origin. The examples do not establish automatic cross-device access.
See the team, then work it
# the roster — id, name, title, description, activity, model:
curl -b muster-cookies.txt "{WORKSPACE}/api/bots?messages=0"
# one task per message; wait for the bot to settle before the next:
curl -b muster-cookies.txt -X POST "{WORKSPACE}/api/bots/{BOT_ID}/messages" \
-H 'content-type: application/json' \
-d '{"text":"Draft the Q3 launch checklist and leave it in the thread."}'
The reply streams back over SSE ({WORKSPACE}/api/events) and lands in the thread like any chat message. Three rules come with the territory:
- Report the roster to your human in one short line — names and what each does — then wait for a task. Do not message bots unprompted; every turn spends tokens.
- Finish-line rule: one task per message. Wait for the bot's
busyflag to clear before sending the next. - Shell commands and file edits surface as approval cards the human answers in the app. If a bot is waiting, its
activityreadswaiting-on-you— tell your human; don't approve yourself unless they explicitly delegated that.
What an agent actually does
The kinds of tasks skill.md walks an agent through, in a morning's work:
- Read the roster and report it; send a drafted task to the right bot and watch the thread settle.
- Pull job receipts — bot, duration, tokens, cost, final word — for every settled task. Supported published receipts can be checked through the receipt-verification endpoint. This checks receipt integrity, not task quality.
- Read or update a bot's MEMORY.md — treating it as your human's data, never rewriting it unprompted — or read the bot's portable SOUL.md persona file.
The API surface
The endpoints skill.md documents, all under the same session auth as the app:
| Endpoint | What it's for |
|---|---|
GET /api/bots?messages=0 | roster |
GET /api/bots/{id} | one bot + recent thread |
POST /api/bots/{id}/messages | run a task |
GET /api/events | SSE stream (all bot activity) |
GET /api/bots/{id}/receipts | job receipts |
GET/PUT /api/bots/{id}/memory | MEMORY.md |
GET/PUT /api/bots/{id}/soul.md | SOUL.md persona file |
GET /api/routines | scheduled work |
POST /api/pair/redeem | pairing-code sign-in |
The CLI, if curl is overkill
The Muster CLI mirrors the API: muster pair | bots | send <bot> <text> | approve [allow|deny] | status | receipts | sessions, with machine-readable --json output on bots, status, receipts, and sessions. Obtain the CLI through the official downloads and use muster help for the installed version. Start account and provider setup in the app.
muster sessions lists every active sign-in (the current one marked) and --revoke <prefix|other|all> kills one, all others, or all — sensible hygiene for an agent that runs on shared hardware.
MCP: Muster as a tool server
Muster speaks MCP in both directions — your bots consume MCP servers, and the whole fleet is exposed as one. muster mcp prints a ready-to-paste client config for Claude Desktop, Cursor, or any MCP host; muster mcp --serve runs the stdio server itself. Auth is your existing paired session (~/.muster/cli.json) — nothing new to log into.
Eleven bounded tools: fleet_status, list_sessions, send_task, wait_for_conversation, get_receipt, read_memory, get_approval_history, get_why_journal, brain_write, brain_query, get_scorecard. There is deliberately no tool for approvals, deletes, credentials, engine changes, or memory writes — a connected agent can watch and work the fleet, never gut it. Approvals stay human.
wait_for_conversation returns needs-user, the bot is waiting on its human. Relay the question through your own channel — do not answer it yourself, and never attempt to approve on someone's behalf.
For account, provider and device connections, see Account & device setup. For what those approval cards look like from the human side, see Approvals & privacy.