Permite a Claude Desktop consultar y gestionar un servidor local de Ollama. Lista los modelos instalados, inspéccionalos, ejecuta completados de generate/chat de una sola vez contra cualquier modelo local, o descarga/elimina modelos del registro, todo ello sin abrir una terminal.
Uso típico: comparar la respuesta de Claude con un modelo local ante el mismo prompt, ejecutar completados masivos económicos contra un modelo cuantizado, o comprobar modelos de puntos de control de entrenamiento personalizados que hayas importado a Ollama.
Un servidor de Ollama en ejecución (ollama serve o la aplicación de Ollama).
El endpoint predeterminado es http://localhost:11434. Puedes sobrescribirlo mediante la configuración de usuario ollama_url en los ajustes de extensión de Claude Desktop si ejecutas Ollama en un host o puerto diferente.
Sin dependencias de npm: Node puro sobre la API HTTP.
Related MCP server: Ollama MCP Server
Descarga el archivo Ollama.mcpb más reciente desde la página de Releases.
En Claude Desktop: Settings → Extensions → Extension Developer → Install Extension → selecciona el archivo .mcpb.
(Opcional) En los ajustes de la extensión, configura la Ollama server URL si ejecutas Ollama en un host/puerto distinto al predeterminado. Déjalo en blanco para http://localhost:11434.
Herramienta | Anotación | Propósito |
| solo lectura | Comprobación de estado + versión del servidor |
| solo lectura | Modelos locales con tamaño, resumen, familia, tamaño de parámetros, cuantización |
| solo lectura | Modelos cargados actualmente en la VRAM |
| solo lectura | Detalles del modelo: modelfile, parámetros, plantilla, capacidades |
| mundo abierto | Completado de texto de una sola vez (sin streaming) |
| mundo abierto | Completado de chat con historial de mensajes (sin streaming) |
| mundo abierto | Descargar un modelo del registro |
| destructivo | Eliminar un modelo instalado localmente |
"¿Qué modelos locales tengo instalados y cuál está cargado actualmente en la VRAM?"
"Ejecuta
forge:b6c1con este prompt: ''. Compara ese resultado con tu propia respuesta.""Muéstrame el modelfile de
forge:b7c1: quiero comprobar el ajuste de temperatura.""Descarga
llama3.1:70b." (espera una larga espera para modelos grandes)"Elimina el modelo
forge:b5c3: ya no necesito ese punto de control."
Esta extensión se ejecuta completamente en tu máquina local y envía solicitudes HTTP solo a tu servidor de Ollama (predeterminado http://localhost:11434). Ningún dato sale de tu máquina a menos que configures explícitamente ollama_url para apuntar a una instancia remota de Ollama, en cuyo caso los prompts y las respuestas viajarán a ese servidor.
La información visible para Claude incluye:
Todos los prompts y mensajes de chat que pases a generate y chat (estos van al servidor de Ollama, que puede registrarlos dependiendo de su configuración).
Texto completo de los completados devueltos por Ollama.
Metadatos de cada modelo instalado (nombres, resúmenes, tamaños, cuantización, contenido del modelfile).
Qué modelos están cargados actualmente en la VRAM y su huella de tamaño.
Si tienes modelos instalados que contienen ajustes finos propietarios o modelfiles con metadatos sensibles, ten en cuenta que Claude verá esa información cuando llames a show_model o list_models.
delete_model es destructivo y no se puede deshacer desde esta extensión: el modelo debe volver a descargarse del registro (o reimportarse desde los blobs de origen) si se elimina por error.
"cannot reach Ollama at http://localhost:11434 — is the server running?" — Inicia Ollama con ollama serve o abre la aplicación de Ollama. Verifica con curl http://localhost:11434/ (debería devolver "Ollama is running").
pull_model se queda bloqueado durante mucho tiempo — La API de descarga de Ollama con stream: false se bloquea hasta que se completa la descarga total, lo cual para modelos de varios GB puede llevar muchos minutos. Si estás descargando un modelo enorme, ejecuta ollama pull <name> en una terminal; allí verás el progreso del streaming, y las llamadas posteriores de MCP encontrarán el modelo ya instalado.
Endpoint de Ollama personalizado/remoto — Configura ollama_url en los ajustes de la extensión (ej. http://192.168.1.42:11434). Requiere reiniciar la extensión.
list_running muestra un modelo después de que dejaste de usarlo — Ollama mantiene los modelos activos en la VRAM durante un TTL configurable (predeterminado 5 minutos). La marca de tiempo expires_at te indica cuándo se descargará. Este es el comportamiento de Ollama, no de la extensión.
Script de Node.js único de ~400 líneas, cero dependencias de npm. Reconstruye el .mcpb:
cd bundle-source
zip -j ../Ollama.mcpb manifest.json package.json server.js README.md LICENSE icon.png glama.jsonMIT. Consulta LICENSE.
claude-terminal-mcp — shell, sistema de archivos y trabajos en segundo plano.
claude-rocm-mcp — monitorización de GPU AMD; combina bien para comprobar si el modelo cargado de Ollama está saturando la VRAM.
claude-sessions-mcp — gestión de sesiones tmux para trabajos de larga duración.
claude-linux-mcp — control de escritorio X11.
Run a chat completion against a local model with message history (non-streaming). Returns the assistant's reply plus timing.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name. | |
| messages | Yes | Chat history. Each item: {role: "system"|"user"|"assistant", content: string}. | |
| options | No | Ollama sampling/decoding options. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readonly and non-destructive, but description adds 'non-streaming' and 'returns timing'. However, it does not disclose potential side effects (e.g., model state changes) or permission requirements beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence of 15 words. It efficiently conveys the core action, key features (non-streaming, message history), and output (reply + timing) with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, openWorldHint=true, no output schema), the description mentions return type but is vague about timing structure and does not cover error cases or model availability. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no additional parameter details beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a chat completion with message history (non-streaming) and returns reply plus timing. It differentiates from siblings like 'generate' by emphasizing message history and non-streaming, but does not explicitly compare to all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use cases via 'with message history' and 'non-streaming', but provides no explicit guidance on when to use this tool versus alternatives like 'generate' or 'pull_model'. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a locally-installed model. Does not affect the remote registry copy. Free the disk space of a model you no longer need.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Model name to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only nature. The description adds valuable context: 'Does not affect the remote registry copy' and 'Free the disk space', which goes beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficiently front-loaded with purpose and key behavioral constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one required param, no output schema), the description fully covers purpose, scope, and side effect. Annotations provide safety profile. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'name', so the tool description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Delete' and the resource 'locally-installed model', and distinguishes from sibling tools like pull_model, list_models, etc. by specifying local scope and effect (freeing disk space).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you no longer need a model and want to free disk space, but does not explicitly state when not to use or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a one-shot text completion against a local model (non-streaming). Returns the full response text plus timing and tokens/second.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name (e.g. "llama3.1:8b"). | |
| prompt | Yes | Prompt text. | |
| system | No | Optional system prompt. | |
| options | No | Ollama sampling/decoding options — e.g. {"temperature": 0.7, "num_predict": 100, "top_p": 0.9}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive, and open-world. The description adds behavioral details: non-streaming, returns full text plus timing/tokens/second, which goes beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loads the core purpose (one-shot completion) and key behaviors (non-streaming, returns timing/tokens). Every word adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage, annotations, and no output schema, the description sufficiently covers the tool's purpose, behavior, and return values. No critical information missing for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description adds no additional parameter-specific information beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a one-shot text completion (verb+resource) and specifies it's non-streaming, distinguishing it from siblings like 'chat' which may be streaming or multi-turn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for one-shot completions and non-streaming needs, providing clear context. However, it does not explicitly mention alternatives or when not to use it, so it misses a full exclusion guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List locally-installed models: name, size in bytes, digest, modified timestamp, family (e.g. llama), parameter size (e.g. 8.0B), and quantization level (e.g. Q4_K_M).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing the exact fields returned (size, digest, family, params, quantization), providing context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates purpose and return fields with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully documents the return fields. Combined with annotations, it provides complete context for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description correctly avoids adding redundant parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List locally-installed models' and enumerates the specific fields returned. This distinguishes it from sibling tools like list_running (running models) and show_model (single model details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing all installed models but provides no explicit guidance on when to use this tool versus alternatives (e.g., show_model for details, list_running for active models).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List models currently loaded into VRAM with their size, VRAM footprint, and expiry timestamp. Empty list means Ollama is idle.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool returns specific fields (size, VRAM footprint, expiry timestamp), enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb, no wasted words. Achieves maximum clarity with minimal text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes the tool's function and output given the lack of parameters and output schema. The note about empty list provides complete context for the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined; the description does not need to add parameter details. Baseline score of 4 applies as there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('models currently loaded into VRAM'), and distinguishes from sibling 'list_models' by specifying the loading status. It also mentions the returned fields (size, VRAM footprint, expiry timestamp).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking current VRAM load and idle status ('Empty list means Ollama is idle'), but does not explicitly mention when to use it vs alternatives like 'list_models' or 'ollama_status'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check: whether the Ollama server is reachable and its version. Use this as a precondition before other tools if you're unsure whether Ollama is running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description adds that the tool returns reachability and version info. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no superfluous information. Purpose and usage are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete: it explains what it does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline score of 4 applies. The description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as a health check for the Ollama server, checking reachability and version. It distinguishes itself from sibling tools like chat or generate, which interact with models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this as a precondition before other tools when unsure if Ollama is running, providing clear when-to-use guidance and implying alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a model from the Ollama registry. Blocks until complete — can take a long time for multi-GB models. For very large pulls, prefer ollama pull in a terminal where you can watch progress.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Model name to pull (e.g. "llama3.1:8b"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool blocks until completion and can take a long time, which are important behavioral traits not captured by annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true). It does not elaborate on authentication or error handling, but the blocking behavior is a key disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and every sentence adds value. No redundant or irrelevant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description adequately covers purpose, behavioral aspects, and usage advice. It could mention success indicators or behavior on existing models, but the current level is sufficient for a simple pull operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage (100%) with a description for the 'name' parameter including an example. The tool description does not add additional meaning beyond what the schema already conveys, hence a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a model from the Ollama registry, with a specific verb ('Download') and resource ('model from the Ollama registry'). It distinguishes itself from sibling tools like 'delete_model' and 'generate' by focusing solely on pulling models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises preferring the terminal `ollama pull` for very large models, giving explicit guidance on when to avoid this tool. However, it does not compare against other server tools (e.g., not to use if model is already present), but the external alternative is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show detailed information for a specific model: modelfile excerpt, parameters, template, capabilities, architecture details, quantization level.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Model name (e.g. "llama3.1:8b" or "forge:b6c1"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about the returned content but does not disclose additional behaviors like rate limits or authentication needs beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the tool's purpose and lists key details without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one parameter), good annotations, and no output schema, the description adequately explains the return content (modelfile excerpt, parameters, etc.), making it fairly complete for an agent to understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the 'name' parameter with an example. The description does not add additional meaning for the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows detailed information for a specific model and enumerates the types of details (modelfile, parameters, etc.), distinguishing it from siblings like list_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context makes it clear that this tool is for retrieving details on a single model versus listing all models (list_models) or chatting (chat), but no explicit when-not or alternative names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0chatdelete_modelgeneratelist_modelslist_runningollama_statuspull_modelshow_modelScored across 8 tools
Each tool has a clearly distinct purpose: chat vs generate differentiate by context (with/without history); model management tools (list, pull, delete, show, list_running) are non-overlapping; ollama_status is a standalone health check. No ambiguity in roles.
Most names follow a verb_noun pattern (e.g., delete_model, list_models, pull_model). 'chat' and 'generate' are single verbs but still actions. 'ollama_status' deviates slightly (noun_noun) but is readable. Overall consistent with minor exceptions.
8 tools cover the essential operations for a local Ollama server: model management (list, pull, delete, show, list_running), two inference modes (chat, generate), and a health check. Well-scoped without bloat or deficiency.
Core CRUD and inference are covered, but streaming support is absent (only non-streaming provided). No tool to adjust model parameters or embeddings. Minor gaps for advanced use, but sufficient for standard workflows.
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Use your Mac, Windows or Linux computer from ChatGPT, Claude or Codex: files, commands, documents.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
