MCP协议与Ollama集成：构建本地AI模型工具调用工作流

1. 项目概述：当MCP遇见Ollama，一个全新的AI工作流诞生了

如果你和我一样，每天都在和各类AI模型打交道，从ChatGPT到Claude，再到本地部署的Llama、Qwen，那你一定体会过那种“信息孤岛”的烦恼。每个模型都有自己的API、自己的对话历史、自己的知识边界。想用Llama 3分析一份代码，用Qwen来润色一段文字，再用GPT-4o来做个总结，你需要在不同的网页、客户端或者命令行窗口之间来回切换，复制粘贴到手软。这不仅仅是效率问题，更打断了深度思考的连续性。

最近，一个名为模型上下文协议的概念开始在开发者圈子里流行起来。简单来说，它试图为AI模型定义一个标准化的“沟通语言”，让不同的模型和应用能够像拼乐高一样无缝协作。而jonigl/mcp-client-for-ollama这个项目，正是这个宏大愿景下一个非常具体、非常实用的“连接器”。它的核心使命，是让你本地的Ollama服务，能够接入到支持MCP协议的客户端中，比如Cursor、Windsurf这类新一代的AI原生IDE。

想象一下这个场景：你在Cursor里写代码，想查询某个数据库的Schema，或者想执行一个Shell命令来测试你的脚本。传统上，你需要切出IDE，手动操作。但现在，通过MCP和这个客户端，你可以直接在Cursor的聊天框里对Ollama说：“帮我列出当前目录下所有修改过的文件”，Ollama就能通过MCP客户端调用系统工具，执行git status，并把结果返回给你。这不再是简单的文本对话，而是赋予了AI模型“动手操作”的能力。这个项目，就是打通Ollama与外部世界“任督二脉”的关键桥梁。

2. 核心架构与工作原理深度拆解

要理解mcp-client-for-ollama的价值，我们必须先搞懂MCP和Ollama各自扮演的角色，以及这个客户端是如何将它们粘合在一起的。

2.1 MCP：AI的“标准外设接口”

你可以把MCP想象成电脑的USB接口。在USB标准出现之前，打印机、键盘、鼠标各有各的接口，混乱不堪。MCP要做的事情类似，它为AI模型定义了一套标准的协议，用于声明“我能做什么”（提供哪些工具）以及“我怎么做”（调用这些工具的规范）。

一个MCP服务器本质上是一个工具提供者。它向MCP客户端宣告：“嗨，我这里有这些工具可用：read_file可以读文件，execute_command可以运行命令，search_web可以联网搜索……”每个工具都有明确的输入参数和输出格式。MCP客户端（如Cursor）则像一个总控台，它连接多个MCP服务器，收集所有可用的工具。当用户向AI模型提出请求时，客户端会判断是否需要调用工具，并从工具库中选择合适的那个，按照协议规范进行调用，最后将工具执行的结果返回给AI模型，由模型整合后回复给用户。

2.2 Ollama：本地的模型“发动机”

Ollama则是另一个层面的英雄。它让在个人电脑上运行和操作各种开源大模型变得极其简单。一条ollama run llama3命令就能让Llama 3在本地跑起来。Ollama提供了完善的API，包括聊天补全、模型列表、拉取删除等。但它本身是一个纯粹的“文本推理引擎”，它擅长理解和生成文本，却不具备直接操作文件系统、执行命令或查询网络的能力。它的世界，局限在接收到提示词和返回生成文本之间。

2.3mcp-client-for-ollama：精密的协议转换器

至此，角色清晰了：MCP服务器提供“手和脚”（工具），Ollama提供“大脑”（模型推理），但它们之间没有直接对话的渠道。mcp-client-for-ollama项目，就是一个MCP客户端，但它是一个特殊的客户端——它将自己“伪装”成一个MCP服务器，对接真正的MCP服务器，同时又将Ollama作为其背后的推理模型。

它的工作流是一个精巧的双向循环：

