我直到自己建造一个才获得MCP

发布: 6天前 (2026年2月2日 GMT+8 16:11)

12 分钟阅读

Source: Dev.to

要为您提供完整的翻译，我需要您粘贴或提供文章的正文内容（包括任何标题、段落、列表等）。请把您想翻译的文本贴在这里，我会保持原有的 Markdown 格式、代码块和链接不变，只翻译正文部分为简体中文。

From “What’s an MCP Server?” to “I Built One”

八个月前，我几乎说不出 MCP 服务器 是什么。

我在 LinkedIn 帖子和我们的 AWS Community Builders Slack 中看到过 (Model Context Protocol) 这个词。大家都对它很兴奋，但我根本不知道它到底是什么——也不清楚我为什么要在意它。它感觉像是 AI 人员（“数据科学和机器学习工程师”）的专属话题，离我团队日常的云基础设施和平台职责很遥远。

我尝试过几个 AWS Labs 的 MCP 服务器（通过 Amazon Q，包括文档和计费示例）。它们能用，但我把它们当作不透明的插件——有用，却神秘。我能使用它们，却解释不了它们的工作原理。

随后，在十一月，Kiro 正式对外开放，我开始更深入地探索它的功能（后续文章会详细介绍）。与此同时，我有机会参与一个 概念验证（Proof‑of‑Concept），来构建一个 MCP 服务器。最初的想法是通过 MCP 服务器将我们的公共 API 暴露给 AI 工具和大语言模型（LLM）。一旦验证成功，目标就是把它迁移到产品中，让客户也能使用。

当我深入研究时，MCP 服务器逐渐变得清晰起来。

什么是 MCP 服务器？

类似于 API，但专为 AI 代理 设计。
允许代理与 其训练数据之外的服务和数据集 进行通信并利用它们。

注意： 本文不是指南或教程。已有优秀资源可供参考，你也可以随时向你选择的 AI 工具询问澄清。这是一篇反思，从“我完全不知道这是什么”到“我可以构建并部署它”。

引发洞察的问题

大型语言模型（LLM）功能强大，但它们是时间冻结的——只能了解训练数据中已有的内容。

它们不知道：

您的代码仓库当前状态
您内部文档的内容
您的 Jira 工单状态
您的 API 或数据库的结构

如果我们希望 AI 工具在真实的工程工作流中真正有用，就需要一种安全且一致地将它们连接到实时外部系统的方法。这正是集成发挥作用的地方——但也会迅速变得混乱。

想象您正在构建 AI 集成

您希望助手能够：

访问您的 GitHub 仓库
查询您的 Jira 工单
搜索公司的文档
检查您的数据库

现在想象您有四个 AI 工具：

AI Tool	GitHub	Jira	Docs	Database
Claude	✅	✅	✅	✅
Copilot	✅	✅	✅	✅
Cursor	✅	✅	✅	✅
ChatGPT	✅	✅	✅	✅

这意味着4 × 4 = 16 个自定义集成。每个集成都：

构建方式不同
独立维护
与其他工具不兼容
工作重复

这完全不可持续。

使用标准协议，您只需一次描述您的能力，任何符合规范的 AI 都可以使用它们。复杂度从 O(N × M) 降至 O(N + M)，其中 N = AI 工具数量，M = 数据源数量。

MCP：AI 的通用适配器

把 MCP 看作是 AI 工具的 USB‑C。

USB‑C 之前

键盘 → PS/2 接口
鼠标 → 串行接口
打印机 → 并行接口
摄像头 → 专有连接器

每个设备都需要自己的接口，且只能与特定的计算机配合使用。

USB‑C 之后

一种标准连接器即可在任何地方使用。

MCP 对 AI 也实现了同样的效果

MCP 之前	MCP 之后
每个 AI 工具都需要为每个数据源定制集成	统一的标准协议；任何 MCP 服务器都能与任何 MCP 客户端配合使用

**示例：**只需构建一次 GitHub MCP 服务器 → 它即可与 Claude、Copilot、Cursor，以及任何未来兼容 MCP 的 AI 工具一起使用。

什么是 MCP 服务器？

简而言之，MCP 服务器是一个程序，它：

连接到数据源（GitHub、数据库、API 等）

通过标准化的 “工具” 暴露这些数据

使用 MCP 协议，以便任何 AI 都能使用它

MCP 服务器本质上是一个 包装器——类似于 API——但不是提供大量 REST 端点，而是暴露工具。

当 MCP 服务器连接到 AI 时，它会宣布自己的能力：

{
  "tools": [
    {
      "name": "search_repositories",
      "description": "Search GitHub repositories",
      "parameters": {
        "query": "string",
        "limit": "number"
      }
    },
    {
      "name": "get_file_contents",
      "description": "Get contents of a file from a repository",
      "parameters": {
        "owner": "string",
        "repo": "string",
        "path": "string"
      }
    }
  ]
}

AI 现在知道：

有哪些工具可用
每个工具的功能
它们需要的参数
如何调用它们

这些工具是 自我文档化 的，但仍需谨慎使用。

工具太多 = 上下文过载

当我添加更多工具时，我意识到 让 AI 负担过多定义会影响性能。

5 MCP 服务器 × 每个 20 个工具 = 可用 100 个工具

对于每个请求，AI 必须：

加载所有 100 个工具定义
理解每个工具的作用
决定使用哪一个
执行正确的工具

后果

上下文膨胀 – 工具定义在实际提问之前就消耗了宝贵的 token。
准确性下降 – AI 可能会选错工具，尤其是名称模糊时。

