• Example Servers

本页展示了各种模型上下文协议(MCP)服务器，这些服务器展示了该协议的功能和多样性。这些服务器使大型语言模型(LLM)能够安全地访问工具和数据源。

这些官方参考服务器展示了核心 MCP 功能和 SDK 用法：

这些 MCP 服务器由公司为其平台维护：

• Axiom - 使用自然语言查询和分析日志、跟踪和事件数据
• Browserbase - 在云中自动化浏览器交互
• Cloudflare - 在 Cloudflare 开发者平台上部署和管理资源
• E2B - 在安全云沙箱中执行代码
• Neon - 与 Neon 无服务器 Postgres 平台交互
• Obsidian Markdown Notes - 阅读和搜索 Obsidian 知识库中的 Markdown 笔记
• Qdrant - 使用 Qdrant 向量搜索引擎实现语义记忆
• Raygun - 访问崩溃报告和监控数据
• Search1API - 用于搜索、爬取和网站地图的统一 API
• Stripe - 与 Stripe API 交互
• Tinybird - 与 Tinybird 无服务器 ClickHouse 平台交互
• Weaviate - 通过 Weaviate 集合启用智能 RAG

不断增长的社区开发服务器生态系统扩展了 MCP 的功能：

Docker - 管理容器、镜像、卷和网络 Kubernetes - 管理 pod

• Exploring Generative AI

大型语言模型(LLM)的工作原理根植于模式匹配和对下一个词元的统计预测("随机鹦鹉")。从这种方法中产生的一个有些出人意料的能力是它们也能在一定程度上"推理"解决问题。有些模型的推理能力比其他模型更强，OpenAI的"o1"和"o3"模型是两个突出的推理模型，而DeepSeek的"R1"最近引起了很大轰动。但是当我们在编码任务中使用AI时，这种能力发挥什么作用呢？

剧透提醒：我还没有答案！但我有问题和想法。

我将从两个方面开始讨论，这两个方面在我的理解中是推理能力的限制，而且这些限制在编码环境中是相关的。然后我将分享我的想法，即推理在哪些编码任务中可能有用，在哪些任务中可能没用。

他们发现：

1. 姓名和数字的变化会影响模型解决问题的性能。即使推理步骤完全相同(Sophie看她的侄子变成Anita看她的孙女，或者是12个毛绒玩具而不是8个)，模型解决问题的性能也不一致，甚至比原始基准测试略有下降。

2. 当问题的难度和规模增加时，性能进一步下降。

3. 最后，他们发现在问题中添加无关信息对性能有很大的负面影响。

首先，这是一个很好的例子，说明为什么我们应该对LLM基准测试持保留态度。

在编码环境中，我发现最后一个发现特别有趣。

• Exploring Generative AI

生成式人工智能和特别是大型语言模型（LLM）已迅速进入公众意识。像许多软件开发人员一样，我对其可能性感到好奇，但不确定它最终对我们的职业意味着什么。我现在在Thoughtworks担任一个角色，协调我们关于这项技术将如何影响软件交付实践的工作。我将在这里发布各种备忘录，描述我和同事们正在学习和思考的内容。

随着智能代理编码助手变得越来越强大，反应各不相同。有些人从最近的进步推断并声称，"一年后，我们将不再需要开发人员。"其他人则对AI生成代码的质量以及为初级开发人员准备应对这一变化的挑战表示担忧。

在过去几个月中，我定期使用Cursor、Windsurf和Cline中的智能代理模式，几乎完全用于更改现有代码库（而不是从头创建井字游戏）。总体而言，我对IDE集成的最新进展以及这些集成如何极大地提升工具辅助我的方式印象深刻。它们

• 执行测试和其他开发任务，并尝试立即修复出现的错误
• 自动识别并尝试修复代码检查和编译错误
• 能够进行网络研究
• 有些甚至集成了浏览器预览功能，可以捕获控制台错误或检查DOM元素

所有这些都带来了与AI令人印象深刻的协作会话，有时帮助我在创纪录的时间内构建功能和解决问题。

然而。

即使在那些成功的会话中，我也一直在干预、纠正和引导。而且我经常决定不提交更改。

生成式AI是指能够根据提示或指令创建新内容的AI系统。这些系统被训练于大量数据，学习识别模式并生成类似于训练数据的新输出。现代生成式AI多为基于神经网络架构的深度学习系统。

