Offline MCP vs Lm
A side-by-side look at the Offline MCP and Lm MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Offline MCP for conversational ai work as a local process; choose Lm for conversational ai as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Offline MCP when
- You need dedicated capabilities in the Conversational AI domain.
- You prefer a local stdio subprocess transport.
- You want tools like
check_ollama_status, run_local_inference, list_recommended_models.
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.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Conversational AI | Conversational AI |
| Quality signal | 57/100 · Good | 67/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 121 |
| Directory activity | 1 views 0 installs 0 upvotes | 0 views 0 installs 0 upvotes |
| Tools | 6 | 8 |
| Full listing | View Offline MCP | View Lm |
Tools & capabilities
Offline MCP tools 6
check_ollama_statusCheck whether a local Ollama server is running at localhost:11434 and which models it has. Use before run_local_inference, or when someone asks whether offline AI is ready. Takes no arguments and contacts only your own machine (3 second timeout). Returns ollama_running, the model names, a count and the endpoint, or ollama_running false with the error and a link to the official download page. Read-only: it only lists models.run_local_inferenceSend a prompt to a local Ollama model and return its answer, with no internet needed once the model is downloaded. Use when no cloud model is reachable or the text must stay on the machine. The prompt goes only to Ollama at localhost:11434 (60 second timeout, non-streaming) and nothing is stored by this tool. Returns the response text, the model used, the token count and offline true, or an error with a hint to start Ollama if it is not running. Read-only with respect to your data; it uses local compute, and answers from small models can be wrong.list_recommended_modelsRecommend open-weights models that run locally through Ollama, with size, RAM need, use case and language fit for Africa. Use when someone asks which model to install for their hardware or task. max_ram_gb keeps models that fit; use_case filters by matching text and, if nothing matches, ALL models are returned. Returns the source label, the recommended models, their install commands and a note that they run locally. A curated list labelled by the author, not a benchmark: check model cards. Read-only; no side effects.degraded_mode_guideGuide to running AI when connectivity or power is unreliable: why it matters, how to install Ollama, pull a small model, test it and point MCP clients at localhost, with hardware minimums and a Raspberry Pi note. Use when planning an offline or low-bandwidth deployment. Takes no arguments. Returns the explanation, numbered setup steps, hardware minimums and deployment tips. A static guide: follow the vendor's own install instructions at ollama.com. Read-only; no side effects.open_weights_directoryDirectory of open-weights model families with sizes, languages and licences, including African-language support such as Aya and Masakhane work, plus speech and translation resources (WAXAL, Paza, AfriNLLB, TranslateGemma) with their licences. Use when someone asks which open models or datasets cover Swahili or other African languages, or what the licence allows. use_case filters the language models by matching text; if nothing matches, ALL models are returned. Returns the source label, the language models, an Africa note, how to deploy them locally and the speech and translation resources with licence and coverage caveats. A curated starting list, not exhaustive or benchmarked: check each model card for languages and licence. Read-only; no side effects.local_deployment_guideSetup guide for running a local model on a device type: laptop, Raspberry Pi and others in the table, with hardware, install steps and a model suggestion. Use when someone asks how to deploy offline AI on specific hardware. An unrecognised device_type returns the laptop guide. Returns the source label, the device_type, the guide, all_options and a solar note. A static guide: follow the vendor's install instructions. Read-only; no side effects.
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.
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.
Offline MCP
{
"mcpServers": {
"offline-mcp": {
"command": "uvx",
"args": [
"offline-mcp"
]
}
}
}
Lm
{
"mcpServers": {
"lm": {
"command": "npx",
"args": [
"-y",
"@houtini/lm"
]
}
}
}
Frequently asked questions
Offline MCP is categorized under Conversational AI and uses a local stdio subprocess. Lm belongs to Conversational AI and uses a local stdio subprocess. Pick Offline MCP for conversational ai work and Lm 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.
Offline MCP has no declared pricing — check the project's own site. Lm has no declared pricing — check the project's own site. 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 offline-mcp and lm as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Offline MCP has a quality signal of 57/100 (Good) with 1 views, 0 installs and 0 GitHub stars. Lm has 67/100 (Great) with 0 views, 0 installs and 121 GitHub stars.