031、流行 MCP Server 集成：文件系统、数据库、API 网关
上周五凌晨两点，我盯着终端里一行诡异的报错发呆：
Error: MCP tool execution failed: EACCES: permission denied, open '/etc/nginx/sites-enabled/default'Claude Code 在帮我调整 Nginx 配置时，试图直接修改系统级文件——这本来是个好主意，但权限模型没处理好。我当时的 MCP Server 配置是全局文件系统访问，Claude 拿到权限后直接往/etc目录写东西，结果被 SELinux 拦了。更尴尬的是，它之前成功修改过/var/www下的项目文件，让我误以为权限没问题。
这个坑让我意识到：MCP Server 的集成不是简单的“装个包就能用”，文件系统、数据库、API 网关这三类 Server 各有各的脾气，配置不当轻则报错，重则把生产环境搞崩。
文件系统 MCP Server：别给 Claude 一把万能钥匙
文件系统 MCP Server 是最容易上手的，也是最容易出事的。我见过有人直接配成allowed_paths: ["/"]，然后让 Claude 去改/etc/passwd——这不是开玩笑，真有人这么干过。
正确的做法是按项目粒度隔离。我的claude.json里是这样写的：
{"mcpServers":{"filesystem":{"command":"npx","args":["-y","@modelcontextprotocol/server-filesystem","/home/me/projects/current-project","/home/me/projects/shared-configs"]}}}注意这里只给了两个路径：当前项目目录和共享配置目录。Claude 只能在这两个目录里读写文件，想碰/etc或者~/.ssh？没门。
这里踩过坑：如果你用 Docker 跑 MCP Server，路径映射要格外小心。我有个同事把宿主机的/data映射到容器里的/data，结果 Claude 在容器里删文件，宿主机上的数据也跟着没了。解决方案是给容器加--read-only参数，或者用 tmpfs 做临时存储。
文件系统 Server 最实用的场景是批量重构。比如我要把项目里所有console.log替换成logger.info，直接跟 Claude 说：“扫描 src 目录下所有 .ts 文件，把 console.log 替换成 logger.info，保留原有参数。”它会在几秒内完成，比手动 grep 快十倍。
但有个限制：大文件处理会超时。Claude 的 MCP 调用有默认 30 秒超时，如果你让它读一个 500MB 的日志文件，大概率会挂。我的做法是让 Claude 先用head -n 1000预览，确认需要处理的部分后再操作。
数据库 MCP Server：只读模式是底线
数据库 MCP Server 是双刃剑。它能让你用自然语言查数据库，但也能让你一句话把表删了。
我推荐用@anthropic/mcp-server-postgres或者@modelcontextprotocol/server-postgres，但永远不要在生产数据库上开写权限。我的配置是这样的：
{"mcpServers":{"database":{"command":"npx","args":["-y","@modelcontextprotocol/server-postgres","postgresql://readonly_user:password@localhost:5432/production_db?sslmode=require"]}}}看到readonly_user了吗？这是关键。我在 PostgreSQL 里专门建了一个只读角色：
CREATEUSERclaude_readonlyWITHPASSWORD'complex_password_here';GRANTCONNECTONDATABASEproduction_dbTOclaude_readonly;GRANTUSAGEONSCHEMApublicTOclaude_readonly;GRANTSELECTONALLTABLESINSCHEMApublicTOclaude_readonly;ALTERDEFAULTPRIVILEGESINSCHEMApublicGRANTSELECTONTABLESTOclaude_readonly;别这样写：直接把超级用户密码写在 MCP 配置里。我见过有人把postgres用户的密码明文写在claude.json里，然后提交到 Git 仓库——这等于把数据库钥匙挂在公司门口。
数据库 MCP Server 最爽的用法是写复杂查询。比如我要找“过去7天里，下单超过3次但从未评价过的用户”，直接说人话，Claude 会生成 SQL 并执行，返回结果。省去了我打开 DBeaver、写 JOIN、调 WHERE 条件的时间。
但要注意：敏感数据会暴露在对话历史里。Claude 会把查询结果返回给你，这些结果会被记录在对话中。如果你查了用户手机号、身份证号，这些信息就留在了 Anthropic 的服务器上（如果你用云端版）。我的做法是：只查聚合数据，不查原始行。比如“统计每个城市的用户数”而不是“列出所有用户的手机号”。
API 网关 MCP Server：把微服务变成可调用的工具
API 网关 MCP Server 是我最近才认真用的。它本质上是一个 OpenAPI/Swagger 规范的适配器，把 REST API 端点映射成 MCP 工具。
我用的是@anthropic/mcp-server-openapi，配置方式：
{"mcpServers":{"api-gateway":{"command":"npx","args":["-y","@anthropic/mcp-server-openapi","--schema","https://api.example.com/openapi.json","--headers","Authorization: Bearer YOUR_API_KEY"]}}}这个 Server 会解析 OpenAPI 规范，把每个端点变成一个 MCP 工具。比如你的 API 有GET /users/{id}，Claude 就能调用get_user这个工具。
这里踩过坑：OpenAPI 规范里如果定义了securitySchemes，MCP Server 会自动处理认证。但如果你用的是自定义认证头（比如X-API-Key），就得手动在--headers里传。我一开始没传，Claude 调用 API 时一直返回 401，排查了半天才发现是认证没传过去。
API 网关 MCP Server 的杀手级应用是自动化运维。比如我要给某个服务扩容，传统做法是：登录 AWS 控制台 -> 找到 Auto Scaling Group -> 修改 desired count。现在我可以直接说：“把 order-service 的实例数从 3 调到 5”，Claude 会调用对应的 API 完成操作。
但有个风险：幂等性问题。如果 Claude 调用了一个非幂等的 API（比如“创建订单”），而它因为网络问题重试了，就可能创建重复订单。我的建议是：只暴露 GET 和幂等的 PUT/DELETE 端点给 MCP Server，POST 操作要格外小心。
组合使用：让三个 Server 协同工作
单个 MCP Server 能力有限，但组合起来威力巨大。我最近做了一个自动化脚本，让 Claude 同时使用文件系统、数据库和 API 网关 Server：
- 从数据库 MCP Server 查询“最近 24 小时错误率超过 5% 的服务”
- 从 API 网关 MCP Server 调用对应服务的健康检查接口
- 从文件系统 MCP Server 读取该服务的配置文件
- 分析问题并生成修复建议
整个过程 Claude 自动完成，我只需要看最终报告。这比手动登录三四个系统查日志快了一个数量级。
但组合使用时要注意上下文窗口。每个 MCP Server 的调用结果都会占用 Claude 的上下文，如果三个 Server 同时返回大量数据，很容易撑爆上下文。我的做法是：让 Claude 先做粗粒度查询，根据结果再决定是否深入。比如先查“哪些服务有问题”，再针对有问题的服务查详情。
安全底线：永远不要信任 MCP Server 的输出
最后说一个血的教训。MCP Server 返回的数据是不可信的。如果文件系统 Server 返回了一个文件名叫../../../etc/passwd，而你的代码直接拼接路径去读，那就出事了。同样，数据库 Server 返回的 SQL 结果如果包含恶意内容，也可能导致 XSS 或注入。
我的做法是：所有 MCP Server 的输出都要经过 sanitize。文件路径用path.resolve并检查是否在允许目录内，数据库结果用参数化查询，API 响应用 JSON schema 校验。
另外，定期轮换 MCP Server 的凭证。数据库只读用户的密码、API Key 这些，建议每 90 天换一次。我写了个 cron job，每个月自动生成新密码并更新claude.json。
个人经验
文件系统 Server 适合做代码重构和配置管理，但一定要限制路径范围；数据库 Server 适合做数据分析和问题排查，但必须用只读账号；API 网关 Server 适合做自动化运维，但只暴露安全端点。
别想着一个配置打天下。每个项目、每个环境都应该有独立的 MCP Server 配置。我甚至为开发、测试、生产环境分别写了不同的claude.json，生产环境的数据库 Server 直接禁用，API 网关只暴露 GET 端点。
最后，MCP Server 不是银弹。它让 Claude 能操作你的系统，但也引入了新的攻击面。每次加一个新的 MCP Server，都要问自己：如果这个 Server 被恶意利用，最坏情况是什么？能接受吗？不能接受就别加。
下篇我会写 MCP Server 的自定义开发——当你找不到现成的 Server 时，如何自己写一个。
