给 Claude 接入 AWS 能力时，基于 awslabs 扩展比从零开发效率更高

最近在给 Claude 接入 AWS 能力时，我差点在 AWS Glue 的插件开发上浪费掉整整一周。很多开发者在写 MCP Server 时习惯于“先撸代码”，结果写到一半才发现，社区或者官方早就有更成熟的实现。如果你现在正准备为 LLM 客户端构建 AWS 相关的 MCP Server，我强烈建议你先去深挖 awslabs/mcp 仓库，而不是直接面对 SDK 开始写 CRUD。

很多人的误区在于把 MCP Server 仅仅当成一个 API 转发层。但实际上，在 AWS 这种极其复杂的生态中，如何定义 Tool 的描述（Description）以确保 LLM 能够准确调用，以及如何处理 API 返回的冗长响应，才是真正的技术难点。如果你从零开始，你不仅要处理基础的 SDK 调用，还得自己去调试 LLM 为什么总是传错参数，或者为什么无法正确解析资源 ID。

通过分析 awslabs/mcp 的实现，你会发现它在几个关键维度上已经解决了痛点。首先是基础设施管理，EC2 和 S3 的基础操作已经封装完毕，不需要你再去重复写一遍 SDK 的调用逻辑。其次是资源发现机制，这比单纯的增删改查实用得多——一个能够自动检索资源 ID 的 Tool，能让 LLM 在执行操作前先定位资源，极大地降低了误操作率。最关键的是权限控制，IAM 角色映射的坑非常深，直接复用现有的实现可以省去大量在策略配置上浪费的时间。

对于想要快速上手的开发者，我建议放弃“独立 Server”的思路，转而采用“基于框架扩展”的路径。

第一步，克隆 awslabs/mcp 的官方实现。不要急着写代码，先去分析 index.ts。重点看它是如何定义 Tool 的，特别是描述字段是如何引导 LLM 触发特定功能的。你会发现，一个高质量的描述比复杂的逻辑更能提升 LLM 的调用成功率。

第二步，在 server.ts 中注入你需要的特定服务客户端。因为该项目基于 AWS SDK v3，你可以非常方便地引入其他服务模块。如果你需要扩展 Glue 或 Athena 的能力，直接参考已有的数据流处理模式，重点放在响应结果的精简上，避免将整个 API 原始 JSON 丢给 LLM，导致 Token 溢出或干扰判断。

第三步，配置本地环境。在 claude_desktop_config.json 中正确配置环境变量是运行的前提。一个典型的配置示例如下：

{
  "mcpServers": {
    "aws-mcp": {
      "command": "node",
      "args": ["/path/to/aws-mcp/build/index.js"],
      "env": {
        "AWS_REGION": "us-east-1",
        "AWS_ACCESS_KEY_ID": "your_key",
        "AWS_SECRET_ACCESS_KEY": "your_secret"
      }
    }
  }
}

在这种模式下，你的开发重心将从“如何调用 API”转移到“如何优化 LLM 的交互体验”上。尤其是面对 AWS 那种层层嵌套的 API 响应时，参考 awslabs 已经写好的转换逻辑，能让你省掉大量对着日志调试的时间。总之，在 MCP 生态快速迭代的现在，选择一个成熟的基座进行扩展，其维护成本远低于维护一个独立且简陋的自定义 Server。