1. 初始化与工具发现：客户端启动，读取配置，连接到用户指定的一个或多个MCP服务器（例如一个提供文件操作工具的服务器，一个提供网络搜索的服务器）。它从这些服务器获取所有可用工具的清单。
2. 会话与意图识别：当用户通过某个前端（比如配置了该客户端的聊天界面）发起对话时，客户端会将用户消息、历史对话以及当前可用的工具列表，组合成一个结构化的提示词，发送给Ollama API。
3. 模型决策与工具调用：Ollama模型分析提示词，判断是否需要调用工具来完成用户请求。如果需要，它会以特定的格式（通常是JSON）在回复中指明要调用哪个工具，以及传入什么参数。
4. 协议执行与结果返回：客户端解析Ollama的回复，提取出工具调用指令。然后，它按照MCP协议的标准，向对应的MCP服务器发起真正的工具调用请求。
5. 结果整合与最终回复：MCP服务器执行工具（如读取了某个文件内容），将结果返回给客户端。客户端再将这个工具执行结果作为新的上下文，连同最初的用户问题，再次发送给Ollama，让模型生成包含工具执行信息的最终回答，呈现给用户。

关键理解：这个项目不是“让Ollama支持MCP”，而是“构建一个使用Ollama作为大脑的MCP客户端”。Ollama本身对MCP一无所知，是这个客户端在中间承担了所有协议翻译、决策路由和结果整合的复杂工作。

3. 从零开始：环境部署与配置实战

理解了原理，我们动手把它跑起来。整个过程可以分为准备地基、构建客户端、配置连接三大步。

3.1 基础环境准备

首先，确保你的系统已经安装了以下两个核心依赖：

1. Ollama：这是项目的基石。访问Ollama官网，根据你的操作系统下载并安装。安装后，在终端运行ollama --version确认安装成功。然后，至少拉取一个模型，例如ollama pull llama3.2:1b（这是一个较小的版本，便于快速测试）。

2. Node.js 环境：该项目通常使用JavaScript/TypeScript编写，需要Node.js运行时。建议安装LTS版本（如v18.x或v20.x）。安装后，通过node --version和npm --version检查。

3.2 客户端获取与初始化

项目代码托管在GitHub，我们通过Git来获取。

# 克隆项目仓库到本地 git clone https://github.com/jonigl/mcp-client-for-ollama.git cd mcp-client-for-ollama # 安装项目依赖 npm install

如果项目提供了package.json，npm install会安装所有必要的依赖包，比如用于HTTP请求的axios、用于解析命令行的commander、用于处理MCP协议通信的@modelcontextprotocol/sdk等。

3.3 核心配置详解

配置是让整个系统运转起来的关键。你需要告诉客户端三件事：用哪个Ollama模型、连接哪些MCP服务器、以及如何运行。

1. 模型配置：客户端需要知道Ollama服务的地址和模型名称。通常这通过环境变量或配置文件设置。

# 设置环境变量示例 export OLLAMA_BASE_URL=http://localhost:11434 export OLLAMA_MODEL=llama3.2:1b

Ollama默认在本地11434端口提供服务。OLLAMA_MODEL必须是你已经通过ollama pull下载好的模型。

2. MCP服务器配置：这是最具灵活性的一部分。你需要一个或多个MCP服务器来提供工具。以官方示例中的stdio类型服务器为例，假设你有一个用Python写的、提供文件系统工具的MCP服务器filesystem_server.py。 配置通常是一个JSON或YAML文件，例如config.json：

{ "mcpServers": { "filesystem": { "command": "python3", "args": ["/path/to/your/filesystem_server.py"], "env": {} }, "calculator": { "command": "node", "args": ["/path/to/calculator/server.js"] } } }

这里定义了两个MCP服务器：filesystem和calculator。command和args指定了如何启动这个服务器进程。客户端会启动这些子进程，并通过标准输入输出与它们进行MCP协议通信。

3. 客户端启动配置：查看项目根目录的package.json，找到启动脚本。通常是：

"scripts": { "start": "node dist/index.js --config ./config.json" }

这意味着编译或运行入口文件时，需要指定配置文件路径。如果项目是TypeScript，可能需要先构建：npm run build，生成dist目录后再运行。

3.4 首次运行与验证

完成配置后，尝试启动客户端：

npm start # 或直接运行 node index.js --config ./config.json

如果一切正常，你应该在日志中看到类似信息：

INFO: Connected to Ollama at http://localhost:11434 INFO: Loaded model: llama3.2:1b INFO: Starting MCP server 'filesystem'... INFO: MCP server 'filesystem' started successfully. INFO: Available tools: read_file, write_file, list_directory INFO: MCP client is ready.

这表示客户端已成功连接Ollama，并启动了filesystemMCP服务器，获取到了read_file等工具。

实操心得：配置的优先级：很多MCP客户端支持多种配置方式，如环境变量、配置文件、命令行参数。通常优先级是：命令行参数 > 环境变量 > 配置文件 > 默认值。遇到问题时，先确认最终生效的配置是什么，避免几处配置相互覆盖导致混乱。

4. 核心功能实现与工具调用全流程剖析

客户端运行起来只是第一步，更重要的是理解它如何处理一个完整的用户请求。我们以一个具体场景：“请告诉我当前项目根目录下README.md文件的第一行内容”为例，拆解全流程。

4.1 工具列表的动态加载与注入

启动时，客户端会并发启动所有配置的MCP服务器。对于每个服务器，客户端会发送一个initialize请求，服务器回应initialized后，客户端会发送tools/list请求。服务器返回其提供的所有工具描述。例如，filesystem服务器可能返回：

{ "tools": [ { "name": "read_file", "description": "Reads the contents of a file at the given path.", "inputSchema": { "type": "object", "properties": { "path": {"type": "string", "description": "The filesystem path to read."} }, "required": ["path"] } } ] }

客户端会将这些工具描述缓存起来，并在后续构造给Ollama的提示词时，将这些工具作为“可用的函数”列表提供给模型。

4.2 提示词工程的奥秘：让模型学会“思考”工具

这是整个流程中最精妙的一环。客户端不能简单地把用户问题扔给Ollama，它必须“教”模型如何使用这些工具。这通过精心设计的系统提示词实现。一个典型的提示词结构如下：

你是一个AI助手，可以调用工具来帮助用户。你可以使用的工具有： 1. 工具名：read_file 描述：读取指定路径文件的内容。 参数：{"path": "字符串，文件路径"} 2. 工具名：execute_command 描述：在Shell中执行一条命令。 参数：{"command": "字符串，要执行的命令"} 当前对话历史： {history} 用户问题：{user_query} 请根据用户问题决定是否需要调用工具。如果需要，请严格按照以下JSON格式回复，且只回复这个JSON对象： { "thought": "你的思考过程，分析为什么需要调用工具以及调用哪个工具", "tool": "工具名称", "args": { /* 工具所需的参数对象 */ } } 如果不需要调用工具，请直接给出你的回答。

这个提示词做了几件关键事：

1. 明确角色和能力：告诉模型它被赋予了调用工具的能力。
2. 清晰列举工具：以结构化方式描述每个工具的用途和输入格式。
3. 强制输出格式：要求模型在需要调用工具时，必须输出一个包含thought、tool、args的特定JSON对象。这种“强制结构化输出”是让普通聊天模型完成工具调用的关键技巧。
4. 提供思考链：要求输出thought字段，这不仅是给用户看的，也促使模型进行更理性的推理，提高了工具选择的准确性。

4.3 模型推理与结构化输出解析

客户端将上述构造好的提示词通过Ollama API发送。对于我们的例子，一个训练良好的模型（如Llama 3）可能会返回：

{ "thought": "用户想查看README.md文件的第一行。我需要读取这个文件的内容。有一个叫read_file的工具可以做到这一点。我需要知道文件的完整路径。假设当前项目根目录就是工作目录，路径可能是'./README.md'。", "tool": "read_file", "args": { "path": "./README.md" } }

客户端收到响应后，会首先尝试将其解析为JSON。如果解析成功且包含tool字段，则进入工具调用流程；否则，认为这是模型的直接回复，直接返回给用户。

