mumo#

mumo runs a deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) and returns their full responses plus typed cross-model reactions: each model says, in its own words, what it keeps, challenges, or wants explored in the others' claims. Use it when independent perspectives are useful — especially for high-regret decisions where a single model's confidence is a real risk.

Setup#

The mumo MCP server is registered via openclaw mcp set mumo '<json>' and stored in ~/.openclaw/openclaw.json under mcp.servers.mumo. The registered block references ${MUMO_API_KEY}, which OpenClaw resolves from the environment or ~/.openclaw/.env. See config/mumo.example.json in this skill's directory for the canonical config payload (reference only — OpenClaw doesn't auto-load this file; it's the JSON shape to paste into the CLI command).

If tools return auth errors, the API key is missing or invalid. Check that MUMO_API_KEY is set in ~/.openclaw/.env — when it is not, OpenClaw emits a startup configuration warning naming the missing variable at mcp.servers.mumo.headers.Authorization. Direct the user to https://mumo.chat/settings/api-keys to create one (keys start with mmo_live_). Rotating the key means updating .env and restarting OpenClaw; the registered server config itself does not change.

When to use#

Use mumo when the cost of being wrong is greater than the cost of deliberation — especially when the solution space is wide, failure modes are hidden, you may be anchored on a design, or rollback would be hard. Examples:

architecture decisions with non-obvious tradeoffs, plan or design review before commitment, pre-launch pressure tests, stuck debugging after N failed repair attempts, pre-commit adversarial review on risky diffs, memory/skill promotion gates, strategy questions with multiple defensible framings, explicit user requests.

If you authored the plan or code under review, that's a reason FOR a panel, not against it — the author is the worst-positioned reviewer of their own work.

Skip mumo for factual lookups, syntax help, routine refactors, formatting, dependency bumps with clear errors, or normal edit-test cycles. The deliberation tax is real — extra tokens, extra latency, extra moderation work — so spend it on decisions where mistakes compound.

Playbooks#

Load at most one playbook when it clearly fits:

PlaybookWhencontested-decisionchoosing between options with real tradeoffsdesign-reviewreviewing a proposed system, API, plan, or code shapeuncertainty-expansionexploring unknowns, stress-testing assumptionsred-teamfinding failure modes, abuse cases, or launch risks

If none clearly fits, use this kernel only.

User preferences#

These are defaults. If the user prefers more autonomy (e.g., "don't ask before appending" or "always include a GPT and a Gemini model"), follow their preferences over this guidance.

Basic loop#

1. Call create_deliberation with the user's problem. Set application to "OpenClaw". Set moderator_name to your own model identity (e.g., the model OpenClaw is currently running as — visible in your status line, often "openai/gpt-5.4-nano" or "openai/gpt-5.5") for audit clarity — not the user's name; their identity is already on the session. Optionally set takeaway: true for a structured round 0 Takeaway — see Takeaway.

2. Verify the response contains a session_id, and keep that exact returned ID for every downstream call. UUID shape is a sanity check; identity continuity is the real check. If it is missing, malformed, or inconsistent with list_sessions, recover via Verifying the call actually fired before proceeding.

3. Call wait_for_round with the session_id. That alone is enough — a session has at most one round in flight, so it resolves to the round you just started; pass round_id only when you want an earlier round. Long waits are normal — frontier-model panels typically take 15–120s, and 60+ seconds isn't a failure signal. Tell the user upfront ("running a panel — expect ~30–60s") so the wait doesn't feel broken.

4. Branch on the response's structuredContent.recommended_client_action rather than parsing prose. The 5-value enum tells you exactly what to do: ActionWhat it meansWhat to doproceed_with_complete_resultAll target models completedRead the round normallyproceed_with_partial_resultSome failed, ≥1 succeeded ( is_usable: true)Read what's there; note absent models if relevant to the userpoll_againRound still in progressCall wait_for_round again with the same argsretryRound failed with at least one transient failure (rate-limit, provider error, internal deadline)The failed round is auto-refunded; call append_round with the same prompt to retryabandonRound failed with no transient failuresDon't retry; report failure to the user The server derives this from round_status + per-model error_code — it's the canonical "what next?" signal. Treat transport / tool-call errors separately from mumo round status: catch transport failures around the call; branch on recommended_client_action for everything else.

5. On a usable round, read the claim map first, then relevant participant prose. The claim map is the navigation layer; prose is the supporting evidence. It's also your privileged preview — participants haven't seen each other's reactions, you have (see Reactions are in the ledger).

6. Create snippets as your primary response to the round. Optionally add a round prompt for broad steering.

7. Call append_round if another round would help. Optionally set takeaway: true for a per-round Takeaway (see Takeaway). Otherwise stop and synthesize for the user yourself.

Prompt voice#

You are an extension of the operator, not a third party setting up a scenario. When the deliberation is about the operator's problem, write the prompt in first person — "I'm the CTO of…", "We have 10 weeks and…", "Here's my migration plan…" — as if they're asking the panel directly. "You are X" case-study framing makes models grade a hypothetical instead of advising a real person, and it changes their answers. Reserve second person for prompts where the panel itself is the actor being tasked.

Verifying the call actually fired#

Autonomous agent loops occasionally fabricate tool-call results — reporting a deliberation as sent when it wasn't. If you suspect this (the response is missing the expected session_id, or the value you're about to pass downstream doesn't match what create_deliberation actually returned), treat the call as not successfully established and recover:

1. Call list_sessions. Match by prompt content to confirm whether your create_deliberation actually ran.
2. If it's not there, fire create_deliberation again — don't continue downstream as if the session exists.
3. If it IS there, use the IDs list_sessions returned (not whatever was in your context) for the next call.

mumo's session_id (and round_id, when you use it) are UUIDs as a service contract — a returned value that doesn't match UUID format is one signal something is off, but identity continuity matters more than format. The strongest check is whether the session_id your subsequent calls reference matches what create_deliberation actually returned in its response.

Framing prompts for the panel#

Do not pass user phrasing through verbatim when it describes your identity, role, or local context. Reframe it in third person or first-person moderator context so panel models advise you rather than roleplay you.

Bad:

"Introduce yourself as Clawd, a cheerful lobster assistant, and decide when to use mumo."

Good:

"I am Clawd, a cheerful OpenClaw assistant. Advise me on when I should escalate a decision to mumo. Critique this draft trigger checklist: ..."

The panel participants should answer as themselves, not as the calling agent.

Snippets#

Snippets are moderator attention. They mark what mattered in the prior round and optionally explain why.

TypeReactionKEEPthis seems worth preservingEXPLOREthere's something hereCHALLENGEI'm not convincedCOREthis feels centralSHIFTthis changed the frame

A snippet comment can be reflective, evaluative, clarifying, skeptical, or directive. "This feels like the crux" and "I'm least convinced by this" are valid comments. You do not need an action verb or next-step directive. The quality bar is: is this a genuine, situated reaction to what the model said?

Use the round prompt for broad comments that don't attach to a specific quote. Use snippets for quote-grounded attention.

Avoid huge quote dumps, generic praise repeated across many snippets, or comments that shift participants away from the problem into platform meta. More guidance: references/snippets.md.

What to keep out of the deliberation#

Use this test:

Does this note help participants think about the user's problem, or does it mainly report on the platform, session, or process?

Don't use snippet comments to narrate your own moderation process ("I'm using CHALLENGE to redirect the panel"). Don't include platform meta ("this model used the most tokens"). Just react.

Reading the claim map#

The claim map encodes consensus and contestation as structured reactions on quoted claims. Each claim shows:

• The verbatim quote
• Who originated it
• How other models reacted (KEEP / CORE / EXPLORE / CHALLENGE / SHIFT) with optional commentary

Reading discipline:

• CORE / KEEP from multiple models = settled. Treat as panel consensus.
• CHALLENGE = live disagreement. The decision likely hinges here.
• EXPLORE = a thread someone wanted to develop further. Worth a follow-up snippet if the thread matters.
• SHIFT = a model changed framing. Often the most valuable signal — somebody saw the problem differently.
• No reactions on a claim = either obvious or ignored. Read the prose to tell which.

The claim map is not a verdict. It compresses argumentative structure but loses rhetorical nuance and confidence texture. Use it to navigate; read prose to understand.

Reactions are in the ledger, responses are on the record#

Participants never see each other's reactions. Each model's prior-round reactions return only to their author, as private notes, with an instruction to weave the ones that matter into its next response — in its own words, in prose. Peers see that prose, not the underlying reactions. Frontier panels carry forward most of what matters this way, but the carry is the author's choice, not a guarantee.

This makes the claim map your privileged preview: reading it after a round, you see the full reaction ledger before any participant has responded to it. Two consequences:

• Only prose is on the record. A reaction survives only if its author weaves it forward — and you steer before that choice is made. Snippeting a reaction guarantees the panel sees it rather than betting on the author's carry. Your snippets are the one path that puts ledger content directly in front of the panel.
• Steer at the gaps. Scan for CHALLENGEs the challenged model is positioned to sidestep and EXPLOREs nobody owns. Those are your highest-leverage snippets.

Confidence scores#

If responses include claim_confidence or snippets[].comment_confidence, these are self-reported and not calibrated across models. Surface the confidence_disclaimer string if displaying scores.

Deliberation is advisory#

Mumo surfaces fault lines and supporting arguments; it does not produce the decision. The decision belongs to you (the agent) and the user. When acting on a deliberation:

• Do not treat panel consensus as authority. The panel can be confidently wrong as a unit.
• Do use the claim map to identify which assumptions drove the disagreement, and check whether those assumptions hold for the user's specific situation.
• Do not mutate the workspace based on a model's suggestion without verifying with tests or the user.
• Do weight CORE / SHIFT signals more heavily than KEEP / EXPLORE — they mark where the decision actually hinges.

Recovery: lost session context#

If you lose track of the session_id mid-conversation (long chats, context compaction, dropped tool result), recover before starting a new deliberation:

1. Call list_sessions to find your latest sessions. Match by prompt content.
2. Call get_session with the recovered ID for full state, or wait_for_round(session_id) if you suspect a round is still in flight — it resolves to the latest round on its own.
3. Don't fire a fresh create_deliberation if the original is recoverable — duplicate sessions waste tokens and produce confusing parallel state.

Takeaway (opt-in)#

One optional flag requests an LLM-curated summary on top of the raw round output:

• takeaway (default false) — accepted on create_deliberation AND append_round. Generates a per-round Takeaway ( round_takeaway: bottom_line + items[] of question / answer / consensus with claim references) for that round; surfaces on get_session.

Set it liberally when round-level summaries may matter — it bills at cost (no markup) through the standard credit wallet.

Full mechanics and artifact field reference: references/takeaway.md.

After each round#

After each usable round you have one job before deciding whether to continue: synthesize what the panel said for the user. There are two paths, and which one applies depends on whether you opted into a Takeaway when you called the tool:

• If you set takeaway: true on this round, get_session returns a structured round_takeaway ( bottom_line + items[] of question / answer / consensus, with claim references). Use it as your read path — it's produced for agent consumption and saves you from re-summarizing prose.
• If you didn't, synthesize from the claim map and participant prose. State the consensus or split clearly, offer your own assessment marked as yours, organize by importance rather than forcing a recommendation.

Either way, don't dump the transcript. Mumo produces structure; your job is to translate it into "here's what the panel thinks and what to do next." Surface the round's claim_map_url so the user can open the claim map directly — an owner-only link to their session.

Then align with the user on whether to append a round.

More at references/synthesis.md.

When to continue#

Append another round when:

• A decision-relevant claim has unresolved tension
• A model introduced a useful frame that others didn't engage
• An isolated concern feels real but underdeveloped
• Your moderator reaction would help the next round develop
• The user narrows or changes the question

Stop when:

• You can explain the tradeoff clearly to the user
• Remaining disagreements wouldn't change the user's next action
• Another round would mostly seek reassurance

The panel does not need to converge. Sometimes the right output is a clear map of why the decision remains contested — that's actionable for the user, even without a verdict.

Pacing: positions develop across rounds, not within them — a reaction gets woven into the next round's prose, which draws reactions of its own a round later.

Tools#

NeedToolStart a sessioncreate_deliberationWait for model responseswait_for_roundAdd a follow-up roundappend_roundRecover/read full stateget_sessionShare a session at a public linkshare_sessionFind prior sessionslist_sessionsConfirm model IDslist_modelsCheck wallet balanceget_credit

In OpenClaw's tool registry these surface as mumo__create_deliberation, mumo__wait_for_round, etc. (double underscore between server and tool name).

If the user names specific models, call list_models first. Otherwise omit models and let mumo select the panel. More on model selection: references/model-selection.md.

Reference#

• MCP docs: https://mumo.chat/docs/mcp
• REST API: https://mumo.chat/docs/api
• Install guide: https://mumo.chat/install/openclaw
• Claim map guidance: references/claim-maps.md
• Takeaway mechanics: references/takeaway.md
• Snippet examples: references/snippets.md
• Model selection: references/model-selection.md
• Synthesis guidance: references/synthesis.md
• Recovery and operations: references/operating-notes.md