mcpbeat Sign in

mumo MCP Server

not responding

mumo is listed as active in the registry but did not answer our last check. It exposes 8 tools. Last commit 9 Sep 2026.

Multi-model deliberation over MCP: full responses plus typed cross-model reactions from other labs.

Uptime history 51 days of history · worst day 0%
51 days agonow
2.2%
Uptime 24h
2 of 91 checks
8
Tools
read from the server
559 ms
Response time
average over 24h
0
Stars
last commit 9 Sep 2026

What changed 6

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 8 September 2026. No other catalogue keeps this.

8 Sep 3 tool descriptions were rewritten append_round, create_deliberation, get_credit
8 Sep 2 tools changed the parameters they ask for create_deliberation, wait_for_round
8 Sep a tool changed version

mumo does not always answer

Over the last week it answered 0.5% of our checks. We check every 15 minutes, so you hear about the next outage within the hour — not from your users.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 12 min ago.

run in your terminal
claude mcp add mcp --transport http https://mumo.chat/api/mcp
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "mcp": {
      "url": "https://mumo.chat/api/mcp"
    }
  }
}
~/.codex/config.toml
[mcp_servers.mcp]
url = "https://mumo.chat/api/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "mcp": {
      "url": "https://mumo.chat/api/mcp"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "mcp": {
      "url": "https://mumo.chat/api/mcp"
    }
  }
}

Available tools 8

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

append
append_round
Add a follow-up round to an existing deliberation session. Use after reading the previous round's claim_map and responses to steer the conversation. The `snippets` array lets you forward specific quotes from the prior round's responses with a typed reaction: - KEEP: this point is strong, preserve it - EXPLORE: dig deeper on this thread - CHALLENGE: push back on this claim - CORE: this is load-bearing, build on it - SHIFT: this reframes the question Models see the snippets as curated forwards and respond with full context. Use this to resolve disagreements, test claims, or direct attention to specific passages. Forwarding is the moderator's privileged promotion of ledger content into the record — you have seen notes the panel has not. Elevate what the discussion needs now rather than waiting to see whether its author carries it. **Returns immediately (async).** Response is a compact ack — model execution runs in background. Call `wait_for_round` with this `session_id` and `round_id` from the ack to read the finished round; its `structuredContent` carries `round_status` (4-way), `is_usable`, and `recommended_client_action` so you can decide whether to read the result, retry, or abandon without parsing prose. Only works on sessions that don't have an in-flight round. If `get_session` shows the latest round is `pending`, wait. If a prior round failed catastrophically and was refunded, you can append a new round — the refund restored your budget. Idempotency is automatic per-tool-args, so retrying after a transport failure is safe — a second call with identical args within 24 hours replays the first round's ack without creating a duplicate (no second round, no second charge).
credit
get_credit
Fetch the caller's current credit wallet balance. Returns `effective_balance_usd` (markup-included, what's left to spend). Rounds are admitted while that balance is above zero, so this is the preflight check outside the write-op flow: above zero means the next round will run; at or below zero means it is refused until top-up or the monthly free-credit reset. `per_model_minimum_usd_default` is also returned, and `pricing.minimum_usd` on `list_models` carries per-model values. Both are reported for reference — they no longer gate admission.
deliberation
create_deliberation
Start a multi-model AI deliberation on a question or decision. Runs the prompt through multiple frontier AI models in parallel and extracts typed reactions (KEEP/EXPLORE/CHALLENGE/CORE/SHIFT) into a claim map of where they agree and diverge. **Returns immediately (async).** The response is a compact ack — `{ session_id, round_id, round_index, status: 'processing', progress_url, ... }` — NOT the finished deliberation. Model execution runs in the background. Call `wait_for_round` to block on cheap progress polling and read the actual responses and claim_map once the round completes (typically 15–120s depending on model choice). `wait_for_round` returns protocol-native `structuredContent` so you can branch on `round_status` / `recommended_client_action` without parsing prose. MCP deliberations are agent-moderated: one round runs, then you decide whether to stop or call `append_round` with follow-up steering. There is no fixed round cap and no autonomous moderator on this surface. Use when you need structured disagreement from independent models, not a single synthesized answer. Ideal for spec review, architectural decisions, or any question where model diversity is a signal. Idempotency is automatic — the adapter derives a stable key from tool arguments, so repeat tool calls with identical args resolve to the same session for 24 hours (no second session, no second charge). A catastrophically-failed round (all providers errored) auto-refunds your budget within 60s; the round won't count against your daily cap.
models
list_models
List the full model catalog. Returns id, provider, display name, context window, max output tokens, pricing, and a per-model `available` verdict for your account (with `unavailable_reason` when false). Nothing is filtered out — `available` is what varies by caller. Call before `create_deliberation` if the user wants specific models. Model IDs from this endpoint are what `create_deliberation`'s `models` parameter expects.
session
get_session
Fetch the full state of a deliberation session including all rounds, responses, snippets, and claim maps. Use to re-read completed session state. While a round is running, prefer `wait_for_round` so you do not repeatedly fetch the full transcript. The claim_map on each round is the highest-signal representation: shows which claims multiple models reacted to, who originated them, and what each reacting model said (KEEP/CHALLENGE/etc + their comment). Use claim_map to identify unresolved disagreements before sending a follow-up. Reactions are the panel's private ledger — participants never see each other's reactions, and as moderator you read them FIRST: the claim map is an advance view of what each model is privately weighing before any of it reaches prose. Use that privileged preview to steer the next round — forward a reaction as a snippet when it deserves the record immediately, or shape your prompt around a collision you can see coming. Authors weave their own strongest notes into their next responses; in later rounds you can compare a prior round's ledger against the prose that followed to spot what was dropped.
sessions
list_sessions
List the caller's deliberation sessions, optionally filtered by status. Most useful for agents managing multiple concurrent sessions — use `status: 'ready'` to find sessions awaiting your next round. Returns a lightweight list (no response bodies); call `get_session` for full content.
share
share_session
Share a deliberation session at a public URL — anyone with the link can view it in the read-only reader deck. Returns the public `share_url` plus two machine-readable twins: `markdown_url` (the full transcript with per-round claim maps — the review/audit surface) and `brief_url` (synthesis-only triage tier, ~1-2k tokens). Hand the markdown twin to a reviewer model, or the share_url to a human — no web UI required. Semantics: idempotent — re-calling returns the same URL. The link is a point-in-time snapshot that auto-refreshes when you've appended rounds since the last share, so after extending a session, call this again to bring the public page current. Sharing never changes the session itself and never lists the page in search engines or the public library (that elevation is a separate platform-curated step). Call when the user wants a shareable link or asks to publish/share results. Requires a registered (non-anonymous) mumo account; sharing generates any missing round takeaways first, so the first share of a long session can take ~15-30s.
wait
wait_for_round
Wait for a deliberation round to finish, then return the full session. This is the agent-friendly follow-up to `create_deliberation` and `append_round`: those tools return a fast ack; this tool polls the lightweight progress endpoint internally and fetches the full transcript only once terminal state is reached. Use this instead of repeatedly calling `get_session` while models are running. The returned claim_map is your advance look at the panel's private notes — nothing in it has reached the other participants yet. Steer with it. **Web-created rounds** (started from the mumo web UI rather than this API) resolve when all model responses have settled — round artifacts (claim map, takeaway) may still be generating at that moment. `claim_map_url` is always present and does not imply the map is ready; if it matters, re-check via `get_session` shortly after. **Structured output.** The response carries both `content[0].text` (human-readable — full session markdown on terminal, short prose summary on timeout) and `structuredContent` matching the tool's `outputSchema`. Branch on `structuredContent.round_status` (`complete` | `partial_failure` | `in_progress` | `failed`) and `recommended_client_action` (`proceed_with_complete_result` | `proceed_with_partial_result` | `poll_again` | `retry` | `abandon`) rather than parsing prose. The schema also exposes per-model `completed_models[]` (with `tokens_in` / `tokens_out` / `finish_reason` / `is_partial`), `in_progress_models[]` (with `partial_text_length` / `last_chunk_at` / `since_last_chunk_ms` / `expired_at_read`), and `failed_models[]` (with canonical `error_code` and any preserved `partial_text`). Always HTTP 200 with explicit semantic state — failed rounds don't crash the tool call.