粗略 token 计数：
100 个工具 ×（名称 + 描述 + 参数模式）→ 每次请求 数千个 token。

最佳实践

有目的地 选择要安装的 MCP 服务器。
不要安装所有找到的 MCP 服务器。
将 工具集聚焦 在 AI 实际需要的范围内。

TL;DR

MCP (Model Context Protocol) 是一种 标准协议，让 AI 代理能够通过 “工具” 调用外部服务。
MCP server 将数据源（GitHub、Jira、DB 等）封装，并将其公开为一组工具，任何兼容 MCP 的 AI 都可以使用。
采用 MCP 后，你可以用 N × M 个自定义集成 替换为 N + M 个组件，大幅降低工程开销。
将 MCP 服务器视作 AI 领域的 USB‑C：一个接口，连接多种设备。
避免工具膨胀——只公开真正有价值的工具。

现在，你已经拥有了清晰的思维模型：MCP = 通用适配器；MCP server = 适配器实现；tools = 你所暴露的插头。祝构建愉快！

示例配置

{
  "mcpServers": {
    "awslabsaws-documentation-mcp-server": {
      "command": "uvx",
      // some args
      "disabled": false,
      "disabledTools": [],
      "autoApprove": ["read_documentation"]
    },
    "terraform-mcp-server": {
      "command": "uvx",
      // some args
      "disabled": true,
      "autoApprove": []
    }
  }
}

不同的代理可以拥有不同的 MCP 设置：

CloudOps 代理 – 使用 AWS 文档和 Terraform MCP 服务器。
Frontend 代理 – 可能使用 React 和 GitHub MCP 服务器。

你也可以 自动批准 安全的命令，让代理自动执行它们。

使用清晰的工具命名

在构建自己的 MCP 服务器时，请使用带命名空间的名称。

不佳

search()
get()
list()

良好

github_search_repositories()
github_get_file_contents()
github_list_pull_requests()

AI 能更快地过滤并理解各个领域。

使用资源进行惰性加载

一些 MCP 服务器使用资源而不是大量单独的工具。

不使用 50 个不同文档的工具

get_lambda_docs()
get_s3_docs()
get_ec2_docs()

使用一个工具 + 资源

read_documentation(resource_uri)

资源

docs://aws/lambda
docs://aws/s3
docs://aws/ec2

资源是按需发现的，而不是预先加载的。

我们将在实际构建第一个 MCP 服务器时进一步探讨最佳实践。

Source: …

通信模式

MCP 服务器可以通过两种方式进行通信。

1. STDIO（本地进程）

作为本地进程运行。
通过 stdin/stdout 进行通信（类似终端管道）。
AI 客户端负责启动并管理该进程。

配置示例

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/files"]
    }
  }
}

何时使用 STDIO

✅ 本地工具、文件系统、git 操作

缺点 – （在此列出任何缺点）

2. HTTP（远程服务）

作为远程 HTTP 服务运行。
客户端通过 URL + 身份验证进行连接。

配置示例

{
  "mcpServers": {
    "company-api": {
      "type": "http",
      "url": "https://mcp.company.com",
      "headers": {
        "Authorization": "Bearer ${API_TOKEN}"
      }
    }
  }
}

何时使用 HTTP

✅ 共享服务或 API

缺点 – （在此列出任何缺点）

生态系统概览

一旦我了解了 MCP，就意识到整个生态系统正在快速增长：

AWS – 选择丰富（例如，AWS Labs MCP）
Terraform
Atlassian – Jira 与 Confluence
GitHub
MCP 服务器 – 超赞的 MCP 服务器

有许多实用的服务器可以提升你使用 AI 的方式，但要小心并有选择性——你可能在第一周就装上十几台！

构建自己的系统

入门门槛很低：

Python – FastMCP
TypeScript – @modelcontextprotocol/sdk
任何能够通过 STDIO 或 HTTP 使用 JSON‑RPC 的语言

文档：

下一步

在接下来的文章中，我将展示我们是如何构建内部概念验证（POC），以向同事和管理层展示这一概念的。

我必须承认，起初我感到有些畏惧（那种冒名顶替综合症永远不会真正消失），但事实证明，这并不是“添加 AI”的问题；而是让你的系统 AI‑accessible（可被 AI 使用）。

AWS Agent Core Runtime

在深入构建 MCP 服务器之前，我需要介绍使这次探索成为可能的工具：Kiro。

正如本系列标题所示，这段旅程是在会议之间 Vibecoding 完成的。没有合适的 AI 设置，就根本不可能在兼顾其他事务的同时保持动手实践。

敬请期待。

我直到自己建造一个才获得MCP

From “What’s an MCP Server?” to “I Built One”

什么是 MCP 服务器？

引发洞察的问题

想象您正在构建 AI 集成

MCP：AI 的通用适配器

USB‑C 之前

USB‑C 之后

MCP 对 AI 也实现了同样的效果

什么是 MCP 服务器？

工具太多 = 上下文过载

后果

最佳实践

TL;DR

示例配置

使用清晰的工具命名

使用资源进行惰性加载

通信模式

1. STDIO（本地进程）

2. HTTP（远程服务）

生态系统概览

构建自己的系统

下一步

AWS Agent Core Runtime

相关文章

介绍 nono：用于 AI 代理的安全沙箱

在几秒钟内切换 Claude Code 提供商，使用 claude-provider（插件 + CLI）

如何在5-10分钟内设置 OpenClaw（无需 Mac Mini、VPS、代码）

调试我的大脑：为什么拖延实际上是‘情绪调节’故障