企业官网建设流程全解析

1. 为什么我最后只留下这 10 个 MCP Server

MCP Server 说白了就是给大模型装上的「外设驱动」：模型本身只会聊天，接上 Git MCP Server 它就能读你的仓库状态，接上 Filesystem MCP Server 它就能翻你的目录，接上 SQLite MCP Server 它就能查你的本地库。适合谁？适合那种手上同时开着 GitLab、本地 Git、一堆散落文件、还有几个 SQLite 小库的开发者——工具链越杂，越需要一个统一入口把它们串起来。

我自己的场景很典型：一个项目在 GitLab 上，本地用 Git 管分支，测试数据塞在 SQLite 里，配置文件散在几个目录。以前每换一个工具就要切一次窗口、记一套命令。后来把这些都做成 MCP Server，再统一走一个 API 通道，模型就能在一次对话里把「看下当前分支改了啥 → 读一下那个配置文件 → 查一下测试库里的记录」串起来做完。

这篇盘点的是我实测下来真正高频的 10 个：GitLab、Git、Filesystem、SQLite、Redis、PostgreSQL、MongoDB、Excel、Kibana、Prometheus。重点不是罗列功能，而是每个都给可复制的配置片段、接入统一 Key 的改法、以及连通性验证动作。你照着配完就能复现，配不通也能在排障章节里找到对应报错。

先说清楚一个前提：这些 Server 各自要连不同的后端（GitLab 要 token、数据库要连接串），如果每个都单独配一套鉴权，管理成本会爆炸。所以我的做法是让它们统一走一个 API 通道，Base URL 指向同一个入口，Key 也只维护一份。这样换模型、加 Server 都不用重新折腾鉴权。下面第二节先把这个前置讲透，后面每个 Server 的配置才有落点。

2. 接入前的统一通道准备：Base URL 与 Key 怎么放

不管你用 Cline、Claude Code 还是别的支持 MCP 的客户端，核心就三样东西：Base URL、API Key、Model ID。这三件套配错一个，后面所有 Server 都连不上。我踩过的坑基本都集中在这一步，所以单独拎出来讲。

Base URL 统一填https://taotoken.net/api，注意这个地址不带任何查询参数，别自己往上加斜杠或者路径。API Key 去控制台生成，生成后只显示一次，记得当场存好。Model ID 按你实际要调的模型填，比如做代码类任务就选对应的编码模型。

如果你用的是 Claude Code 这类走 Anthropic 协议的客户端，配置方式是在 settings 里指定 Base URL 和 Key。如果是 Cline 这种走 OpenAI 兼容协议的，就在 provider 设置里填。Codex 的话改auth.json，把 base_url 和 api_key 写进去。三种客户端的写法不一样，但本质都是把请求指向同一个通道。

这里给一个 Cline 的 MCP 配置骨架，路径是客户端的 MCP 设置文件（不同版本位置略有差异，一般在用户配置目录下的 mcp 配置里）：

{ "mcpServers": { "git": { "command": "uvx", "args": ["mcp-server-git", "--repository", "/path/to/your/repo"], "env": { "GIT_AUTHOR_NAME": "your-name", "GIT_AUTHOR_EMAIL": "you@example.com" } } } }

注意这个片段里没有出现 Base URL 和 Key，因为 MCP Server 本身是本地进程，它负责操作 Git；而模型调用走的是客户端那一层的通道配置。很多人会把这两层搞混：MCP Server 是「手」，模型通道是「大脑」，手不需要知道大脑连的哪个网关。所以 Base URL 和 Key 配在客户端，MCP Server 配在 mcpServers 里，两者分开。

Codex 的auth.json改法大致是这样：

{ "base_url": "https://taotoken.net/api", "api_key": "sk-你的key" }

改完保存，重启客户端。验证通道是否通，最直接的办法是发一条最简单的对话请求，看能不能正常返回。如果返回 401，说明 Key 不对或没生效；如果报 local proxy failed，多半是本地网络或客户端代理设置的问题，跟通道本身无关。

把这一层打通之后，下面每个 Server 的配置就只是往 mcpServers 里加一段的事。我建议你先把 Git 和 Filesystem 这两个配好，因为它们不依赖外部服务，最容易验证成功，能快速确认整条链路是通的。

3. 十个 MCP Server 的可复制配置片段

这一节是全文最干的部分，每个 Server 给一段能直接抄的配置，外加它最常用的几个 Tool。配置里的路径、token 记得换成你自己的。

3.1 Git MCP Server：本地仓库操作

Git MCP Server 让模型能直接读仓库状态、看 diff、提交变更。支持的 Tool 有 git_status、git_diff_unstaged、git_diff_staged、git_diff、git_commit、git_add、git_reset、git_log、git_create_branch、git_checkout、git_show、git_init。

{ "mcpServers": { "git": { "command": "uvx", "args": ["mcp-server-git", "--repository", "/Users/me/projects/demo"] } } }

配好后你可以直接问模型「当前有哪些未暂存的改动」，它会调 git_diff_unstaged 返回结果。实测下来这个 Server 最实用的场景是让模型帮你写 commit message：先 git_diff_staged 拿到暂存内容，再生成描述，最后 git_commit 提交，一条龙。

3.2 GitLab MCP Server：企业级仓库管理

GitLab MCP Server 面向 GitLab 仓库，能做创建仓库、推代码、建 issue、提 MR。Tool 包括 create_or_update_file、push_files、search_repositories、create_repository、get_file_contents、create_issue、create_merge_request、fork_repository、create_branch。

{ "mcpServers": { "gitlab": { "command": "uvx", "args": ["mcp-server-gitlab"], "env": { "GITLAB_PERSONAL_ACCESS_TOKEN": "glpat-你的token", "GITLAB_API_URL": "https://gitlab.cn/api/v4" } } } }

token 在 GitLab 的「设置 → 访问令牌」里生成，勾选 api 权限。注意 GITLAB_API_URL 要带你实际用的 GitLab 实例地址，别照抄。这个 Server 我主要用来让模型批量建 issue，比手点快很多。

3.3 Filesystem MCP Server：文件系统读写

Filesystem MCP Server 用 Node.js 实现，能读写文件、建目录、移动、搜索、看元数据。Tool 有 read_file、read_multiple_files、write_file、edit_file、create_directory、list_directory、move_file、search_files、get_file_info、list_allowed_directories。

