Lm vs Mumo MCP
A side-by-side look at the Lm and Mumo MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Lm for conversational ai work as a local process; choose Mumo MCP for conversational ai over a hosted endpoint. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Lm when
- You need dedicated capabilities in the Conversational AI domain.
- You prefer a local stdio subprocess transport.
- You want tools like
chat, custom_prompt, code_task.
Choose Mumo MCP when
- You need dedicated capabilities in the Conversational AI domain.
- You prefer a remote HTTP/SSE transport.
- Its auth model fits you: No auth required.
- You want tools like
create_deliberation, append_round, wait_for_round.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Conversational AI | Conversational AI |
| Quality signal | 67/100 · Great | 67/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Remote HTTP/SSE |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 121 | 0 |
| Directory activity | 0 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 8 | 8 |
| Full listing | View Lm | View Mumo MCP |
Tools & capabilities
Lm tools 8
chatSend a task to a local LLM - a sidekick running on the user's hardware or a configured OpenAI-compatible endpoint. It does not consume the user's Claude quota. Trades latency for tokens: local inference is typically 3-30× slower than frontier models, so delegation wins when the task is bounded and self-contained. Good fit: • Explain or summarise code/docs you already have in context • Generate boilerplate, test stubs, type definitions, mock data • Answer factual questions about languages, frameworks, APIs • Draft commit messages, PR descriptions, comments • Translate or reformat content (JSON↔YAML, snake_case↔camelCase) • Brainstorm approaches before committing to one Less good when: the task needs tool access, depends on multi-file context you have not captured, or is quick enough for you to answer directly before the round-trip completes. Prompt tips (local models take instructions literally): (1) Send COMPLETE context - the local LLM cannot read files. (2) Be explicit about output format ("respond as a JSON array", "return only the function"). (3) Specific system persona beats generic - "Senior TypeScript dev" not "helpful assistant". (4) State constraints - "no preamble", "reference line numbers", "max 5 bullets". (5) Leave max_tokens UNSET - the server sizes the budget from the model's real context window. Tiny caps like 256 waste the model: reasoning burns the budget before any visible output. Routing picks the best loaded model automatically. Call `discover` to see what is loaded and, after the first real call, its measured speed. The footer shows cumulative tokens offloaded.custom_promptStructured analysis via the local LLM with explicit system/context/instruction separation. The 3-part format prevents context bleed in smaller models - the local LLM acknowledges the context in a fake assistant turn before receiving the instruction. Good fit when prompt structure matters: • Code review - paste full source, ask for bugs/improvements • Comparison - paste two implementations, ask which is better and why • Refactoring suggestions - paste code, ask for a cleaner version • Content analysis - paste text, ask for structure/tone/issues • Any task where separating context from instruction improves clarity Field guidance (each has a job - keep them focused): • system: persona + constraints, under 30 words. "Expert Python developer focused on performance and correctness." • context: COMPLETE data - full source, full logs, full text. Never truncate. • instruction: exactly what to produce, under 50 words. Specify format: "Return a JSON array of {line, issue, fix}." Review the output before acting on it - local model capability varies.code_taskSend a code-specific task to the local LLM, wrapped with an optimised code-review system prompt. Temperature is locked low (0.2 or the routed model's hint) for deterministic output. Good fit: • Explain what a function/class does • Find bugs or suggest improvements • Generate unit tests or type definitions for existing code • Add error handling, logging, or validation • Convert between languages or patterns For best results: • Provide COMPLETE source - the local LLM cannot read files. • Include imports and type definitions so the model has full context. • Be specific: "Write 3 Jest tests for the error paths in fetchUser" beats "Write tests". • Set the language field - it shapes the system prompt and improves accuracy. Verify generated code compiles, handles edge cases, and follows project conventions before committing.code_task_filesLike code_task, but the local LLM reads files directly from disk - source never passes through the MCP client's context window. Use when reviewing multiple files or a single large file. How it works: • Provide absolute paths. Relative paths are rejected. • Files are read in parallel (Promise.allSettled) - one unreadable file does not sink the call. • Files are concatenated with `=== filename ===` headers and sent to the same code-review pipeline as code_task. • Read failures are surfaced inline with the reason so the LLM can still reason about the rest. • Pre-flight prefill estimate: if measured per-model data shows the input would exceed the MCP client's ~60s request timeout during prompt processing, the call is refused early with a diagnostic instead of hanging. Split or trim when this fires. Good fit: • Reviewing related files together (module + its tests, client + server pair) • Auditing a single large file too big to paste comfortably • Any code_task where keeping source out of the Claude context window matters Size guidance: on slow hardware (< 25 tok/s generation), keep total input under ~8,000 tokens (~32,000 chars) to stay safely under the client timeout. Faster hardware handles much more - the pre-flight estimator adapts once you've done a few calls and real per-model timings are in the SQLite cache. Same review discipline as code_task - verify the output before acting on it.discoverCheck whether the local LLM is online and what model is loaded. Returns model name, context window size, response latency, and cumulative session stats (tokens offloaded so far). Call this if you are unsure whether the local LLM is available before delegating work. Fast - typically responds in under 1 second, or returns an offline status within 5 seconds if the host is unreachable.list_modelsList all models on the local LLM server - both loaded (ready) and available (downloaded but not active). Shows rich metadata for each model: type (llm/vlm/embeddings), architecture, quantization, context window, and a capability profile describing what the model is best at. Use this to understand which models are available and suggest switching when a different model would suit the task better.embedGenerate text embeddings via the local LLM server. Requires an embedding model to be loaded (e.g. Nomic Embed). Returns a vector representation of the input text for semantic search, similarity comparison, or RAG pipelines. Uses the OpenAI-compatible /v1/embeddings endpoint.statsShow user stats: tokens offloaded, calls made, per-model performance - for the current session AND lifetime (persisted in SQLite at ~/.houtini-lm/model-cache.db). Unlike `discover` which includes the model catalog, `stats` returns just the numbers in a compact markdown table - cheap to call repeatedly to see the 💰 offloaded counter climb. Useful for quantifying how much work the local model is genuinely doing, and for noticing when a model's reasoning-token ratio is drifting.
Mumo MCP tools 8
create_deliberationStart 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.append_roundAdd 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).wait_for_roundWait 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` / `output_cap`), `in_progress_models[]` (with `partial_text_length` / `last_chunk_at` / `since_last_chunk_ms` / `expired_at_read`), and `failed_models[]` (with canonical `error_code`, `output_cap` and any preserved `partial_text`). `output_cap` is null unless a platform cap bound the call: `{ tokens, reason }` with reason `guest` (guest output limit) or `balance` (the remaining credit bounded the output — top up or wait for the reset rather than retrying). Always HTTP 200 with explicit semantic state — failed rounds don't crash the tool call.get_sessionFetch 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.list_sessionsList 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.list_modelsList 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.share_sessionShare 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.get_creditFetch the caller's current credit wallet balance. Returns `effective_balance_usd` (markup-included, what's left to spend). At or below zero, every new round is refused until top-up or the monthly free-credit reset. Above zero, a round is admitted when the balance also covers that round's minimum (each model's reserved output plus input and the post-round reactions/takeaway) — a per-request check, so a low positive balance can still refuse a large panel with `credit_exhausted`, whose `required_usd` names the minimum and `affordable_alternatives` the rosters that fit (from `create_deliberation` only; always empty from `append_round`). `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.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Lm
{
"mcpServers": {
"lm": {
"command": "npx",
"args": [
"-y",
"@houtini/lm"
]
}
}
}
Mumo MCP
{
"mcpServers": {
"mcp-46": {
"url": "https://mumo.chat/api/mcp"
}
}
}
Frequently asked questions
Lm is categorized under Conversational AI and uses a local stdio subprocess. Mumo MCP belongs to Conversational AI and uses a remote HTTP/SSE transport. Pick Lm for conversational ai work and Mumo MCP for conversational ai.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Lm has no declared pricing — check the project's own site. Mumo MCP has no declared pricing — check the project's own site. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add lm and mcp-46 as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Lm has a quality signal of 67/100 (Great) with 0 views, 0 installs and 121 GitHub stars. Mumo MCP has 67/100 (Great) with 1 views, 0 installs and 0 GitHub stars.