通过 MCP 将 Ollama 连接到数据库和 API：2026 年本地智能体配置指南

快速事实

• 协议： JSON-RPC 2.0 通过 stdio（本地子进程）或 HTTP/SSE（远程）传输。本地智能体几乎只用 stdio。
• 维护方： Anthropic（开源规范）；参考服务器维护在 GitHub 的 modelcontextprotocol/servers，外加快速发展的第三方生态。
• 2026 年的本地客户端： Goose（Block）、Cline（VS Code 扩展）、Continue.dev（VS Code/JetBrains）、LM Studio（桌面应用），以及多个 CLI 工具。
• 兼容的 Ollama 模型： 任何具备原生 tool call 训练的模型。2026 年 5 月：Gemma 4 27B、GLM-5.1 32B、Qwen3 32B、Qwen3-Coder 30B、Llama 3.3 70B。
• 默认 transport： 本地进程用 stdio；只有需要跨机器或跨智能体共享服务器时才用 HTTP/SSE。
• 配置集中在一个文件： ~/.config/goose/config.yaml（Goose）、~/.continue/config.json 的 MCP 块（Continue.dev）、或 Cline 设置 UI 中的 mcpServers。形式相同：服务器名、command、args、env vars。
• 无需 Claude Desktop。 协议早于 Claude Desktop 的独占叙事；所有参考服务器均为 MIT/Apache 许可，可在任何符合规范的客户端下运行。

MCP 实际为本地模型解锁的能力

• **「找出此仓库中所有 TODO，按文件分组，并将 Markdown 摘要写入 notes/todos.md。」** —— filesystem 服务器读取，模型分组，同一服务器写入。端到端一次往返。
• 「列出本季度营收 Top 10 客户并绘制图表。」 —— postgres 服务器执行 SQL（只读角色），模型汇总，并通过 filesystem 写出 CSV 供你的图表工具使用。
• 「打开 Hacker News 首页，找出 AI 相关的前三篇文章，总结后追加到我的阅读清单。」 —— puppeteer 服务器驱动无头浏览器，模型抽取并总结，filesystem 追加。
• **「向我的 fork 提交标题为 chore: bump deps 的草稿 PR，并在描述中链接失败的 CI run。」** —— github 服务器创建 PR、获取 run、在描述中写入链接。
• **「查看 events.db 最新 100 行，告诉我哪些 user ID 是新错误尖峰的来源。」** —— sqlite 服务器查询；模型推理；你在聊天面板看到答案。
• 以上每一项都是「一句话到操作」的工作流，过去要么需要带托管工具的云端模型，要么需要手写脚本。MCP 是让你能跨客户端复用同一服务器、跨服务器复用同一模型的那一层。

四个最常用 MCP 服务器对比

组件如何协作

• Ollama 作为后台服务运行在 127.0.0.1:11434，通过 OpenAI 兼容 API 提供模型。它不知道 MCP 是什么——只是回应 chat completion，并在模型请求时输出 tool call。
• MCP 客户端（Goose、Cline、Continue.dev、LM Studio）是桥梁。它与 Ollama 沟通模型部分，与 MCP 服务器沟通工具部分。模型发出 tool call 时，客户端将其路由到正确的服务器，获取结果，然后把结果送回对话。
• MCP 服务器 是相互独立的子进程，每种能力一个。它们通过 stdio 说 JSON-RPC 2.0。每个服务器声明一组 Tools、Resources 和 Prompts；客户端将其合并为对模型呈现的工具表面。
• stdio transport 让一切保持本地。 服务器由客户端启动，通过 stdin/stdout 通信，并在客户端退出时退出。除非服务器自身打开网络连接（浏览器服务器会，filesystem 与数据库服务器不会），否则不走网络。
• 模型看到的是扁平工具列表。 在模型视角中没有服务器——只有 filesystem.read_file、sqlite.query、puppeteer.navigate 这样的工具名。客户端处理路由。

配置：15 分钟搭建 Ollama + Goose