{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects", "/Users/me/notes" ] } } }

后面跟的路径是允许访问的白名单，只有列进去的目录模型才能碰。这个设计很重要，别图省事直接给根目录。我一般只放项目目录和笔记目录，避免误操作。

3.4 SQLite MCP Server：本地数据库查询

SQLite MCP Server 做数据库交互，能跑 SQL、分析数据、生成洞察备忘录。Tool 有 read_query、write_query、create_table、list_tables、describe-table、append_insight。

{ "mcpServers": { "sqlite": { "command": "uvx", "args": ["mcp-server-sqlite", "--db-path", "/Users/me/data/test.db"] } } }

配好后问「test.db 里有哪些表」，它会调 list_tables。再问「统计一下 orders 表里每个状态的数量」，它走 read_query。注意 write_query 会真的改数据，测试库随便玩，生产库别接。

3.5 Redis MCP Server：缓存操作

Redis MCP Server 通过标准化 Tool 操作 Redis，主要有 set、get、delete、list。

{ "mcpServers": { "redis": { "command": "uvx", "args": ["mcp-server-redis"], "env": { "REDIS_URL": "redis://localhost:6379/0" } } } }

适合调试缓存逻辑：让模型 set 一个 key，再 get 出来确认，比开 redis-cli 快。

3.6 PostgreSQL MCP Server：只读查询

PostgreSQL MCP Server 提供只读访问，Tool 就一个 query。

{ "mcpServers": { "postgres": { "command": "uvx", "args": ["mcp-server-postgres"], "env": { "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb" } } } }

只读这个限制我很喜欢，接生产库也不怕模型手滑写坏数据。查表结构、跑统计都够用。

3.7 MongoDB MCP Server：文档数据库

MongoDB MCP Server 操作 MongoDB，Tool 有 connect、find、aggregate、count、db-status、insert-one、create-index 等。

{ "mcpServers": { "mongodb": { "command": "uvx", "args": ["mcp-server-mongodb"], "env": { "MONGODB_URI": "mongodb://localhost:27017/mydb" } } } }

aggregate 这个 Tool 特别适合让模型帮你写聚合管道，你描述需求它生成 pipeline，比翻文档快。

3.8 Excel MCP Server：表格处理

Excel MCP Server 让模型操作 Excel，Tool 有 create_workbook、create_worksheet、get_workbook_metadata、write_data_to_excel、read_data_from_excel、merge_cells 等。

{ "mcpServers": { "excel": { "command": "uvx", "args": ["mcp-server-excel"], "env": { "EXCEL_FILES_PATH": "/Users/me/sheets" } } } }

做数据报表时很省事：让模型读一个 sheet，处理后写到新 sheet，全程不用打开 Excel。

3.9 Kibana MCP Server：日志检索

Kibana MCP Server 操作 Kibana，Tool 有 get_status、execute_api、search_kibana_api_paths、list_all_kibana_api_paths、get_kibana_api_detail。

{ "mcpServers": { "kibana": { "command": "uvx", "args": ["mcp-server-kibana"], "env": { "KIBANA_URL": "http://localhost:5601", "KIBANA_API_KEY": "你的key" } } } }

排查线上问题时，让模型直接查日志比手动拼查询语句快得多。

3.10 Prometheus MCP Server：指标查询

Prometheus MCP Server 操作 Prometheus，Tool 有 execute_query、execute_range_query、list_metrics、get_metric_metadata、get_targets。

{ "mcpServers": { "prometheus": { "command": "uvx", "args": ["mcp-server-prometheus"], "env": { "PROMETHEUS_URL": "http://localhost:9090" } } } }

看监控指标时，直接问「最近一小时 CPU 使用率峰值多少」，它走 execute_range_query 返回。

十个配完，你的 mcpServers 里就有十个条目了。建议分批加，每加一个就验证一次，别一次性全塞进去，出问题不好定位。

4. 连通性验证与调用日志检查

配完不等于能用，必须验证。我的验证流程分三步：先确认通道通，再确认单个 Server 起得来，最后确认模型能真正调到 Tool。

第一步，通道验证。发一条普通对话，看模型有没有正常回复。如果这一步就失败，问题在 Base URL 或 Key，跟 MCP Server 无关。返回 401 就是 Key 问题，去控制台重新生成一个。

第二步，Server 启动验证。以 Git 为例，配好后在客户端里问「列出当前仓库的 git status」。如果模型返回了分支名和改动文件，说明 Server 起来了。如果报错说找不到命令，检查 uvx 或 npx 有没有装。uvx 是 uv 工具链的一部分，没装的话先装 uv。

第三步，日志检查。大多数客户端会把 MCP Server 的 stderr 输出到日志里。Git Server 启动失败时，日志里会有类似「repository not found」的提示，说明--repository路径写错了。Filesystem 报「path not allowed」，说明你访问的目录不在白名单里。

我实测时遇到过一个典型问题：Git Server 能起来，但 git_commit 一直失败。查日志发现是没配 GIT_AUTHOR_NAME 和 GIT_AUTHOR_EMAIL，提交时缺作者信息。补上这两个环境变量就好了。所以配置片段里那两个 env 别省。

还有一个高频坑是路径问题。--repository和 Filesystem 的白名单路径都必须是绝对路径，写相对路径会失败。Windows 下路径分隔符要用双反斜杠或者正斜杠。

验证 SQLite 时，如果报「unable to open database file」，八成是--db-path指向的文件不存在。SQLite 不会自动建库文件，你得先手动建一个空的，或者用 create_table 让它建。

验证 Redis 和 PostgreSQL 时，先确认本地服务真的在跑。redis-cli ping返回 PONG，psql能连上，再去配 MCP。服务没起，配了也白搭。

日志里如果看到「local proxy failed」，这通常不是 MCP 的问题，而是客户端到通道之间的网络层出了状况。检查一下客户端的代理设置，或者换个网络环境试试。这个报错跟 Server 配置无关，别去改 mcpServers。

把这三步走完，十个 Server 里能通几个就是几个。通不了的按报错对号入座，基本都能解决。

5. 常见报错排查对照表

这一节把我在实测中撞到的报错整理成对照表，你遇到时直接查。

重点说几个容易误判的。401 和 local proxy failed 经常被混为一谈，其实前者是鉴权问题，后者是网络问题，处理方向完全不同。看到 401 就去查 Key，看到 local proxy failed 就去查网络，别在 MCP 配置里瞎改。

reading choices 这类报错通常出现在模型返回体解析阶段，多半是 Model ID 填了个不存在的模型，或者通道返回了非预期格式。换个确认可用的 Model ID 基本能解决。

OAuth 报错在 Claude Code 这类客户端里比较常见，一般是授权过期。重新走一遍授权流程即可，不用动 MCP 配置。

还有一个隐蔽的坑：多个 Server 同时配了但只有一个能通。这通常是某个 Server 的启动命令阻塞了，比如 uvx 第一次运行要下载包，超时了。解决办法是先单独在终端里跑一遍uvx mcp-server-git --help，让它把包下完，再配到客户端里。

排查的核心思路是分层：通道层（Base URL/Key/Model ID）、进程层（Server 能不能起来）、权限层（token/白名单/路径）。哪层报错查哪层，别跨层猜。

6. 按场景选通道：对话、编码、Agent 怎么分流

十个 Server 配好之后，接下来是选对通道。不同任务对通道的要求不一样，选错了要么浪费要么不够用。

如果你只是偶尔验证某个模型能不能调通、或者做轻量的对话测试，直接用模型对话入口就行，地址是https://taotoken.net/api对应的对话能力，配合控制台生成的 Key 即可。这种场景不需要长期占用资源，随用随开。

如果你是要长期做编码任务，比如每天都要让模型读仓库、改代码、跑测试，那更适合用 Coding Plan。它面向的就是这种持续性的编码工作流，配合 Git、Filesystem、GitLab 这几个 Server，能把「读代码 → 改代码 → 提交」整条链路串起来。我自己的日常开发就是走这个组合。

如果你在搭 Agent，需要模型自主调用多个 Tool 完成复杂任务，那 Coding Plan 同样适用，因为它对多轮调用和长上下文的支持更稳。Agent 场景下 Server 之间的协作很频繁，通道稳定性比单次响应速度更重要。

具体到操作，去控制台生成 Key 之后，接入文档里有各客户端的详细配置说明。Claude Code 用户看 Anthropic 协议那部分，Cline 用户看 OpenAI 兼容那部分，Codex 用户直接改auth.json。三个入口分别是控制台的 API Keys 页面、接入文档页、以及模型对话页。

我的建议是：先用模型对话验证通道通不通，再用 Coding Plan 跑一个真实的小任务，比如让模型读一个 Git 仓库、改一行代码、提交。跑通了，再把这十个 Server 按需加进去。别一上来就全配，容易在排障时迷失。

最后留一个我自己的习惯：每加一个新 Server，就在笔记里记一条「这个 Server 解决什么问题、配了哪些 env、验证时用的什么命令」。攒到十个的时候，这份笔记就是你的私人排查手册，比任何文档都好使。