moamcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MOAMCP_HOME | No | Root directory for instance registry (<home>/instances) and board persistence (<home>/boards). | ~/.moamcp |
| MOAMCP_BUS_PORT | No | The desired Bus port. | 39813 |
| MOAMCP_LOGS_DIR | No | Root directory for the four-layer archive (shared by all instances). | <MOAMCP_HOME>/logs |
| MOAMCP_WAIT_CAP_MS | No | Safety cap for moa_wait_turn / moa_board_wait long-polling. | 25 minutes |
| MOAMCP_BUS_WATCH_FAILS | No | Number of consecutive probe failures before the host is judged dead and takeover is triggered. | 3 |
| MOAMCP_BUS_WATCH_TIMEOUT_MS | No | Timeout for host probe requests. | 1000 |
| MOAMCP_BUS_WATCH_INTERVAL_MS | No | Interval for probing the host Bus in reuse mode. | 10000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| moa_initA | Initialize task state: agent list + debate params from an inline preset config. Returns {ok, card_url, agents} where agents is the dispatch map [{id, binding_slot?}] - use binding_slot to dispatch each debater with the correct model. |
| moa_start_debateA | Seed the debate state machine {turn:1, round:1, speaker: first agent} with reference results. |
| moa_wait_turnB | Long-poll until it is this agent's turn. Returns {speaker_id, round, prompt, full_context}, or {status:"debate_complete", transcript}, or {status:"timeout", retry:true} at the safety cap. |
| moa_submit_turnA | Submit this agent's turn content. Validates turn order ({error:"not_your_turn"} otherwise), advances to the next speaker. Pass signoff:true to cast an early-close (unanimous signoff) vote; when every agent has signed off the debate closes early ({debate_complete:true, early:true, reason:"unanimous_signoff"}). Any normal (non-signoff) submission counts as dissent and resets accumulated signoffs. |
| moa_completeA | Write the archive to /{task_id}/ (probe.json, events.jsonl, result.json, plus board.jsonl — the task-scope blackboard notes; logsDir defaults to ~/.moamcp/logs, MOAMCP_LOGS_DIR overrides), close the task, wake remaining waiters (including board waiters, which get {status:"closed"}). |
| moa_board_writeA | Write an entry to the shared blackboard (last-write-wins per key). value is markdown, max 96KB — put large content in files and reference them. Use the blackboard for contracts/decisions/status/pointers across agents and sessions; one-shot instructions belong in dispatch prompts instead. |
| moa_board_readA | Read live entries from the blackboard (deleted keys never appear). With key: that key's latest entry; with tag: entries carrying the tag; with neither: every key's latest value. Newest first, capped by limit (default 100). |
| moa_board_listA | Lightweight browse of the blackboard: one row per live key with {key, author, ts, tags, bytes} (no values). |
| moa_board_waitA | Long-poll until key has a value — or, with since (ISO timestamp), until the entry is strictly newer than it ("wait for the next update"). Returns {status:"ready", entry}, {status:"timeout", retry:true} at the safety cap (default 25min like moa_wait_turn, MOAMCP_WAIT_CAP_MS / timeoutMs tune it), or {status:"closed"} when a task scope is archived while waiting. |
| moa_board_deleteA | Tombstone-delete a key: it disappears from read/list; the append-only JSONL keeps the deletion record. |
| moa_projects_listA | Read-only aggregate for cross-harness project discovery: every registered workspace and registry project in this MOAMCP_HOME. Use it to look up a target projectId before sending a handoff (workspace = the absolute project path you pass to handoff tools). WARNING: every harness that mounts moamcp must point MOAMCP_HOME at the SAME directory — otherwise each harness gets its own blackboard and the coordination chain silently breaks. |
| moa_tip_createB | Create a project-level Tip in the explicitly selected workspace. |
| moa_tip_readA | Read one complete project Tip, including context when present. |
| moa_tip_listA | List lightweight project Tip summaries with status/module/tag filters; archived rows are hidden by default. |
| moa_tip_updateA | Update a Tip atomically; omitted fields remain and nullable optional fields clear their values. |
| moa_tip_archiveA | Archive a project Tip without changing its other content; actor identifies the updater in BoardEntry.author. |
| moa_handoff_sendA | Send a directed handoff (title/summary/optional context) into the TARGET project's inbox (toProject: projectId or "user-global"). The entry is written to the target project's board under handoff/ with fromProject = the current workspace's project alias (or ws:). v2 (optional): pass toAgent/fromAgent as |
| moa_handoff_inboxA | List handoffs addressed to the current project (newest first; id/title/summary/state/fromProject metadata, no context). Archived rows are hidden by default — pass state to filter exactly (pending/consumed/archived). v2: pass agent (your self-reported |
| moa_handoff_readA | Read one complete handoff from the current project's inbox, including the context payload. Returns null when the id is unknown here. Handoffs never participate in recall/indexing. |
| moa_handoff_consumeA | Mark a pending handoff consumed (terminal state; records consumedAt). Only pending → consumed | archived transitions are legal; anything else errors. Handoffs never participate in recall/indexing. |
| moa_handoff_archiveA | Archive a pending handoff (terminal state) without changing its content; hidden from the default inbox view afterwards. Only pending → consumed | archived transitions are legal; anything else errors. Handoffs never participate in recall/indexing. |
| moa_status_agentsA | Live agent/session status folded from the CLI homes' session trees (wire.jsonl / state.json / tasks/*.json) plus the owning Bus's /status snapshot. Returns aggregate counts plus per-agent snapshots ordered by lastSeen (most recent first), capped at 100 by default (pass limit or sessionId to filter). source is 'local' when this process folds the data itself, 'remote' when a reuse session proxies the owning Bus's /status, and 'local-empty' when nothing is available yet — the state is always explicit, never silently stale. |
| moa_tower_bootA | Boot the tower workspace for a git repository: validates the repo (inside a git repo, ≥1 commit), writes the state + namespace identity docs to the shared board, and registers the tower roster entry (name "tower") with your orchestrator agent id. The tower_agent_id must belong to a spawned tower-orchestrator subagent — "main" is rejected (main is never the tower; boot first, then let the orchestrator drive plan/spawn/merge itself). Idempotent lifecycle: repeated boot while booted errors; teardown clears the namespace so boot works again. No .tower/ directory is created inside the repo — state lives in the board, worktrees live in a sibling -worktrees/ dir. Optional delegator_agent_id (M1): registers a roster entry {name:"delegator", kind:"delegator", agentId} — the delegation channel, which may ONLY call moa_tower_send addressed to the tower. |
| moa_tower_planA | Split a tower goal into missions (tower-only): each mission gets an id (M), a branch (feat/M- — id-prefixed so same-titled missions never collide), and a worktree slot (wt-). Build scopes must be pairwise disjoint (merged missions reserve nothing); deps must reference known mission ids. Survey missions are read-only and reserve no scope. Required combo: workspace + caller_agent_id + missions (each item needs title + a non-empty scope; tasks/deps/kind are optional). |
| moa_tower_spawnA | Two-stage spawn (tower-only, B1 bookkeeping stage): creates the mission's physical git worktree (sibling -worktrees/wt-, never inside the repo), marks the mission active with the agent as owner, and registers the roster entry with a PENDING agent id. The tower then launches the agent with its own Agent tool in the FOREGROUND (never run_in_background=true — a backgrounded child cannot wake the tower when it completes): phase 1 does offline work only (workers: code + local commits; reviewers: read-only verdict draft) with no tower calls, then moa_tower_register(agent_id=…) completes the enrollment and a foreground resume (phase 2) lets the agent submit tower reports under its own identity. Argument combos: worker spawn = {name, kind:"worker", mission_id}; reviewer spawn = {name, kind:"reviewer", review_target} — the matching mission_id / review_target argument is REQUIRED for the chosen kind. Reviewers take review_target (a branch to review) instead of a mission. |
| moa_tower_registerA | Two-stage spawn completion (tower-only): fills the real engine agent id into the pending roster entry created by moa_tower_spawn, runs the B2 identity cross-validation (① fold entry exists; ② dual-channel parent-child: wire parentAgentId == towerAgentId OR the tower fold entry lists this agent as a subagent; ③ soft session-workDir check), and rebuilds the guard mirror file (/.tower-guard.json — name-keyed agents map with {name, worktree, agentId} + worktrees array). Missing fold data degrades to verified:false (never blocked); a hard mismatch increments failed_count (3 consecutive → blocked). Re-running register is allowed and re-verifies (B2-9). Required combo: {name, agent_id} — the roster name from moa_tower_spawn plus the engine agent id your Agent tool returned (mission_id/review_target/worktree/branch are optional backfills). |
| moa_tower_missionA | Read or patch a mission, addressed by its id — the argument is named |
| moa_tower_sendA | Deliver an inbox message to a roster agent, the tower, or "all" (broadcast). Self-send is forbidden; the body is capped at 96KB (board ceiling) — split larger content into multiple messages. Returns the message board key. |
| moa_tower_inboxA | Read the caller's inbox (messages addressed to you or broadcast; the tower sees everything), newest first. |
| moa_tower_findingA | File a structured finding (bug | improve | vuln | idea) for the tower to route. Workers use it for anything notable outside their mission scope instead of fixing it directly. The finding is stored under a random UUID key. |
| moa_tower_reviewA | Submit a review verdict for an assigned branch (reviewers and the tower only). The store assigns the round (your history + 1) and stamps the branch tip — the tool resolves the tip itself via git rev-parse, never trusting a self-reported commit. Only a "clean" review of the exact current tip passes the merge gate; the gate consumes clean rounds only. The |
| moa_tower_mergeA | Merge a mission branch into the base (tower-only). The hard gate runs in fixed order: branch belongs to a mission → dependencies merged → survey zero-diff noop → review exists → latest round fully clean (every reviewer of the highest round) → branch tip unchanged since the clean review → changed files inside the mission scope (picomatch) → CI green (only when a ci_command is configured on boot — requires a ci/ record with commit == current tip && exitCode == 0 && clean worktree; otherwise skipped) → git merge --no-ff → conflicts report. Every blocked step records a merge.blocked activity-log line. |
| moa_tower_teardownA | Tear the tower down (tower-only): remove mission worktrees (dirty ones are kept unless force) — root-level symlinks/junctions inside each worktree are unlinked first so junction targets are never touched (git for Windows follows junctions on recursive removal) — then, ONLY when every worktree was removed (or none exist), delete the guard mirror file and clear the live tower namespace so a fresh boot is possible. If any worktree was kept or failed to remove, the result reports each outcome truthfully with torn_down:false and the tower STAYS BOOTED so you can fix the worktrees and re-run (with or without force); nothing is deleted on a partial teardown. The append-only board JSONL stays as the audit trail. |
| moa_tower_statusA | Shared tower dashboard: mission table, roster (with B2 identity verified/failed_count/blocked columns), per-branch review-gate state (highest review round/status and whether it still matches the branch tip), CI summary (configured + per-branch latest result), the caller's inbox count, and the recent activity log. Reading status also re-verifies every roster entry against the status fold (lazy re-verify, B2-9) and persists the verdicts. |
| moa_tower_ciA | Run the configured CI command (boot ci_command) in the mission branch's worktree (tower-only). M1 async: the MCP bridge forwards the request to the persistent Bus owner, which spawns CI and the tool returns IMMEDIATELY with {run_id, started_at, status:"started"}. The ci/ record that lands when the process exits {commit (tip at run time), exitCode, dirty, logRef, ranAt, runId} is the SOURCE OF TRUTH; await it with moa_tower_wait(wait={kind:"ci", branch}) before merging. Per-worktree serialization and completion writes live in the Bus owner, so closing this MCP session cannot cancel the run. A dirty worktree is intercepted BEFORE execution: the run errors asking for a commit first and records a dirty:true failed result. The run log is truncated (last 200 lines, ≤64KB) and referenced by logRef. When a ci_command is configured, the merge gate requires a green (exitCode 0, clean, current tip) record before merging. |
| moa_tower_waitA | Long-poll wait primitive for the tower domain (M1), modeled on moa_board_wait / moa_wait_turn: block until the requested condition holds, then return {status:"ok", ...observed payload}; at the safety cap (default 25min, MOAMCP_WAIT_CAP_MS / timeoutMs tune it — timeoutMs is clamped to the cap) return {status:"timeout", retry:true}. wait.kind:"ci" → block until the ci/ record exists AND its commit matches the branch's CURRENT tip (a stale record from an older tip does NOT satisfy it); payload = the ci record. wait.kind:"inbox" → block until the caller's tower inbox has at least one message (same set moa_tower_inbox returns); payload = the messages. wait.kind:"mission" → block until the mission doc's status changes from what it was at call time; payload = the mission doc (a closed task scope returns {status:"closed"} instead of timing out). wait.kind:"deps" → block until EVERY mission id in mission(mission_id).deps has status "merged" — the dependency-driven parallel-dispatch primitive: all missions are dispatched at once and a dependent parks here, waking when its deps land (a successful moa_tower_merge always writes the dep mission doc, which wakes the wait); already-merged deps return immediately, an empty deps list is satisfied vacuously, and a dep id with no mission document is a protocol error (deps are validated at plan time, so a missing doc means corruption); payload = {mission_id, deps:[{id,status}...]}. Any registered roster member (tower/worker/reviewer) may wait; a delegator is rejected — delegators may only call moa_tower_send addressed to the tower. |
| moa_tower_progressA | Post a progress note to a mission (the mission's owning worker or the tower only — row-11 ownership). Notes accumulate under the single LWW key progress/; the value keeps the newest lines within the board ceiling (80KB headroom). Write frequency is the profile's cron discipline (B4) — keep notes sparse. |
| moa_statusA | Get the current Bus status: port, mode (own/reuse), active tasks, process info. Use this to discover the Bus port for the debate card URL. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Yorha9e/moamcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server