Endpoints

URLTransportStateLatencyChecked
https://mumo.chat/api/mcp streamable-http answering 86 ms 12 min ago

Alternatives to mumo

same job, measured the same way
Omnarai MCP
by justjlee

Deliberation + live 5-model council divergence over the Omnarai multi-AI attributed corpus.

44 installs/wk 8 tools answering
Cisco Modeling Labs CML
by xorrkaz

An MCP server that provides access to common Cisco Modeling Labs (CML) operations.

1 099 installs/wk local only
Linksee Memory
by michielinksee

Hand a project over with the reasons attached. Local-first cross-agent memory MCP + drift detection.

79 installs/wk local only
Deixis
by jolars

Typed LSP operations for MCP clients.

local only
Gessa: game asset generation for AI agents
by gessa

Generate game-ready 3D models, textures, and audio from natural language, over MCP.

29 installs/wk answering
Meok AI Reflection MCP
by csoai-org

MEOK AI Labs - ai-reflection MCP server extracted from SOV3

136 installs/wk local only
Multi-MCP
by religa

Multi-model AI orchestration MCP server with code review, compare, and debate tools.

64 installs/wk local only
plantcv-mcp
by musharna

Plant phenotyping via PlantCV — returns traits plus the segmentation overlay they came from

5 670 installs/wk local only

mumo — questions

Answers built from our own checks of this server.

What can mumo do?
It exposes 8 tools, read directly from the server on our last check. Among them: append_round, create_deliberation, get_credit, get_session, list_models, list_sessions and 2 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is mumo working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 2 of 91 checks got a reply (2.2%), average response time 559 ms. The bar chart above shows every period we have measured.
The registry lists mumo as active — why does it not respond?
The official MCP registry stores what the author submitted; it does not verify that the server still runs. We check the endpoint ourselves, and this one does not answer. Catalogues that copy the registry without checking will show it as working.
How do I connect mumo?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does mumo need an API key?
No. mumo completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 8 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is mumo?
It answers our handshake in 559 ms on average, which is faster than 27% of all working MCP servers we measure. The comparison comes from our own checks across the whole registry, every 15 minutes.
Is mumo open source?
Yes — it is published under the MIT licence, written in JavaScript and 0 stars on GitHub. The source link is on this page, so you can read exactly what it does with your data before you connect it.