Skip to main content
Glama
Local AI MCP

Local AI MCP

Official
by TMHSDigital

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
OLLAMA_HOSTNoOllama base URL (scheme optional; added if missing).http://localhost:11434
LMSTUDIO_HOSTNoLM Studio base URL.http://localhost:1234
LOCAL_AI_DETECT_TIMEOUT_MSNoTimeout for provider auto-detection probes.1500
LOCAL_AI_REQUEST_TIMEOUT_MSNoTimeout 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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "subscribe": true,
  "listChanged": true
}
completions
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription
setupDetect runtimes and hardware, then recommend (and optionally install) a starter model that fits
free-vramSee what is loaded and unload what is not needed
benchmark-my-modelsCompare the speed of installed models on this machine
pick-modelFind the best model for a task on this hardware

Resources

Contextual data attached and managed by the client

NameDescription
systemRAM, CPU and GPU/VRAM snapshot
loadedModels resident in memory on each live provider
models-ollamaModels installed on one provider
models-lmstudioModels installed on one provider
models-llamacppModels installed on one provider
models-dockermodelrunnerModels installed on one provider

TDQS

A3.7/5.0

Scored across 22 tools

Disambiguation3/5

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.

Naming Consistency3/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessSyncing