通过 MCP 将 Ollama 连接到文件、数据库和 API：2026 年本地配置指南

快速事实

• 协议： JSON-RPC 2.0 通过 stdio（本地子进程）或 Streamable HTTP（远程）传输。较早的 HTTP+SSE transport 已弃用。本地智能体几乎只用 stdio。当前规范版本为 2026-07-28。
• 来源： 由 Anthropic 作为开放规范创建（modelcontextprotocol.io）。modelcontextprotocol/servers 中仍在维护的参考服务器只有少数几个（filesystem、git、fetch、memory 等）；SQLite、PostgreSQL、Puppeteer 和 GitHub 已移至 servers-archived。现在由各厂商发布自己的服务器。
• 本地客户端： Goose（开源，仓库 aaif-goose/goose）、Cline（VS Code 扩展）、Continue.dev（VS Code/JetBrains）、LM Studio（桌面应用），以及多个 CLI 工具。
• 兼容的 Ollama 模型： 任何具备原生 tool call 训练的模型，例如 Gemma 4 31B、GLM-4.7 Flash、Qwen3.6 27B、Qwen3 32B、Qwen3-Coder 30B、Llama 3.3 70B。
• 默认 transport： 本地进程用 stdio；只有需要跨机器或跨智能体共享服务器时才用 Streamable HTTP。
• 配置在客户端中： Goose 读取 ~/.config/goose/config.yaml 中的 extensions 块（或运行 goose configure）；Cline 和 Continue.dev 有各自的 MCP 设置。字段含义在各处相同：服务器名、command、args、env vars。
• 无需 Claude Desktop。 协议开放，独立于 Claude Desktop；这里用到的服务器均为开源（请自行查看各自许可证），可在任何符合规范的客户端下运行。

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

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

配置：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 31B (gemma4:31b)、GLM-4.7 Flash (glm-4.7-flash)、Qwen3.6 27B (qwen3.6:27b)、Qwen3 32B (qwen3:32b) 或 Llama 3.3 70B (llama3.3:70b) 中选一个。32 GB 统一内存或 24 GB VRAM 在 Q4_K_M 下从容运行 26B–32B。
• Step 3 —— 安装 Goose。 在 macOS 或 Linux 上运行 curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash（或 brew install block-goose-cli）。在 Windows 上使用 Goose 文档中的 PowerShell 安装程序，或使用 WSL。CLI 安装为 goose。
• Step 4 —— 将 Ollama 配置为 provider。 运行 goose configure，选择 ollama 作为 provider，将模型设为已拉取的那个，host 设为 http://127.0.0.1:11434（留空也表示 localhost:11434）。Goose 会写入 ~/.config/goose/config.yaml。Ollama 的默认上下文窗口可能很小（Goose 文档提到 4096 token），可能导致 Goose 忽略其扩展——请用 OLLAMA_CONTEXT_LENGTH=32768（或更高）启动 Ollama。
• Step 5 —— 加入 filesystem MCP 服务器。 运行 goose configure，选择 Add Extension，再选 Command-line Extension，或在 ~/.config/goose/config.yaml 中加入 extensions 块（配置示例见下）。如只想一次性测试，goose session --with-extension "npx -y @modelcontextprotocol/server-filesystem /path/to/workspace" 仅为该会话启用它。启动 goose session 并请求列出测试目录的文件。第一轮即可确认服务器接入。
• Step 6 —— 用真实任务验证。 试运行 goose session，请求「列出 notes/ 中每个 Markdown 文件的标题与字数，并将结果写入 notes/index.md」。如果智能体读、汇总、回写都成功，整个循环可工作。

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

# 2. Install Goose (macOS / Linux)
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

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

# 4. Give Ollama a context window big enough for tool use, then start a session
OLLAMA_CONTEXT_LENGTH=32768 ollama serve   # in a separate terminal
goose session

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

• 安装： 参考服务器为 @modelcontextprotocol/server-filesystem，通过 npx -y 运行（无需全局安装，需要 Node.js）。它是仍在维护的参考服务器之一。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
extensions:
  filesystem:
    type: stdio
    name: filesystem
    enabled: true
    cmd: npx
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/agent-workspace"]
    envs: {}
    timeout: 300

数据库服务器：安全查询 Postgres（和 SQLite）

• Postgres：postgres-mcp（Crystal DBA，MIT 许可证） 是带只读模式的选项（PyPI 上最新发布在 2025 年 5 月，依赖它之前请先查看仓库的活跃度）。用 uvx postgres-mcp --access-mode=restricted 运行（或 pipx install postgres-mcp，或使用其 Docker 镜像），并通过 DATABASE_URI 环境变量传入连接 URI。受限模式允许只读事务并带有查询时间限制；非受限模式仅用于开发。
• 同时使用专用只读角色。 受限模式是一道屏障，数据库角色是另一道。创建一个仅有 SELECT 授权的 agent_ro 角色，并使用该角色的 connection string。
• SQLite：参考服务器已归档。 它是 Python 包 mcp-server-sqlite（不是 npm 包；最后一次发布在 2025 年 4 月），可能仍能运行，但不会再有修复。请只让它指向文件副本，绝不要指向唯一的一份文件，或者改把数据加载进 Postgres。在把文件交给任何社区 SQLite 服务器之前，先阅读其代码。
• Schema 感知： 在提分析问题前请智能体「列出表并 describe 最常用的五个」——模型在检查过 schema 之后比凭空猜列名要准确得多。
• 成本： 查询直接落在数据库上。在一亿行的表上格式不当的 SELECT * 与人手所造成的事故同等严重——把该角色放在独立连接池并设置 statement timeout。