• Step 1 —— 安装 Ollama。 从 ollama.com/download 下载（macOS/Windows/Linux）。用 curl http://127.0.0.1:11434/api/tags 确认服务运行。
• Step 2 —— 拉取支持 tool calling 的模型。 在 Gemma 4 27B (gemma4:27b)、GLM-5.1 32B (glm5:32b)、Qwen3 32B (qwen3:32b) 或 Llama 3.3 70B (llama3.3:70b) 中选一个。16 GB 统一内存或 12 GB VRAM 在 Q4_K_M 下从容运行 27B–32B。
• Step 3 —— 安装 Goose。 pipx install goose-ai（macOS、Linux），或从 Goose Releases 页下载安装程序。CLI 安装为 goose。
• Step 4 —— 将 Ollama 配置为 provider。 运行 goose configure，选择 ollama 作为 provider，将模型设为已拉取的那个，host 设为 http://127.0.0.1:11434。Goose 会写入 ~/.config/goose/config.yaml。
• Step 5 —— 加入 filesystem MCP 服务器。 编辑 ~/.config/goose/config.yaml 加入 mcpServers 块（配置示例见下）。重启 goose session 并请求列出测试目录的文件。第一轮即可确认服务器接入。
• Step 6 —— 用真实任务验证。 试运行 goose session，请求「列出 notes/ 中每个 Markdown 文件的标题与字数，并将结果写入 notes/index.md」。如果智能体读、汇总、回写都成功，整个循环可工作。

# 1. Pull a tool-calling model
ollama pull gemma4:27b

# 2. Install Goose
pipx install goose-ai

# 3. Configure Ollama as the provider
goose configure
# Provider: ollama
# Model:    gemma4:27b
# Host:     http://127.0.0.1:11434

# 4. Start a session — Goose reads ~/.config/goose/config.yaml
goose session

Filesystem 服务器：在沙箱目录中读写

• 安装： 参考服务器为 @modelcontextprotocol/server-filesystem，通过 npx -y 运行（无需全局安装）。Goose、Cline、Continue.dev 都从配置块自动启动。
• Allow-list 路径： 服务器接受一个或多个目录参数，并拒绝在其外的操作。务必传入显式的、范围窄的路径——绝不要 ~ 或 /。
• 暴露的工具： read_file、read_multiple_files、write_file、edit_file（按行替换）、list_directory、search_files、move_file、create_directory、directory_tree。模型看到的形式是 filesystem.read_file 等。
• 易用性： directory_tree 返回 JSON 树状结构，便于模型在读取具体文件之前先了解结构。search_files 提供类似 grep 的递归搜索。
• 风险面： 服务器尊重 allow-list，但在该列表内拥有完整读写权限。把 allow-list 视作唯一屏障，并选择专用 workspace 目录而非 home 文件夹。

# ~/.config/goose/config.yaml
mcpServers:
  filesystem:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-filesystem"
      - "/Users/you/agent-workspace"
    env: {}

SQLite 与 Postgres 服务器：查询真实数据

• **SQLite 服务器（@modelcontextprotocol/server-sqlite）** 接受一个 .db 文件路径。适用于日志分析、schema 原型、不开数据库即可探索导出数据。
• **Postgres 服务器（@modelcontextprotocol/server-postgres）** 接受 connection string。推荐做法是为智能体创建专用的只读角色，并使用该角色的 connection string。
• 暴露的工具： query（配置为只读时仅 SELECT）、list_tables、describe_table。Postgres 服务器另加 list_schemas。部分 fork 加入 write_query——除非你信任模型在该数据库上的行为，否则保持禁用。
• Schema 感知： 在提分析问题前请智能体「列出表并 describe 最常用的五个」——模型在调用过 describe_table 之后比凭空猜列名要准确得多。
• 成本： 查询直接落在数据库上。在一亿行的表上格式不当的 SELECT * 与人手所造成的事故同等严重——把该角色放在独立连接池并设置 statement timeout。

# ~/.config/goose/config.yaml
mcpServers:
  sqlite:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-sqlite"
      - "--db-path"
      - "/Users/you/data/events.db"
    env: {}

  postgres:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-postgres"
      - "postgresql://agent_ro@127.0.0.1:5432/analytics"
    env:
      PGPASSWORD: "${PG_AGENT_PASSWORD}"

