Local AI MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OLLAMA_HOST | No | Ollama base URL (scheme optional; added if missing). | http://localhost:11434 |
| LMSTUDIO_HOST | No | LM Studio base URL. | http://localhost:1234 |
| LOCAL_AI_DETECT_TIMEOUT_MS | No | Timeout for provider auto-detection probes. | 1500 |
| LOCAL_AI_REQUEST_TIMEOUT_MS | No | Timeout for normal requests (inference, pull progress, etc.). | 120000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Local AI MCP manages local model runtimes. Start with list_providers / system_resources. To offload work, prefer delegate (picks and readies the best local model) or complete with a specific model. Inference never goes to a hosted API unless a hosted provider is named explicitly.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": true,
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_providersA | List configured model runtimes (Ollama, LM Studio, llama.cpp, Docker Model Runner, and any opt-in MLX / vLLM / Foundry Local / OpenAI-compatible / hosted instances) with host, kind (local or hosted), live status, and capabilities. |
| list_modelsA | List models installed/available on each live provider, keyed by provider. Pass provider to query just one. |
| list_loadedA | List models currently loaded into memory on each live provider, with VRAM use and context length where the runtime reports them. |
| model_infoA | Detailed metadata for one model (family, parameter size, quantization, context length, and layer architecture where available). Without provider, queries the live local providers that have the model. |
| pull_modelA | HEAVY: Download a model onto ONE provider (multiple GB, can take a long time). Streams download progress via MCP progress notifications when the client sends a progressToken. With background:true, returns a jobId immediately instead; poll pull_status and stop it with pull_cancel (use this when the client has no progress display or a short tool timeout). Without provider, uses the provider that already has the model, else the first live local provider that can pull. |
| pull_statusA | Status of background pulls started with pull_model { background: true }: state (running, done, failed, cancelled), progress, and result or error. Without jobId, lists every job this server remembers (finished jobs are kept for an hour; jobs are forgotten on restart). |
| pull_cancelA | Stop a background pull started with pull_model { background: true }. Finished jobs are returned unchanged. |
| remove_modelA | DESTRUCTIVE: Permanently delete a model from one provider. provider is REQUIRED (no fan-out). If the client supports elicitation the user is asked to confirm directly; otherwise confirm:true is required. |
| load_modelA | Load a model into memory on ONE provider so it is ready for inference. Optional keepAlive (e.g. '5m', '1h') and contextLength. Without provider, uses the live local provider that has the model. |
| unload_modelA | Unload a model from memory to free VRAM/RAM on ONE provider. Without provider, uses the live local provider that has it loaded. |
| ensure_modelA | Make a model ready in one call: optionally pull it, check it fits current free VRAM, unload other models if needed (evict: 'lru' or 'all'), load it, and verify. Use dryRun:true to get the plan without changing anything. |
| health_checkA | Check whether each provider is reachable and report its version (and live metrics such as vLLM KV-cache usage). Without provider, checks every configured provider, including hosted ones. |
| diagnosticsA | One read-only snapshot for troubleshooting: the effective configuration (API keys never shown, only whether one is set), every configured provider with its detection result, latency and error, the benchmark speed cache, and how hardware was probed. Paste its output into bug reports. |
| system_resourcesA | Report local hardware: platform, total/available RAM, CPU count, and GPUs with total/free VRAM (NVIDIA via nvidia-smi, AMD/Intel via sysfs or the Windows registry, Apple Silicon unified memory). Each GPU names its data source. |
| fit_checkA | Will a model run on this machine, and where? Uses the installed model's size and exact layer architecture when the runtime exposes it (else parameter-count or catalog estimates) to size weights + KV cache for a context length, then compares with free VRAM summed across GPUs and available RAM. Returns target gpu / partial (GPU+CPU split) / cpu / none, with the numbers and how the KV estimate was made. Credits back memory the model already uses if it is loaded. |
| benchmarkA | HEAVY: Runs REAL inference. Measures a model on this machine with a warmup (absorbs load time) plus N streamed runs: time-to-first-token, generation tokens/sec (runtime-reported when available, else measured after the first token), and prompt-processing speed. Pass models[] to compare several models with the same prompt, ranked by generation speed. |
| search_availableA | Search the built-in curated catalog of well-known local models (Ollama tags) by name, family, or task. Offline and instant. For live results with per-quant fit, use search_models with source 'huggingface'. |
| suggest_modelA | Recommend catalog models for a task, ranked for THIS machine: fully-on-GPU first, then partial GPU offload, then CPU-only. Within a tier the largest (most capable) model comes first unless preferSpeed is true. Flags models already installed on a live provider and explains each pick. |
| search_modelsA | Find models to download, annotated with whether each fits this machine. source 'huggingface' searches GGUF repos on the Hugging Face Hub and returns per-quant sizes, the best quant for this hardware, and pullable references (Ollama: hf.co/:). source 'catalog' searches the offline curated list. The Ollama library has no public search API, so it is not a source. |
| completeA | DELEGATED INFERENCE: Offload a completion to a model you choose for cost savings and privacy. Without provider, runs on the live LOCAL provider that has the model (never a hosted API unless LOCAL_AI_ALLOW_HOSTED_FALLBACK is set); the result's 'provider', 'host' and 'local' fields say where it ran. Supports system prompts, JSON / JSON-Schema output (validated 'parsed' field), seed/topP/topK, image inputs for vision models, and contextLength for long inputs. Streams tokens via MCP progress notifications when the client sends a progressToken. |
| embedA | DELEGATED EMBEDDINGS: Generate embeddings for a string or an array of texts. Without provider, runs on the live local provider that has the model. Always returns one vector per input. |
| delegateA | ONE CALL to offload work locally: pick the best model for a task on THIS machine, make it ready, and run it. Prefers models already loaded (no load cost), then installed models that fit your free VRAM, then (with allowPull) the best catalog model that fits. Task specialists (coder, vision, reasoning) win over general models; then larger fitting models win, grouped into size tiers (within ~20% parameter count); inside a tier, the model benchmarked fastest on this machine wins (run benchmark to record speeds; results expire after 14 days). Never uses a hosted provider unless allowHosted is true (or, when allowHosted is omitted, LOCAL_AI_ALLOW_HOSTED_FALLBACK is set), and even then any suitable local model is preferred. Models that only fit in system RAM run on CPU when nothing fits the GPU. Returns the completion plus a 'routing' block explaining the choice. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| setup | Detect runtimes and hardware, then recommend (and optionally install) a starter model that fits |
| free-vram | See what is loaded and unload what is not needed |
| benchmark-my-models | Compare the speed of installed models on this machine |
| pick-model | Find the best model for a task on this hardware |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| system | RAM, CPU and GPU/VRAM snapshot |
| loaded | Models resident in memory on each live provider |
| models-ollama | Models installed on one provider |
| models-lmstudio | Models installed on one provider |
| models-llamacpp | Models installed on one provider |
| models-dockermodelrunner | Models installed on one provider |
TDQS
Scored across 22 tools
Most tools map to a distinct resource (providers, models, hardware, pulls), but several pairs overlap meaningfully: search_available is explicitly a subset of search_models (source 'catalog'), diagnostics partially duplicates health_check + system_resources, and ensure_model overlaps with the pull_model/load_model/fit_check combination. complete vs delegate is also a judgement call for an agent, since both run inference and only the description clarifies which to pick. Descriptions do a lot of work to disambiguate, keeping this above a 2.
The dominant pattern is snake_case verb_noun (pull_model, list_models, search_models, remove_model, suggest_model), but it is mixed with noun_noun (model_info, system_resources, health_check, fit_check) and bare single-word tools (complete, delegate, embed, benchmark, diagnostics). Everything is readable and there is some within-family consistency (list_*, pull_*, search_*), but the overall set does not follow one predictable convention.
22 tools is on the heavy side for a local-runtime manager, and a few do not clearly earn their place: search_available is redundant with search_models, and pull_status/pull_cancel are arguably one job-status tool. The remaining surface (lifecycle, discovery, hardware, inference) is defensible, so this sits at borderline rather than excessive.
The model lifecycle is well covered end to end: search/suggest, pull with background jobs, load/unload, fit check, benchmark, delete, plus inference (complete/delegate/embed) and hardware/diagnostics. Minor gaps remain, notably no way to add or edit provider configuration, no model copy/alias/rename, and no way to cancel long-running non-pull work such as benchmark. These are workaround-able rather than blocking.