4.4 MCP协议下的工具调用与结果处理

解析出tool和args后，客户端会查找缓存的工具列表，确认read_file工具来自哪个MCP服务器（这里是filesystem）。然后，它按照MCP协议的tools/call请求格式，向对应的服务器发送请求：

{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "read_file", "arguments": { "path": "./README.md" } } }

filesystem服务器执行读取操作，并返回结果：

{ "jsonrpc": "2.0", "id": 1, "result": { "content": [ { "type": "text", "text": "# MCP Client for Ollama\nThis is a client that enables Ollama models to use MCP tools." } ] } }

客户端收到结果后，不能直接把这个JSON给用户。它需要进行第二轮调用。它将工具执行的结果（即文件内容）作为新的上下文，连同最初的用户问题和对话历史，再次发送给Ollama模型，提示词可能是：

（之前的工具定义和对话历史...） 用户问题：请告诉我当前项目根目录下README.md文件的第一行内容。 你决定调用工具read_file，参数为{"path": "./README.md"}。 工具调用结果： # MCP Client for Ollama This is a client that enables Ollama models to use MCP tools. 请根据工具调用结果，回答用户的问题。

这次，模型会生成最终的回答：“README.md文件的第一行内容是# MCP Client for Ollama。”

4.5 完整流程的代码级抽象

我们可以将上述流程抽象为一个简化的循环状态机：

1. 状态：等待用户输入-> 接收user_query。
2. 状态：构造提示并调用模型-> 组合历史、工具列表、用户查询，调用Ollama API。
3. 状态：解析模型响应-> 尝试解析JSON。若为工具调用，进入状态4；若为直接回复，进入状态6。
4. 状态：执行MCP工具调用-> 向对应MCP服务器发送tools/call请求。
5. 状态：整合结果并再次调用模型-> 将工具结果作为新上下文，回到状态2（但这次提示词强调根据结果回答）。
6. 状态：返回最终结果-> 将模型的直接回复或基于工具结果的回复返回给前端用户。

注意事项：工具调用的递归与终止：理论上，模型在一次回复中可能请求调用多个工具，或者在第一轮工具调用后，基于结果又决定调用另一个工具。一个健壮的客户端需要能处理这种多步推理。同时，必须设置超时和最大调用深度限制，防止模型陷入无限循环的工具调用请求中。

5. 高级配置与性能调优指南

当基本功能跑通后，为了获得更好、更稳定的体验，我们需要深入配置细节和性能优化。

5.1 多模型与多服务器策略

模型轮询与回退：在生产环境中，不要依赖单一模型。可以在配置中定义一个模型列表。