目前主导生成式AI讨论的是大型语言模型（LLMs）。这些是经过大量文本训练的模型，可以生成连贯的文本，预测给定上下文中最可能的下一个词。尽管基础架构可能很复杂，但我们可以将其视为一个复杂的自动补全系统。

LLMs展现出的能力远超过以前的生成系统，它们能够：

• 以难以与人类创作区分的方式撰写文章、小说、诗歌或代码
• 回答问题、提供建议、编写报告、总结文档
• 理解上下文并保持对话连贯性
• 同时处理多种语言
• 理解代码并生成新代码

生成式AI已经在许多领域展示出其应用潜力：

开发人员正在使用生成式AI工具（如GitHub Copilot、Amazon CodeWhisperer和Google Duet AI）来加速编码过程。这些工具可以：

• 生成样板代码
• 提出完整函数和算法
• 帮助编写测试
• 解释现有代码
• 重构代码以提高质量
• 生成文档

生成式AI可以产生各种形式的内容：

• 博客文章、社交媒体更新和营销文案
• 个性化电子邮件和通信
• 产品描述和目录
• 视频脚本和广告文案

生成式AI正在改变企业与客户的互动方式：

• 聊天机器人和虚拟助手
• 智能响应建议
• 自动票务分类和路由
• 知识库生成和维护

从DALL-E到Midjourney等工具正在改变设计流程： 生成概念艺

服务器通过MCP提供了为语言模型添加上下文的基本构建块。这些原语支持客户端、服务器和语言模型之间的丰富交互：

• 提示（Prompts）：预定义的模板或指令，用于指导语言模型交互
• 资源（Resources）：为模型提供额外上下文的结构化数据或内容
• 工具（Tools）：可执行函数，允许模型执行操作或检索信息

每个原语可以在以下控制层次结构中概括：

原语	控制方	描述	示例
提示	用户控制	由用户选择调用的交互式模板	斜杠命令、菜单选项
资源	应用程序控制	由客户端附加和管理的上下文数据	文件内容、Git历史
工具	模型控制	向LLM公开以执行操作的函数	API POST请求、文件写入

模型上下文协议（MCP）提供了一种标准化方式，使服务器能够向客户端公开提示词模板。提示词允许服务器提供结构化消息和与语言模型交互的指令。客户端可以发现可用的提示词，获取其内容，并提供参数来自定义它们。

提示词设计为用户控制的，这意味着它们从服务器暴露给客户端，目的是让用户能够明确选择使用它们。

通常，提示词会通过用户界面中的用户发起命令触发，这允许用户自然地发现和调用可用的提示词。

例如，作为斜杠命令：

然而，实现者可以自由地通过任何适合其需求的界面模式来公开提示词——协议本身不强制要求任何特定的用户交互模型。

支持提示词的服务器必须在初始化期间声明prompts能力：

模型上下文协议（Model Context Protocol）由几个协同工作的关键组件组成：

• 基础协议：核心 JSON-RPC 消息类型
• 生命周期管理：连接初始化、能力协商和会话控制
• 服务器功能：服务器提供的资源、提示和工具
• 客户端功能：客户端提供的采样和根目录列表
• 实用工具：跨领域关注点，如日志记录和参数补全

所有实现必须支持基础协议和生命周期管理组件。其他组件可以根据应用程序的特定需求来实现。

这些协议层在实现客户端和服务器之间丰富交互的同时，建立了明确的关注点分离。模块化设计允许实现精确支持所需的功能。

MCP 客户端和服务器之间的所有消息必须遵循 JSON-RPC 2.0 规范。协议定义了以下类型的消息：

请求从客户端发送到服务器，或者从服务器发送到客户端，用于启动操作。