浏览器服务器：用 Puppeteer 或 Playwright 驱动 Chromium

• 参考服务器： @modelcontextprotocol/server-puppeteer（轻量，默认 headless）与 @modelcontextprotocol/server-playwright（较重，支持多浏览器）。本地智能体使用 Puppeteer 即可。
• 暴露的工具： navigate、screenshot、click、fill、select、evaluate（运行 JavaScript）、get_page_content。模型用 get_page_content 读取结构化文本，用 screenshot 进行视觉确认。
• 延迟： 真实浏览器会话每个动作 1–5 秒。多步浏览很容易消耗 30–60 秒以及数万 token，因为页面内容较大。请使用 32K+ 上下文窗口。
• 选择器： 模型必须挑选 CSS 选择器。小模型常出错；27B+ 的 tool calling 模型对常见模式较为可靠。把任务范围收紧——「抽取此 URL 的标题与首段」远比「在站内浏览并找到联系页」可靠。
• 适合场景： 调研（打开页面、汇总、追加到笔记）、回归测试（导航、点击、截图）、在你掌控的页面上的表单填写。不适合场景：任何在真实 Web 上误点会带来后果的工作。

# ~/.config/goose/config.yaml
mcpServers:
  puppeteer:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-puppeteer"
    env:
      PUPPETEER_HEADLESS: "true"
      # Block obviously dangerous endpoints at the OS firewall level
      # rather than relying on the agent to refuse them.

GitHub 服务器：从本地模型操作仓库、issue 与 PR

• 安装： @modelcontextprotocol/server-github，将 PAT 放入 GITHUB_PERSONAL_ACCESS_TOKEN 环境变量后运行。token 是唯一鉴权——服务器本身没有额外配置。
• 暴露的工具： search_repositories、get_file_contents、create_or_update_file、create_pull_request、list_issues、create_issue、add_issue_comment、merge_pull_request，以及数十个其他工具。完整工具表面较大，多数任务用 5–10 个工具即可。
• 收紧 PAT。 使用限定到具体仓库的 fine-grained PAT，权限仅到必要最小（浏览给 Read，PR/issue 创建给 Write）。不要在实验性智能体上使用带 repo 权限的经典 PAT。
• 真实工作流： triage（「读取最近 20 个 open issue，分组并起草标签」）、起草（「读 README 并提交一个修复 typo 的 PR」）、报表（「本周哪些 PR 长时间停滞」）。
• 风险面： 智能体可以创建 issue 和 PR、发表评论，并在拥有写权限时推送 commit。除非同时信任模型与流程，否则禁用 merge 类工具——fine-grained PAT 仓库中的误合并仍可恢复，但要尽快发现。

# ~/.config/goose/config.yaml
mcpServers:
  github:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-github"
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GH_AGENT_PAT}"
      # Fine-grained PAT scoped to one or two test repos,
      # not your personal account-wide classic token.

一个不信任模型的安全模型

• 将 filesystem 服务器限定到一个目录。 永不 ~ 或 /。选定 agent-workspace/ 文件夹，把智能体需要接触的文件副本放进去。即便智能体出错，最坏情况是一个文件夹。
• 数据库服务器默认只读运行。 用仅 SELECT 授权且 statement timeout 为 30 秒的专用 agent_ro 角色，可以整体消除一类事故。
• 所有写入或 shell 工具都置于明确授权之后。 Goose、Cline、Continue.dev 都支持按工具的授权规则。读取工具默认放行；write_file、edit_file、execute_command、create_pull_request 以及任何提交表单的浏览器动作都需要授权。
• 使用审计日志。 每个 MCP 客户端都会记录 tool call 与结果。长会话之后扫一眼日志：你会看到模型尝试一些你未预期的事（有时无害，有时值得收紧权限）。
• 第三方访问的 token 范围要紧。 GitHub PAT 限定到两个测试仓库。Postgres 角色只读。浏览器会话不带凭据。模型迟早会尝试你未预期的事；它能做什么的边界，不能依赖模型的「自觉」。
• 敏感数据工作时让智能体 air-gap。 处理私有数据时关闭主机的网络访问（或使用 network namespace）。本地栈本就不向外发数据，但纵深防御能兜住第三方服务器的失误。
• 像对待依赖一样选 MCP 服务器。 参考服务器维护良好，许多第三方服务器并非如此。在为某个需要凭据的服务器安装前，请先阅读其代码。