# ~/.config/goose/config.yaml
extensions:
  postgres:
    type: stdio
    name: postgres
    enabled: true
    cmd: uvx
    args: ["postgres-mcp", "--access-mode=restricted"]
    envs:
      DATABASE_URI: "postgresql://agent_ro:${PG_AGENT_PASSWORD}@127.0.0.1:5432/analytics"
    timeout: 300

浏览器服务器：用 Playwright MCP 驱动浏览器

• 选哪个服务器： 使用微软的 @playwright/mcp（npx @playwright/mcp@latest）。旧的 @modelcontextprotocol/server-puppeteer 已被标记为「no longer supported」，而 npm 上并不存在 @modelcontextprotocol/server-playwright 这个包。
• 暴露的工具： browser_navigate、browser_snapshot、browser_click、browser_type、browser_fill_form、browser_evaluate（运行 JavaScript）、browser_take_screenshot、browser_tabs、browser_wait_for。模型通过 browser_snapshot（无障碍快照，Playwright MCP 建议采取操作时优先用它而不是截图）读取页面，截图只用来查看。
• 延迟： 真实浏览器会话每个动作 1–5 秒。多步浏览很容易消耗 30–60 秒以及数万 token，因为页面内容较大。请使用 32K+ 上下文窗口。
• 元素引用： 模型依据快照中的引用来点击元素。小模型常选错；27B+ 的 tool calling 模型对常见模式较为可靠。把任务范围收紧——「抽取此 URL 的标题与首段」远比「在站内浏览并找到联系页」可靠。
• 适合场景： 调研（打开页面、汇总、追加到笔记）、回归测试（导航、点击、截图）、在你掌控的页面上的表单填写。不适合场景：任何在真实 Web 上误点会带来后果的工作。

# ~/.config/goose/config.yaml
extensions:
  playwright:
    type: stdio
    name: playwright
    enabled: true
    cmd: npx
    args: ["@playwright/mcp@latest"]
    envs: {}
    timeout: 300
# Block obviously dangerous endpoints at the OS firewall level
# rather than relying on the agent to refuse them.

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

• 安装： 使用 GitHub 官方的 github/github-mcp-server，通过其 Docker 镜像（ghcr.io/github/github-mcp-server）运行，并将 PAT 放入 GITHUB_PERSONAL_ACCESS_TOKEN 环境变量。旧的 @modelcontextprotocol/server-github npm 包已被标记为「no longer supported」；新的配置不要使用它。
• 暴露的工具： 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
extensions:
  github:
    type: stdio
    name: github
    enabled: true
    cmd: docker
    args: ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"]
    envs:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GH_AGENT_PAT}"
    timeout: 300
# 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 31B (gemma4:31b) —— Google 的 tool call 训练在同尺寸中处于业内最佳。Q4_K_M 下可装入 16 GB 统一内存或 24 GB VRAM。通用推理良好；在链式 tool call 上略偏保守。
• GLM-4.7 Flash (glm-4.7-flash) —— 智谱的模型 tool call 可靠性极强，开箱 128K 上下文窗口。比 Gemma 4 略重；24 GB GPU 上从容运行。
• Qwen3.6 27B (qwen3.6:27b) —— Ollama 上较新的 Qwen 选项（约 18–19 GB，256K 上下文，支持 tool calling）。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 芯片 Mac 或搭载 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 开始，只在出现需要的工作流时再添加其他。
• 错误 8：照着旧教程安装已归档的参考服务器。 npm 包 @modelcontextprotocol/server-postgres、-puppeteer 和 -github 已被标记为「no longer supported」，SQLite 服务器也已归档。一些较早的指南还会提到并不存在的 npm 包（server-sqlite、server-playwright）。请使用上文列出的仍在维护的服务器。
• 错误 9：把 MCP 配置写进 Ollama。 Ollama 没有 MCP 设置。服务器在客户端中配置（Goose 的 extensions，Cline 或 Continue.dev 的 MCP 设置）。

参考资料

• Model Context Protocol 规范 —— 官方规范、JSON-RPC schema、transport 与生命周期定义，包括 2026-07-28 的变更记录。
• modelcontextprotocol/servers GitHub 仓库 —— 仍在维护的参考服务器（filesystem、git、fetch、memory 等）以及已归档服务器的列表。
• github/github-mcp-server —— GitHub 官方 MCP 服务器，Docker 与二进制安装方式。
• microsoft/playwright-mcp —— Playwright MCP 服务器及其浏览器工具。
• crystaldba/postgres-mcp —— 带受限（只读）访问模式的 Postgres MCP 服务器。
• 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-4.7、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 中心 —— 完整指南库。