{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

• 请求必须包含字符串或整数 ID。
• 与基本 JSON-RPC 不同，ID 不得为 null。
• 请求 ID 不得在同一会话中被请求者先前使用过。

响应是对请求的回复，包含操作的结果或错误。

模型上下文协议（MCP）采用客户端-主机-服务器架构，每个主机可以运行多个客户端实例。这种架构使用户能够跨应用程序集成AI功能，同时保持明确的安全边界和关注点隔离。MCP基于JSON-RPC构建，提供专注于客户端和服务器之间上下文交换和采样协调的有状态会话协议。

graph LR
    subgraph "应用程序主机进程"
        H[主机]
        C1[客户端 1]
        C2[客户端 2]
        C3[客户端 3]
        H --> C1
        H --> C2
        H --> C3
    end

    subgraph "本地机器"
        S1[服务器 1<br>Files 和 Git]
        S2[服务器 2<br>数据库]
        R1[("本地<br>资源 A")]
// ...

主机进程作为容器和协调器：

• 创建和管理多个客户端实例
• 控制客户端连接权限和生命周期
• 执行安全策略和同意要求
• 处理用户授权决策
• 协调AI/LLM集成和采样
• 管理跨客户端的上下文聚合

每个客户端由主机创建，并维护独立的服务器连接：

• 每个服务器建立一个有状态会话
• 处理协议协商和能力交换
• 双向路由协议消息
• 管理订阅和通知
• 维护服务器之间的安全边界

主机应用程序创建和管理多个客户端，每个客户端与特定服务器保持1:1关系。

服务器提供专门的上下文和功能：

Model Context Protocol（MCP）是一个开放协议，它使 LLM 应用程序与外部数据源和工具之间能够无缝集成。无论您是构建 AI 驱动的 IDE、增强聊天界面，还是创建自定义 AI 工作流，MCP 都提供了一种标准化的方式来连接 LLM 与它们所需的上下文。

本规范基于 schema.ts 中的 TypeScript 模式，定义了权威的协议要求。

有关实现指南和示例，请访问 modelcontextprotocol.io。

MCP 为应用程序提供了标准化的方式来：

• 与语言模型共享上下文信息
• 向 AI 系统公开工具和功能
• 构建可组合的集成和工作流

该协议使用 JSON-RPC 2.0 消息在以下组件之间建立通信：

• 主机（Hosts）：发起连接的 LLM 应用程序
• 客户端（Clients）：主机应用程序内的连接器
• 服务器（Servers）：提供上下文和功能的服务

MCP 部分受到 Language Server Protocol 的启发，后者标准化了如何在整个开发工具生态系统中添加对编程语言的支持。类似地，MCP 标准化了如何将额外的上下文和工具集成到 AI 应用程序的生态系统中。

• JSON-RPC 消息格式
• 有状态连接
• 服务器和客户端能力协商

服务器向客户端提供以下任何功能：

资源（Resources）：供用户或 AI 模型使用的上下文和数据 提示（Prompts）：为用户提供的模板化

创建无需构建配置的 模型上下文协议 (MCP) 服务器项目。

# 使用 uvx (推荐)
uvx create-mcp-server

# 或者使用 pip
pip install create-mcp-server
create-mcp-server

您无需手动安装或配置任何依赖项。 该工具将设置创建 MCP 服务器所需的一切。

您需要在您的机器上安装 UV >= 0.4.10。

要创建新服务器，请运行以下任一命令：

它将引导您创建一个新的 MCP 服务器项目。 完成后，您将拥有一个具有以下结构的新目录：

my-server/
├── README.md
├── pyproject.toml
└── src/
    └── my_server/
        ├── __init__.py
        ├── __main__.py
        └── server.py

没有配置或复杂的文件夹结构，只有运行服务器所需的文件。

安装完成后，您可以启动服务器：

cd my-server
uv sync --dev --all-extras
uv run my-server

• 用于创建新项目的简单命令行界面
• 在可用时自动配置 Claude Desktop 应用程序集成
• 使用 uvx 实现快速、可靠的包管理和项目创建
• 设置基本的 MCP 服务器结构
• 使用 模型上下文协议 Python SDK 作为服务器项目

curl -LsSf https://astral.sh/uv/install.sh | sh

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

uv self update

创建/同步完整的开发环境

uv sync

执行该命令后，主要做了以下事：

1. 读取项目配置 pyproject.toml
2. 创建/激活虚拟环境 .venv
3. 安装所有依赖（含开发依赖）
4. 以可编辑模式（-e / editable）安装当前项目
5. 生成/锁定依赖版本 uv.lock

uv add "mcp[cli]"

uv remove "mcp[cli]"

uv init echo
cd echo

创建的文件：

.
├── .python-version
├── README.md
├── main.py
└── pyproject.toml

uv run main.py

Hello from echo!

• python-sdk

Model Context Protocol 允许应用程序以标准化的方式为 LLM 提供上下文，将提供上下文的关注点与实际的 LLM 交互分离开来。这个 Python SDK 实现了完整的 MCP 规范，使您能够轻松地：

• 构建可连接到任何 MCP 服务器的 MCP 客户端
• 创建暴露资源、提示和工具的 MCP 服务器
• 使用标准传输方式如 stdio 和 SSE
• 处理所有 MCP 协议消息和生命周期事件

我们推荐使用 uv 来管理您的 Python 项目。在由 uv 管理的 Python 项目中，通过以下方式将 mcp 添加到依赖项：

uv add "mcp[cli]"

或者，对于使用 pip 管理依赖的项目：

pip install mcp

要使用 uv 运行 mcp 命令：

uv run mcp

让我们创建一个简单的 MCP 服务器，它暴露一个计算器工具和一些数据：

sh ./scripts/install-dependencies.sh

• Contributing to Continue

❌ File out/node_modules/@esbuild/darwin-arm64/bin/esbuild does not exist

1. 克隆仓库：

   git clone https://github.com/ConardLi/easy-dataset.git
   cd easy-dataset

2. 安装依赖：

   npm install

3. 启动开发服务器：

   npm run build

   npm run start

4. 打开浏览器并访问 http://localhost:1717

如果你想自行构建镜像，可以使用项目根目录中的 Dockerfile：

1. 克隆仓库：

   git clone https://github.com/ConardLi/easy-dataset.git
   cd easy-dataset
   

2. 构建 Docker 镜像：

   docker build -t easy-dataset .
   

3. 运行容器：

   docker run -d -p 1717:1717 -v {YOUR_LOCAL_DB_PATH}:/app/local-db --name easy-dataset easy-dataset
   

   注意： 请将 {YOUR_LOCAL_DB_PATH} 替换为你希望存储本地数据库的实际路径。

4. 打开浏览器，访问 http://localhost:1717

模型类型	模型	评估结果
语言模型	Qwen2.5-0.5B	❌
	Qwen2.5-1.5B	✅
	Qwen2.5-7B	✅
	Qwen2.5-14B-Instruct	✅
	Qwen2.5-32B-Instruct	✅
推理模型	DeepSeek-R1-Distill-Qwen2.5-1.5B	❌
	DeepSeek-R1-Distill-Qwen2.5-7B	❌
	DeepSeek-R1-Distill-Qwen2.5-14B	✅
	DeepSeek-R1-Distill-Qwen2.5-32B	✅
	Qwen/QwQ-32B	✅
	Qwen/QwQ-32B-Preview	✅
	Qwen/QwQ-32B-AWQ	❌
代码模型	Qwen2.5-Coder-0.5B	❌
	Qwen2.5-Coder-1.5B	✅
	Qwen2.5-Coder-3B	✅

对于这样的阅读理解任务，推理模型的表现要反而不如语言模型和代码模型，通过分析发现在思考的过程可能会出错而导致答案错误。对于大参数模型，进行了量化会导致模型性能下降，如：Qwen/QwQ-32B-AWQ。

• Qwen2.5-0.5B ❌

• Qwen2.5-1.5B ✅

• Qwen2.5-7B ✅

• Qwen2.5-14B-Instruct ✅

• Qwen2.5-32B-Instruct ✅

• DeepSeek-R1-Distill-Qwen2.5-1.5B ❌

Model Context Protocol (MCP) 入门

MCP 是一个开放协议，用于标准化应用程序向 LLM 提供上下文的方式。可以将 MCP 视为 AI 应用程序的 USB-C 端口。正如 USB-C 提供了一种将设备连接到各种外围设备和配件的标准化方式一样，MCP 提供了一种将 AI 模型连接到不同数据源和工具的标准化方式。

MCP 帮助您在 LLM 之上构建代理和复杂的工作流程。LLM 经常需要与数据和工具集成，而 MCP 提供了：

• 越来越多的预构建集成，您的 LLM 可以直接插入
• 在 LLM 提供商和供应商之间切换的灵活性
• 在您的基础设施中保护数据的最佳实践

MCP 的核心遵循客户端-服务器架构，其中主机应用程序可以连接到多个服务器：

config.yaml Reference

Continue hub 助手使用 config.yaml 规范定义。本地助手也可以通过放置在全局 .continue 文件夹中的 YAML 文件 config.yaml 进行配置（Mac 上为 ~/.continue，Windows 上为 %USERPROFILE%\.continue）

:::info Config YAML 替代了 config.json。查看迁移指南。 :::

一个助手由以下部分组成：

1. 顶级属性，用于指定助手的 name、version 和 config.yaml 的 schema
2. 块列表，这些是可组合的编码助手构建块数组，可供助手使用，如模型、文档和上下文提供者。

块是编码助手的一个独立构建块，例如一个模型或一个文档来源。在 config.yaml 语法中，块包含与助手相同的顶级属性（name、version 和 schema），但在其所属的块类型下只有一个项目。

可以在 Continue hub 上找到块和助手的示例。

助手可以显式定义块（参见下面的属性），也可以导入和配置现有的 hub 块。

Hub 块和助手通过格式为 owner-slug/block-or-assistant-slug 的标识符识别，所有者可以是用户或组织。

可以通过在块类型下添加 uses 子句将块导入到助手中。

这篇文章是使用 Google Gemini Deep Research 生成的。提示词：研究 Model Context Protocol

大型语言模型 (LLMs) 在理解和生成人类语言方面取得了显著的进步。然而，这些模型本质上是孤立的，它们的知识仅限于训练数据，并且缺乏与外部世界交互的能力 1。为了克服这些限制，将 LLMs 与外部数据源和工具集成变得至关重要 1。传统上，这种集成是通过为每个新的数据源或工具开发定制的连接器来实现的 1。这种方法导致了集成工作的重复，难以扩展，并且维护成本高昂，阻碍了上下文感知 AI 的广泛采用 1。

为了应对这一挑战，模型上下文协议 (MCP) 应运而生 1。MCP 是一种开放标准，旨在规范应用程序如何向 LLMs 提供上下文和工具 6。可以将 MCP 视为 AI 应用程序的通用连接器，类似于 USB-C 标准化了设备和外设之间的连接 6。通过提供一种标准化的方式将 AI 模型连接到各种数据源和工具，MCP 简化了集成，增强了互操作性，并促进了可扩展性 6。

本报告旨在对模型上下文协议 (MCP) 进行全面的解析，涵盖其基本原理、核心架构、通信机制、广泛的应用场景以及客户端和服务器端的创建方法。通过深入理解 MCP，开发者和组织可以更好地利用这一新兴标准，构建更智能、更具上下文感知能力的 AI 应用。

MCP 的设计基于若干核心原则，这些原则共同塑造

快速链接：

• 从 GitHub 构建 MCP 服务器
• 从头开始构建自定义 MCP 服务器

本文档解释了模型上下文协议 (MCP) 服务器的功能以及 Cline 如何帮助构建和使用它们。

MCP 服务器充当大型语言模型 (LLM)（如 Claude）与外部工具或数据源之间的中介。它们是向 LLM 提供功能的小程序，使其能够通过 MCP 与外部世界交互。MCP 服务器本质上就像 LLM 可以使用的 API。

MCP 服务器定义了一组"工具"，即 LLM 可以执行的函数。这些工具提供了广泛的功能。

MCP 的工作原理：

• MCP 主机发现连接的服务器的功能并加载它们的工具、提示和资源。
• 资源提供对只读数据的一致访问，类似于文件路径或数据库查询。
• 安全性由服务器隔离凭证和敏感数据来确保。交互需要明确的用户批准。

MCP 服务器的潜力非常广阔。它们可以用于多种用途。

以下是 MCP 服务器的一些具体使用示例：

• Web 服务和 API 集成：
  • 监控 GitHub 存储库的新问题
  • 根据特定触发器发布 Twitter 更新
  • 检索基于位置的服务的实时天气数据

• 浏览器自动化：
  • 自动化 Web 应用程序测试
  • 抓取电子商务网站进行价格比较
  • 为网站监控生成截图

• 数据库查询：
  • 生成每周销售报告
  • 分析客户行为模式
  • 为业务指标创建实时仪表板

项目和任务管理： 基于代码提交自动创建 Jira 工单 生成每周进度报告 根据项