本地 MCP vs Claude Desktop：什么变了，什么不变

为本地 MCP 选择支持 tool calling 的模型

• **Gemma 4 27B (gemma4:27b)** —— Google 的 tool call 训练在同尺寸中处于业内最佳。Q4_K_M 下可装入 16 GB 统一内存或 24 GB VRAM。通用推理良好；在链式 tool call 上略偏保守。
• **GLM-5.1 32B (glm5:32b)** —— 智谱的模型 tool call 可靠性极强，开箱 128K 上下文窗口。比 Gemma 4 略重；24 GB GPU 上从容运行。
• **Qwen3 32B (qwen3:32b) —— 综合均衡；dense 32B 干净处理 MCP，在长智能体循环中稳定。Qwen3-Coder 30B (qwen3-coder:30b)** 是代码形态智能体工作的最佳选择。
• **Llama 3.3 70B (llama3.3:70b)** —— 上限最高但最重。Q4_K_M 下需要 48 GB+ 统一内存或 2× 24 GB GPU。仅在硬件允许时使用；通常更小的模型已足够。
• MCP 工作避免： 任何 7B 以下，以及任何没有显式 tool call 训练的通用模型。它们会输出格式错误的 call、循环卡住，而你会怪罪 harness——但 harness 没问题。
• 提升任何模型 tool call 质量的结构化提示工程方法，参见 Chain-of-Thought Prompting。
• 逐项基准对比，参见 2026 年最佳本地 tool calling 模型。

MCP vs 普通 Function Calling：差别在哪

• Function calling 是 LLM 端的能力：模型输出一段描述工具名与参数的结构化 JSON。OpenAI Tools、Anthropic Tools、Ollama 的 tool call API 都是同一思路，只是 wire format 略有差异。
• MCP 在其上：它跨进程标准化工具如何被描述、发现、调用、返回。单凭 function calling 的模型并不知道你的 filesystem；MCP 服务器把 filesystem 操作暴露出来，客户端将其映射到模型的 function calling API，模型于是可以调用。
• 收益是 interop。 filesystem 服务器只写一次；Claude Desktop、Goose、Cline、Continue.dev、LM Studio 都不加修改地复用。模型从 Claude 换成 Gemma 4，服务器不变。
• 用纯 function calling 也能做智能体。 但你会按项目重写 filesystem、数据库、浏览器 handler。有了 MCP，它们是开箱依赖。
• 一次性脚本，纯 function calling 更简单。 但凡你想在项目或模型间复用，几天之后 MCP 就成为更省力的路径。

中国企业的应用方案