{ "ollama": { "baseUrl": "http://localhost:11434", "models": ["llama3.1:8b", "qwen2.5:7b", "gemma2:9b"], "strategy": "fallback" // 或 "round-robin" } }

• fallback策略：优先使用第一个模型，如果请求失败或超时，自动尝试下一个。
• round-robin策略：轮流使用列表中的模型，平衡负载。 这提高了服务的可用性，也能根据任务类型选择不同特长的模型（如代码任务用CodeLlama，通用任务用Llama）。

MCP服务器的组合与隔离：你可以配置功能各异的MCP服务器。

• 系统操作类：filesystem（文件）、shell（命令）。
• 信息获取类：duckduckgo-search（搜索）、sqlite（数据库）。
• 专业工具类：github（Git操作）、figma（设计稿）。 关键在于，要根据安全策略进行隔离。例如，将高风险的shell服务器部署在沙箱环境或严格限制其命令白名单，而只读的filesystem服务器则可以放宽一些。

5.2 提示词模板的定制化

默认的系统提示词可能不适用于所有模型或任务。项目应允许用户自定义提示词模板。你可以在配置文件中指定一个提示词模板文件的路径。

{ "promptTemplate": { "system": "./templates/system_prompt.txt", "user": "./templates/user_prompt.mustache" } }

在system_prompt.txt中，你可以用{{tools}}这样的占位符，客户端在运行时会将格式化的工具列表注入进去。针对代码模型，你可以强化其输出JSON的指令；针对推理模型，你可以鼓励它进行更详细的思考链。

5.3 性能优化关键参数

与Ollama API交互时，以下几个参数对响应速度和效果影响巨大：

1. 超时设置：为Ollama API调用和MCP服务器工具调用分别设置合理的超时。

   timeouts: ollamaCompletion: 120000 # 模型生成超时，单位毫秒，对于长文本生成需调高 mcpCall: 30000 # 工具调用超时

   网络不佳或工具执行慢时，避免无限制等待。

2. 上下文长度与管理：Ollama模型有上下文窗口限制（如4K、8K、128K tokens）。客户端需要智能管理对话历史。

   • 策略：采用“滑动窗口”，只保留最近N轮对话。
   • 压缩：对于较旧的对话，可以尝试用模型进行摘要压缩，再将摘要放入上下文。
   • 配置：在客户端配置中明确上下文窗口大小，并设置历史消息条数上限。

3. 温度与采样参数：通过Ollama API传递这些参数，影响模型输出的确定性和创造性。

   { "model": "llama3.2:1b", "prompt": "...", "options": { "temperature": 0.7, // 较低值（如0.2）使输出更确定，适合工具调用；较高值更有创意。 "top_p": 0.9, "num_predict": 512 // 最大生成token数，防止模型“说个没完” } }

   对于工具调用，建议将temperature设得较低（如0.1-0.3），以提高模型输出结构化JSON的稳定性。

5.4 安全加固实践

将本地模型与系统工具连接，安全是重中之重。

1. 工具权限最小化：为每个MCP服务器配置严格的权限范围。例如，filesystem服务器可以配置一个allowed_paths列表，只允许访问特定目录。
2. 输入验证与净化：在客户端调用MCP工具前，对模型提供的参数进行二次验证。例如，检查path参数是否包含..（上级目录）等路径遍历攻击特征。
3. 用户身份与审计：在多人使用或服务化部署时，引入用户身份标识。记录完整的审计日志：谁、在什么时候、问了什么问题、模型调用了什么工具、参数是什么、结果是什么。这便于事后追溯和问题排查。
4. 网络隔离：如果MCP服务器需要连接外部网络（如搜索），考虑将其部署在独立的网络命名空间或容器中，限制其网络访问范围。

6. 典型问题排查与实战调试技巧

在实际部署和使用中，你肯定会遇到各种问题。下面是一些常见故障场景及其排查思路。

6.1 连接类问题

问题：客户端无法连接Ollama。

• 现象：启动时报错Failed to connect to Ollama或Model not found。
• 排查步骤：
  1. 检查Ollama服务状态：运行ollama serve确保服务在运行。用curl http://localhost:11434/api/tags测试API是否可达。
  2. 检查环境变量：确认OLLAMA_BASE_URL和OLLAMA_MODEL设置正确。模型名必须完全匹配，包括标签（如:1b）。
  3. 检查网络与端口：如果是远程Ollama，确认防火墙放行了11434端口，且URL正确。
  4. 查看Ollama日志：Ollama服务本身的日志可能包含更详细的错误信息。

问题：MCP服务器启动失败。

• 现象：日志显示Failed to start MCP server 'filesystem'。
• 排查步骤：
  1. 检查命令路径：确认配置中command和args的路径是绝对路径，且可执行文件存在并有执行权限。
  2. 检查依赖：许多MCP服务器是脚本（Python/Node.js），确保对应的解释器已安装，且脚本所需的第三方库已安装（如pip install mcp）。
  3. 手动测试服务器：尝试在终端手动运行配置中的命令，看是否能独立启动并输出日志，这能快速定位是命令问题还是客户端调用问题。

6.2 工具调用逻辑问题

问题：模型不调用工具，总是直接回答。

• 现象：对于明显需要工具的问题（如“当前目录有什么文件？”），模型却尝试凭空回答。
• 排查步骤：
  1. 检查提示词：这是最常见的原因。检查系统提示词是否清晰列出了工具，并强制要求了JSON输出格式。提示词可能太弱，没有给模型足够的引导。
  2. 检查工具描述：工具的描述（description）是否清晰易懂？模型是根据描述来判断工具用途的。将描述写得更加具体、场景化。
  3. 调整模型参数：尝试降低temperature值，增加top_p，使模型输出更可控、更遵循指令。
  4. 更换模型：不同模型遵循指令和输出结构化内容的能力差异很大。Llama 3、Qwen 2.5、Command R+ 在这方面的表现通常较好。较小的模型（如1B、3B参数）可能能力不足。

问题：模型调用了错误的工具，或参数格式错误。

• 现象：模型输出了JSON，但tool字段不对，或args里的参数名与工具定义不匹配。
• 排查步骤：
  1. 强化工具描述：在工具描述中明确输入参数的名称和类型。例如：“参数path(字符串类型)：要读取的文件绝对路径。”
  2. 提供少量示例：在系统提示词中，加入1-2个工具调用的示例（Few-shot Learning），能极大提高模型输出的准确性。
  3. 输出格式约束：在提示词中反复强调JSON的键名必须精确匹配，如"tool"和"args"，一个字母都不能错。

6.3 性能与稳定性问题

问题：响应速度非常慢。

• 现象：一次简单的问答需要十几秒甚至更久。
• 排查步骤：
  1. 分层计时：在客户端代码中添加详细的性能日志，记录：构造提示词耗时、Ollama API调用耗时、MCP工具调用耗时、结果整合耗时。找到瓶颈所在。
  2. Ollama瓶颈：如果Ollama调用慢，检查本地CPU/GPU负载。尝试使用量化版本更小的模型（如llama3.2:1bvsllama3.2:3b）。确保Ollama使用了GPU加速（如果可用）。
  3. MCP服务器瓶颈：如果某个工具调用慢（如网络搜索），考虑为该工具调用设置独立的超时，并实现异步调用，避免阻塞主线程。
  4. 上下文过长：检查发送给Ollama的提示词是否包含过长的、未压缩的对话历史。启用历史管理策略。

问题：客户端运行一段时间后崩溃或内存泄漏。

• 现象：进程占用内存持续增长，最终崩溃。
• 排查步骤：
  1. 检查MCP服务器：有些MCP服务器可能存在内存泄漏。尝试逐个禁用服务器，观察内存增长情况。
  2. 检查客户端资源管理：确保正确关闭不再使用的MCP服务器子进程。每次会话结束后，是否清理了相关的资源？
  3. 监控日志：查看崩溃前的错误日志或堆栈跟踪，这是最直接的线索。

6.4 调试技巧与日志分析

高效的调试离不开清晰的日志。建议为客户端配置结构化、分等级的日志（如使用winston或pino库）。

1. 启用DEBUG级别日志：在开发或排查问题时，将日志级别设为DEBUG，这会打印出收发的原始MCP协议消息、构造的提示词、模型原始响应等。

   // 示例配置 const logger = createLogger({ level: process.env.LOG_LEVEL || 'info', // 通过环境变量控制 });

2. 关键日志点：

   • 收到用户请求时：记录请求ID和问题摘要。
   • 发送给Ollama的提示词：完整记录，这是诊断模型行为的关键。
   • 收到Ollama响应时：记录是直接回复还是工具调用JSON。
   • 调用MCP工具前后：记录工具名、参数和返回结果（注意可能包含敏感信息，生产环境需脱敏）。
   • 发生错误时：记录完整的错误对象和上下文。

3. 使用交互式测试：可以编写一个简单的测试脚本，模拟用户输入，并打印出每个中间步骤的结果，这比在完整流程中调试更高效。

7. 生态整合与进阶应用场景

当你的mcp-client-for-ollama稳定运行后，就可以思考如何将它融入更广阔的生态，解锁更多强大的应用场景。

7.1 与主流AI IDE集成：Cursor & Windsurf

这是该项目最直接的应用场景。以Cursor为例，它内置了MCP客户端支持。你不需要修改Cursor本身，而是通过配置Cursor来连接你运行的mcp-client-for-ollama服务。

1. 将客户端包装为服务器：你需要让mcp-client-for-ollama以一个标准MCP服务器的形式对外提供服务（例如通过SSE或WebSocket）。这可能需要修改项目代码，添加一个服务器层。
2. 配置Cursor：在Cursor的设置（如cursor.json）中，添加MCP服务器配置，指向你客户端暴露的端点。
3. 效果：配置成功后，在Cursor的聊天界面中，你的本地Ollama模型将能够使用配置好的文件操作、Git命令等工具，实现真正的“对话即操作”。

7.2 构建自动化智能体工作流

单一的问答式工具调用已经很强大了，但我们可以更进一步，构建多步骤的自动化工作流。

场景：自动代码审查与修复

1. 用户提出需求：“检查src/utils.js文件中的安全漏洞。”
2. 客户端驱动模型，模型可能规划一系列动作： a. 调用read_file工具读取该文件。 b. 基于代码内容，调用execute_command运行一个静态分析工具（如npm audit或自定义脚本）。 c. 读取分析报告。 d. 如果发现漏洞，调用write_file工具尝试生成修复建议或直接修补代码。
3. 客户端协调所有这些工具调用，并将最终结果“已发现X个漏洞，并已在第Y行应用了修复建议”返回给用户。

这需要模型具备一定的规划能力，而客户端需要支持模型进行连续、多轮的工具调用。

7.3 开发自定义MCP服务器扩展能力

社区提供的通用MCP服务器可能无法满足你的特定需求。这时，开发自定义MCP服务器就成为必然。

一个简单的“天气查询”MCP服务器示例（Node.js）：

// weather-server.js import { Server } from '@modelcontextprotocol/sdk/server/index.js'; import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'; const server = new Server( { name: 'weather', version: '1.0.0' }, { capabilities: { tools: {} } } ); // 声明工具 server.setRequestHandler('tools/list', async () => { return { tools: [ { name: 'get_weather', description: 'Get current weather for a city.', inputSchema: { type: 'object', properties: { city: { type: 'string', description: 'City name' } }, required: ['city'] } } ] }; }); // 处理工具调用 server.setRequestHandler('tools/call', async (request) => { if (request.params.name === 'get_weather') { const city = request.params.arguments?.city; // 这里模拟调用真实天气API const mockWeather = `The weather in ${city} is sunny, 22°C.`; return { content: [{ type: 'text', text: mockWeather }] }; } throw new Error('Tool not found'); }); const transport = new StdioServerTransport(); await server.connect(transport); console.error('Weather MCP server running on stdio...');

编写完成后，在客户端的配置文件中添加这个新服务器，你的Ollama模型就立刻拥有了查询天气的能力。你可以用同样的方式，将内部API、数据库、监控系统等任何资源封装成MCP工具。

7.4 面向生产环境的服务化部署

对于团队共享或持续服务，你需要考虑更稳健的部署方式。

1. 容器化：将mcp-client-for-ollama及其依赖的MCP服务器一起打包成Docker镜像。这保证了环境一致性，简化了部署。

   FROM node:18-slim WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY dist/ ./dist/ COPY config.production.json ./config.json COPY mcp-servers/ ./mcp-servers/ CMD ["node", "dist/index.js"]

2. 进程管理：使用pm2或systemd来管理客户端进程，实现自动重启、日志轮转和资源监控。

3. API网关与认证：如果你希望以Web API的形式提供服务，可以在客户端外层包装一个简单的HTTP服务器（如Express.js），并添加API密钥认证，以便其他应用安全地调用。

4. 可观测性：集成监控工具（如Prometheus），暴露指标（请求数、延迟、错误率、工具调用分布），并设置告警。

这个项目就像一个乐高底座，Ollama模型是上面的大脑，MCP服务器是各种功能积木，而你的业务场景和创意，则是搭建出的无限可能。从提升个人效率的智能终端，到驱动团队协作的自动化中枢，它的边界由你来定义。