Provides tools to query and manage a local Ollama server, including listing installed models, running text completions (generate/chat), pulling models from the registry, deleting models, and checking server status.
Lets Claude Desktop query and manage a local Ollama server. List installed models, inspect them, run one-shot generate/chat completions against any local model, or pull/delete models from the registry — all without opening a terminal.
Typical use: comparing Claude's answer to a local model on the same prompt, running cheap bulk completions against a quantized model, or checking custom training-checkpoint models you've imported into Ollama.
A running Ollama server (ollama serve or the Ollama app).
Default endpoint is http://localhost:11434. Override via the ollama_url user config in Claude Desktop's extension settings if you run Ollama on a different host or port.
No npm dependencies — pure Node over the HTTP API.
Related MCP server: Ollama MCP Server
Download the latest Ollama.mcpb from the Releases page.
In Claude Desktop: Settings → Extensions → Extension Developer → Install Extension → pick the .mcpb.
(Optional) In the extension's settings, set Ollama server URL if you run Ollama on a non-default host/port. Leave blank for http://localhost:11434.
Tool | Annotation | Purpose |
| read-only | Health check + server version |
| read-only | Local models with size, digest, family, parameter size, quantization |
| read-only | Models currently loaded in VRAM |
| read-only | Model details: modelfile, parameters, template, capabilities |
| open-world | One-shot text completion (non-streaming) |
| open-world | Chat completion with message history (non-streaming) |
| open-world | Download a model from the registry |
| destructive | Remove a locally-installed model |
"Which local models do I have installed, and which one is currently loaded in VRAM?"
"Run
forge:b6c1on this prompt: ''. Compare that output to your own answer.""Show me the modelfile for
forge:b7c1— I want to check the temperature setting.""Pull
llama3.1:70b." (expect a long wait for large models)"Delete the
forge:b5c3model — I don't need that checkpoint anymore."
This extension runs entirely on your local machine and sends HTTP requests only to your Ollama server (default http://localhost:11434). No data leaves your machine unless you explicitly configure ollama_url to point at a remote Ollama instance, in which case the prompts and responses travel to that server.
The information visible to Claude includes:
All prompts and chat messages you pass to generate and chat (these go to the Ollama server, which may log them depending on its configuration).
Full text of completions returned by Ollama.
Metadata for every installed model (names, digests, sizes, quantization, modelfile contents).
Which models are currently loaded in VRAM and their size footprint.
If you have installed models containing proprietary fine-tunes or modelfiles with sensitive metadata, note that Claude will see that information when you call show_model or list_models.
delete_model is destructive and cannot be undone from this extension — the model must be re-pulled from the registry (or re-imported from source blobs) if deleted by mistake.
"cannot reach Ollama at http://localhost:11434 — is the server running?" — Start Ollama with ollama serve or launch the Ollama app. Verify with curl http://localhost:11434/ (should return "Ollama is running").
pull_model hangs for a long time — Ollama's pull API with stream: false blocks until the full download completes, which for multi-GB models can take many minutes. If you're pulling a huge model, run ollama pull <name> in a terminal instead — you'll see streaming progress there, and subsequent MCP calls will find the model already installed.
Custom/remote Ollama endpoint — Set ollama_url in the extension's settings (e.g. http://192.168.1.42:11434). Requires restart of the extension.
list_running shows a model after you stopped using it — Ollama keeps models hot in VRAM for a configurable TTL (default 5 minutes). The expires_at timestamp tells you when it'll unload. This is Ollama's behavior, not the extension's.
Single ~400-line Node.js script, zero npm dependencies. Rebuild the .mcpb:
cd bundle-source
zip -j ../Ollama.mcpb manifest.json package.json server.js README.md LICENSE icon.png glama.jsonMIT. See LICENSE.
claude-terminal-mcp — shell, filesystem, and background jobs.
claude-rocm-mcp — AMD GPU monitoring; pairs well for checking whether Ollama's loaded model is saturating VRAM.
claude-sessions-mcp — tmux session management for long-running jobs.
claude-linux-mcp — X11 desktop control.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LukeLamb/claude-ollama-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