• 《数据安全法》(2021)： 数据分级分类与重要数据出境评估是云端 AI 部署的核心障碍。本地 MCP 栈不产生数据出境行为，重要数据始终留在企业内网，对应「分级分类」中较高级别数据可在不触发出境评估的前提下使用 LLM 能力。
• 《个人信息保护法》(PIPL)： PIPL 第 23 条对个人信息委托处理与第三方提供有严格要求；第 38 条对跨境提供个人信息额外要求安全评估或单独同意。本地推理消除了 LLM 层的第三方处理者关系，简化了与 OpenAI、Anthropic、Google 等境外 AI 服务商相关的合规路径。
• 《网络安全法》与等保（MLPS 2.0）： 关键信息基础设施运营者与三级以上系统须满足数据本地化与日志可审计要求。本地 MCP 客户端的审计日志（Goose、Cline、Continue.dev）与等保审计要求天然契合，可作为 tool call 行为的主要证据存档。
• 中国企业实际应用场景： 银行（信贷材料分析）、医院（病历摘要）、律师事务所（合同审阅）、制造业（图纸辅助设计）、政府机关（公文助理）——所有「客户/患者/公民数据不能出企业」的场景都适用。Apple M5 Mac mini 或搭载 RTX 4090 的工作站可运行 27B–32B 模型，覆盖摘要、合规检查、内部数据库代码片段验证等核心需求。
• 头部互联网公司参考： 阿里巴巴、腾讯、华为、字节跳动、百度等对自研模型与外部模型混用早有实践；本地 MCP 协议层为「内部模型 + 内部数据」组合提供了一套与云端方案 wire 兼容的工具栈，便于在内外部环境之间迁移工具实现而不重写。
• 注意事项： 浏览器服务器是合规上最敏感的组件，建议为其单独建立网络隔离环境并禁止访问支付/办公等高影响系统；GitHub PAT 须改为企业内部 Git（GitLab/Gitea）的等价 token 并按仓库限定权限；审计日志须落入 WORM 存储或不可被智能体覆写的内部 Git 仓库以满足等保留存要求。

搭建本地 MCP 时常见错误

• 错误 1：使用小型通用模型。 7B 以下（以及大多数没有 tool call 微调的 7B–13B 通用模型）会输出格式错误的 tool call。请使用 27B+ 的 tool call 微调模型，停止与 harness 较劲。
• 错误 2：allow-list 自己的 home 目录。 「只是测试」式的 ~ allow-list 会一路保留进入日常使用。请从一开始就建立专用的 agent-workspace。
• 错误 3：让数据库服务器停留在读写模式。 自信满满的智能体在真实表上写出的 DELETE 查询，正是这套规范要避免的事故。把 agent_ro 设为默认；只为明确需要写入的任务、并仅在那些任务期间，临时启用单独的可写角色。
• 错误 4：自动批准每个工具。 「全部批准」开关方便但危险。读取工具（read_file、list_directory、query）可自动批准；写入/shell/PR 工具一律要求授权。
• 错误 5：用 32K 上下文模型做多步浏览器工作。 页面内容很大；浏览三页就可能在推理之前耗尽 32K token。浏览器密集任务请用 128K 上下文模型。
• 错误 6：假设智能体有判断力。 它没有。模型并不理解「这是生产数据库」或「该 PR 会触发部署」。权限是你唯一的屏障。
• 错误 7：一次性安装所有参考服务器。 工具越多 = system prompt 越大 = 工具选择越慢越不可靠。从 filesystem 开始，只在出现需要的工作流时再添加其他。

参考资料

• Model Context Protocol 规范 —— 官方规范、JSON-RPC schema、transport 与生命周期定义。
• modelcontextprotocol/servers GitHub 仓库 —— 参考服务器（filesystem、sqlite、postgres、github、puppeteer 等）及配置文档。
• Goose 项目文档 —— CLI 安装、Ollama provider 配置、MCP 服务器配置语法。
• Ollama 模型库 —— 可用本地模型、tool call 支持标记，以及本指南引用的量化级别。
• Cline GitHub 仓库 —— VS Code 端 MCP 客户端实现，MCP 服务器面板。
• Continue.dev 文档 —— Continue.dev 客户端 mcpServers 配置块参考。

常见问题

延伸阅读

• 2026 年最佳本地 tool calling 模型 —— 上面推荐模型（Gemma 4、GLM-5.1、Qwen3、Llama 3.3）的逐项对比基准。
• 自治本地智能体确实可用 —— 本地 MCP 智能体在长任务上能可靠完成什么、不能做什么的现实检查。
• Continue.dev vs Cline vs Aider：2026 年最佳本地编码智能体 —— 代码形态工作的相邻智能体语境；Cline 与 Continue.dev 也是 MCP 客户端。
• 2026 年最佳本地 LLM —— 更广 open-weights 生态的模型权威。
• 用本地 AI 智能体替代 Zapier —— 同一 MCP 栈的工作流自动化框架。
• Power Local LLM 中心 —— 完整指南库。