让 Claude Desktop 可以查询和管理本地 Ollama 服务器。无需打开终端，即可列出已安装的模型、检查模型详情、针对任何本地模型运行一次性 generate/chat 补全，或从注册表中拉取/删除模型。
典型用途：将 Claude 的回答与本地模型针对同一提示词的回答进行比较、针对量化模型运行低成本的批量补全，或检查您导入到 Ollama 中的自定义训练检查点模型。
正在运行的 Ollama 服务器（ollama serve 或 Ollama 应用程序）。
默认端点为 http://localhost:11434。如果您在不同的主机或端口上运行 Ollama，请通过 Claude Desktop 扩展设置中的 ollama_url 用户配置进行覆盖。
无 npm 依赖——纯 Node 通过 HTTP API 实现。
Related MCP server: Ollama MCP Server
从 Releases 页面下载最新的 Ollama.mcpb。
在 Claude Desktop 中：设置 → 扩展 → 扩展开发者 → 安装扩展 → 选择 .mcpb 文件。
(可选) 在扩展设置中，如果您在非默认主机/端口上运行 Ollama，请设置 Ollama server URL。如果使用 http://localhost:11434，请留空。
工具 | 注解 | 用途 |
| 只读 | 健康检查 + 服务器版本 |
| 只读 | 本地模型（包含大小、摘要、系列、参数量、量化信息） |
| 只读 | 当前加载在显存 (VRAM) 中的模型 |
| 只读 | 模型详情：模型文件、参数、模板、能力 |
| 开放世界 | 一次性文本补全（非流式） |
| 开放世界 | 带有消息历史的聊天补全（非流式） |
| 开放世界 | 从注册表下载模型 |
| 破坏性 | 删除本地安装的模型 |
“我安装了哪些本地模型，目前哪个模型加载在显存中？”
“使用
forge:b6c1运行此提示词：''。将输出结果与你自己的回答进行比较。”“向我展示
forge:b7c1的模型文件 (modelfile) —— 我想检查一下温度设置。”“拉取
llama3.1:70b。” (对于大型模型，请耐心等待)“删除
forge:b5c3模型 —— 我不再需要那个检查点了。”
此扩展完全在您的本地机器上运行，仅向您的 Ollama 服务器（默认 http://localhost:11434）发送 HTTP 请求。除非您明确配置 ollama_url 指向远程 Ollama 实例，否则没有任何数据会离开您的机器；如果配置了远程实例，提示词和响应将会传输到该服务器。
Claude 可见的信息包括：
您传递给 generate 和 chat 的所有提示词和聊天消息（这些消息会发送到 Ollama 服务器，服务器可能会根据其配置记录这些信息）。
Ollama 返回的补全全文。
每个已安装模型的元数据（名称、摘要、大小、量化、模型文件内容）。
当前加载在显存中的模型及其大小占用。
如果您安装的模型包含专有的微调数据或带有敏感元数据的模型文件，请注意，当您调用 show_model 或 list_models 时，Claude 将会看到这些信息。
delete_model 是破坏性的，且无法通过此扩展撤销——如果误删，必须从注册表重新拉取（或从源二进制文件重新导入）。
“无法连接到 http://localhost:11434 上的 Ollama — 服务器是否在运行？” — 请使用 ollama serve 启动 Ollama 或运行 Ollama 应用程序。使用 curl http://localhost:11434/ 进行验证（应返回 "Ollama is running"）。
pull_model 长时间挂起 — Ollama 的 stream: false 拉取 API 会阻塞直到完整下载完成，对于多 GB 的模型，这可能需要几分钟。如果您正在拉取大型模型，请改在终端中运行 ollama pull <name> —— 您可以在那里看到流式进度，后续的 MCP 调用将发现模型已安装。
自定义/远程 Ollama 端点 — 在扩展设置中设置 ollama_url（例如 http://192.168.1.42:11434）。需要重启扩展。
list_running 在您停止使用后仍显示模型 — Ollama 会将模型保持在显存中，直到达到可配置的 TTL（默认 5 分钟）。expires_at 时间戳会告诉您它何时卸载。这是 Ollama 的行为，而非扩展的行为。
单个约 400 行的 Node.js 脚本，零 npm 依赖。重新构建 .mcpb：
cd bundle-source
zip -j ../Ollama.mcpb manifest.json package.json server.js README.md LICENSE icon.png glama.jsonMIT。请参阅 LICENSE。
claude-terminal-mcp — shell、文件系统和后台作业。
claude-rocm-mcp — AMD GPU 监控；非常适合检查 Ollama 加载的模型是否占满了显存。
claude-sessions-mcp — 用于长时间运行作业的 tmux 会话管理。
claude-linux-mcp — 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.
