031、流行 MCP Server 集成:文件系统、数据库、API 网关

📅 2026/6/19 16:05:29
031、流行 MCP Server 集成:文件系统、数据库、API 网关
031、流行 MCP Server 集成文件系统、数据库、API 网关上周五凌晨两点我盯着终端里一行诡异的报错发呆Error: MCP tool execution failed: EACCES: permission denied, open /etc/nginx/sites-enabled/defaultClaude 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:passwordlocalhost:5432/production_db?sslmoderequire]}}}看到readonly_user了吗这是关键。我在 PostgreSQL 里专门建了一个只读角色CREATEUSERclaude_readonlyWITHPASSWORDcomplex_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 规范里如果定义了securitySchemesMCP 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 ServerPOST 操作要格外小心。组合使用让三个 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 时如何自己写一个。