1. 项目概述与核心价值

如果你和我一样，每天要在Azure DevOps里处理项目、工作项、拉取请求，同时又在用Claude、Cursor这类AI助手写代码、分析问题，那你肯定想过：要是能让AI直接帮我查查构建状态、创建个Bug工单，或者从代码库里找段参考代码，那该多省事。今天要聊的这个开源项目 mcp-server-azure-devops ，就是专门干这个的。它本质上是一个“翻译官”，在AI助手和Azure DevOps之间架起了一座标准化的桥梁。

简单来说，它实现了 Model Context Protocol 。你可以把它理解为一个标准化的“插件协议”，让AI助手（比如Claude Desktop、Cursor AI）能够安全、规范地调用外部工具和服务。这个项目具体做的，就是把Azure DevOps那一套复杂的REST API，封装成MCP协议里定义好的“工具”，然后暴露给AI。这样一来，你就能用自然语言直接指挥AI去操作Azure DevOps了。比如，你可以在Claude里说：“帮我看看项目‘WebApp’里最近失败的流水线有哪些”，AI就能通过这个MCP服务器去查询并给你结果。

它的核心价值在于 标准化 和 安全性 。以前你要想集成，可能得自己写一堆胶水代码，处理认证、解析API响应，还得考虑怎么把结果安全地传给AI。MCP协议把这些脏活累活都抽象掉了，你只需要关心业务逻辑。对于团队而言，这意味着可以更安全地把Azure DevOps的访问能力赋予AI，因为所有的操作都经过这个服务器，权限和审计都是可控的。对于开发者，尤其是DevOps工程师和全栈开发者，这能极大提升日常工作的效率，把一些重复性的查询、创建操作交给AI去完成。

2. 核心架构与设计思路拆解

这个项目的代码结构清晰，反映了一种非常务实的模块化设计思想。它不是把所有功能堆在一个文件里，而是按Azure DevOps的功能域进行切分，这让我们这些想借鉴或者二次开发的同行能很快理清脉络。

2.1 基于功能域的模块化架构

项目的主体结构围绕 src/features/ 目录展开。每个子目录对应一个Azure DevOps的核心概念，比如 work-items/ , repositories/ , pipelines/ 。这种划分方式非常直观，因为Azure DevOps本身的API和组织方式就是如此。当你需要新增一个关于“测试计划”的功能时，很自然地就会想到在 features 下创建一个 test-plans 目录。

在每个功能模块内部，代码通常遵循类似的模式。以 work-items 为例，你可能会看到：

  • index.ts : 模块的出口，定义了这个模块对外提供的所有MCP工具。
  • handlers/ : 存放具体处理每个工具请求的函数。比如 createWorkItem.ts , updateWorkItem.ts 。
  • types.ts : 定义这个模块专用的数据类型和接口。
  • utils.ts : 一些共享的辅助函数。

这种结构的好处是 高内聚、低耦合 。所有和工作项相关的逻辑都聚集在一起，修改和测试都变得很容易。当主服务器启动时，它会遍历 features 目录，动态地加载每个模块注册的工具。这意味着如果你想禁用一个功能，或者有条件地加载某些模块，改动会非常局部化。

2.2 认证层的抽象与灵活性

认证是任何与企业系统集成的关键，也是最容易出问题的地方。这个项目在 src/auth/ 目录下实现了认证抽象，支持多种方式，这是它设计上的一大亮点。

它没有硬编码某一种认证方式，而是定义了一个统一的 CredentialProvider 接口。具体实现有：

  • PatCredentialProvider : 使用个人访问令牌，这是最直接、兼容性最好的方式，无论是云端Azure DevOps Services还是本地部署的Azure DevOps Server都支持。
  • AzureIdentityCredentialProvider : 利用Azure Identity SDK，支持托管身份、服务主体、Azure CLI等多种现代认证方式，特别适合在Azure环境（如Azure VM、App Service、Azure Functions）中运行。
  • AzureCliCredentialProvider : 直接复用本地 az login 的登录状态，对开发者本地调试非常友好。

这种设计给了使用者极大的灵活性。比如，在本地开发时，你可以用Azure CLI方式，省去管理PAT的麻烦；在部署到生产环境的Azure虚拟机时，可以自动使用虚拟机的系统托管身份，无需存储任何密钥，安全性更高。服务器启动时会根据 AZURE_DEVOPS_AUTH_METHOD 环境变量来决定实例化哪一个Provider，整个过程对上层业务工具透明。

2.3 错误处理与用户反馈

AI助手不像人类开发者，它看不懂晦涩的HTTP状态码和堆栈跟踪。因此，如何把Azure DevOps API返回的错误，转换成对AI（以及最终用户）友好的信息，至关重要。

项目中的错误处理通常分为几个层级：

  1. 网络/客户端错误 ：比如网络超时、组织URL错误。这类错误会被捕获并包装成带有明确操作指引的提示，例如“无法连接到Azure DevOps组织，请检查 AZURE_DEVOPS_ORG_URL 配置是否正确”。
  2. API业务错误 ：比如权限不足（403）、资源不存在（404）、请求体无效（400）。处理函数会尝试从错误响应中提取关键信息（如 message 字段），并转化为如“您没有权限查看此项目”或“工作项ID 12345不存在”这样的自然语言描述。
  3. 逻辑错误 ：比如用户要求创建一个分支，但提供的源分支名不存在。这需要在调用API前就做好校验，并返回前置性的错误提示。

一个值得学习的细节是，它在返回错误时，不仅会给出友好提示，有时还会附上相关的文档链接或建议的下一步操作（比如“请确认您的PAT是否具有‘代码读写’权限”），这能极大地提升AI助手解决问题的效率。

3. 从零开始：环境配置与运行实操

光看架构不过瘾，我们动手把它跑起来。这里我会带你走一遍最常用的两种方式：用npx快速体验，以及从源码构建进行深度定制。我会把过程中容易踩的坑和注意事项都标出来。

3.1 前置准备：账号与权限

首先，你需要一个Azure DevOps组织。如果是公司使用，通常已有现成的。个人可以去 dev.azure.com 免费创建一个。

权限是关键 。你的认证凭证（无论是PAT还是Azure账号）需要在目标项目中拥有相应的权限。一个常见的误区是，只给了“读取”权限，却想让AI创建工单或分支，这肯定会失败。

实操心得 ：我建议专门为这个MCP服务器创建一个服务账户或者一个PAT。为这个PAT配置权限时，遵循最小权限原则。例如，如果只希望AI查询流水线状态和代码，就只授予“构建（读取）”和“代码（读取）”权限。如果需要创建工单，再额外加上“工作项（读写）”。在Azure DevOps的项目设置 -> “权限”页面可以精细配置。

3.2 方法一：使用npx快速运行（推荐初学者）

这是最快、最干净的方式，适合只想体验功能的用户。它直接从npm仓库下载并运行打包好的版本。 

# 只需一行命令，-y 参数表示直接同意安装
npx -y @tiberriver256/mcp-server-azure-devops

运行后，服务器会启动，但会立即报错退出，因为它缺少必要的环境变量。这是正常的。我们需要通过环境变量告诉它如何连接。

创建配置文件（以Claude Desktop为例） ： Claude Desktop的MCP服务器配置通常位于 ~/Library/Application Support/Claude/claude_desktop_config.json （Mac）或 %APPDATA%\Claude\claude_desktop_config.json （Windows）。

我们用 PAT认证 方式，因为它最通用。先到Azure DevOps生成一个PAT：组织设置 -> “个人访问令牌” -> 新建令牌。范围（Scopes）根据你需要工具的功能来选，比如“工作项（读写）”、“代码（读写）”、“构建（读取）”等。令牌生成后务必立即复制保存，因为它只显示一次。

然后编辑配置文件： 

{
  "mcpServers": {
    "azureDevOps": {
      "command": "npx",
      "args": ["-y", "@tiberriver256/mcp-server-azure-devops"],
      "env": {
        "AZURE_DEVOPS_ORG_URL": "https://dev.azure.com/你的组织名",
        "AZURE_DEVOPS_AUTH_METHOD": "pat",
        "AZURE_DEVOPS_PAT": "这里粘贴你刚才复制的PAT",
        "AZURE_DEVOPS_DEFAULT_PROJECT": "你的默认项目名",
        "LOG_LEVEL": "info"
      }
    }
  }
}

保存配置，重启Claude Desktop。在聊天窗口输入 /mcp 应该能看到 azureDevOps 服务器已连接，并列出所有可用的工具。

注意事项 ： AZURE_DEVOPS_DEFAULT_PROJECT 不是必填项，但强烈建议设置。它为那些需要项目上下文的工具（如 list_repositories ）提供了一个默认值。否则，每次调用这类工具时，你都需要在对话中明确指定项目名，比较繁琐。

3.3 方法二：从源码运行与开发

如果你想研究代码、添加自定义工具，或者需要修改现有逻辑，就需要克隆源码。 

# 克隆项目
git clone https://github.com/tiberriver256/mcp-server-azure-devops.git
cd mcp-server-azure-devops

# 安装依赖
npm ci  # 推荐用 ci 而不是 install，它能确保依赖版本与 lock 文件完全一致

# 复制环境变量模板并编辑
cp .env.example .env

用编辑器打开 .env 文件，内容如下，需要你填充： 

# 认证方式：pat, azure-identity, azure-cli
AZURE_DEVOPS_AUTH_METHOD=pat

# 你的 Azure DevOps 组织 URL
AZURE_DEVOPS_ORG_URL=https://dev.azure.com/你的组织名

# 如果使用 PAT 认证，在此填写
AZURE_DEVOPS_PAT=你的PAT

# （可选）默认项目，简化工具调用
AZURE_DEVOPS_DEFAULT_PROJECT=你的项目名

# （可选）日志级别：debug, info, warn, error
LOG_LEVEL=info

然后编译并运行： 

npm run build   # 将TypeScript编译为JavaScript
npm start       # 运行 dist/index.js

如果你在开发调试阶段，希望代码修改后能热重载，可以使用： 

npm run dev     # 使用 ts-node-dev 运行 src/index.ts，支持文件监听和重启

开发模式下的配置 ：在开发时，你可能不想修改Claude Desktop的全局配置。一个技巧是，在项目根目录创建一个 claude-dev-config.json ，然后在启动Claude Desktop时通过命令行参数指定配置文件路径（如果Claude Desktop支持的话）。或者，更简单的方法是，直接运行 npm start 或 npm run dev 启动MCP服务器，它会作为一个独立的进程运行在本地某个端口（默认可能是3000）。然后，你可以在Claude Desktop的配置中，将 command 改为 node ， args 指向你编译好的 dist/index.js 的绝对路径，并设置好工作目录和环境变量。这样更灵活。

4. 核心工具详解与使用场景

这个服务器提供了二十多个工具，覆盖了Azure DevOps的主要功能。我们挑几个最常用、也最能体现价值的工具，深入看看它们怎么用，以及背后有哪些门道。

4.1 工作项管理：让AI成为你的项目助理

工作项是项目管理的核心。 create_work_item , update_work_item , list_work_items 这几个工具，能让AI帮你处理大量琐碎的事务。

场景 ：你在代码审查时发现一个Bug，可以直接对AI说：“在‘Backend’项目里创建一个Bug类型的工作项，标题是‘用户登录API在输入超长字符串时返回500错误’，分配给张三，描述里附上这段错误日志【粘贴日志】，并关联到用户故事US-456。”

AI在背后会调用 create_work_item 工具，传入类似以下的参数（实际以AI理解的自然语言为准）： 

{
  "project": "Backend",
  "type": "Bug",
  "title": "用户登录API在输入超长字符串时返回500错误",
  "assignedTo": "张三@company.com",
  "description": "错误日志：...",
  "fields": {
    "System.Tags": "bug, api",
    "Microsoft.VSTS.Common.Priority": "2"
  },
  "links": [
    {
      "rel": "System.LinkTypes.Hierarchy-Reverse",
      "url": "https://dev.azure.com/.../_apis/wit/workItems/456",
      "attributes": { "comment": "在实现此用户故事时发现的Bug" }
    }
  ]
}

实操心得 ： fields 参数是个强大但容易出错的地方。不同项目、不同工作项类型（如Agile的Bug和CMMI的Bug）的字段名和允许值可能不同。最稳妥的方式是，先用 get_work_item 工具获取一个已有同类型工作项的完整数据，看看它的字段结构，或者让AI调用 get_project_details 工具来查询项目支持的字段。直接硬编码字段名可能会导致创建失败。

update_work_item 工具同样强大，支持使用JSON Patch格式进行精细化的更新。比如，你可以让AI：“把Bug 12345的状态改成‘进行中’，添加一条评论‘正在调查’，并把优先级提高到1。”

4.2 代码仓库操作：智能代码导航与修改

get_file_content 和 get_repository_tree 是AI理解代码库的“眼睛”。 create_commit 则是让AI进行简单代码修改的“手”。

场景 ：你记不清某个工具函数的实现细节，可以问AI：“在‘WebApp’项目的‘main’仓库里，帮我看看 src/utils/validation.js 这个文件里 validateEmail 函数是怎么实现的。” AI通过 get_file_content 获取文件内容给你看。

更进一步，你可以让AI进行简单的、模式化的修改：“在同一个文件里，找到所有 console.log(‘debug:’ 开头的语句，把它们都注释掉。” AI可以结合 get_file_content 获取内容，分析后，使用 create_commit 工具，以“搜索替换”的模式提交更改。

create_commit 工具支持两种模式：

  1. 统一差异模式 ：提供完整的diff文本。这要求AI能生成准确的diff格式，适合复杂的修改。
  2. 搜索替换模式 ：提供搜索字符串和替换字符串。这更简单直接，适合全局性的、模式固定的修改。

注意事项 ：让AI直接提交代码需要非常谨慎。务必在非关键分支（如feature分支）上操作，并且提交后一定要进行人工审查。 create_commit 工具本身不会自动创建拉取请求，这给了你一个安全缓冲。最佳实践是，让AI在feature分支上修改并提交，然后你再手动（或让AI调用 create_pull_request 工具）创建PR，经过CI流水线检查和人工评审后合并。

4.3 流水线洞察：构建状态一目了然

对于DevOps工程师， list_pipeline_runs , get_pipeline_run , get_pipeline_log 这几个工具是日常监控的利器。

场景 ：早上上班，你想快速了解昨晚的构建情况。可以直接问AI：“列出‘Production-Deploy’流水线最近5次运行的状态和触发原因。” AI调用 list_pipeline_runs ，返回一个清晰的列表，包括运行ID、状态（成功/失败/进行中）、触发者、提交信息等。

如果发现某次运行失败了，你可以继续追问：“获取第12345次运行失败的详细日志，看看错误是什么。” AI会先调用 get_pipeline_run 获取运行概览和构件信息，然后可能调用 get_pipeline_log 获取特定失败任务的日志内容。

trigger_pipeline 工具则允许你通过AI手动触发一次构建，并传入参数。比如：“用参数 DEPLOY_ENV=staging 和 SKIP_TESTS=false 触发‘Nightly-Build’流水线。”

避坑技巧 ：流水线日志可能非常庞大。直接让AI获取全部日志可能会超出上下文限制或导致响应缓慢。 get_pipeline_log 工具通常支持分页或指定行数范围。更好的做法是，先让AI调用 pipeline_timeline 工具，获取失败任务（Job）或步骤（Step）的精确标识符，然后只获取那个特定任务的日志，这样更高效。

4.4 搜索工具：跨越仓库与维基的知识查找

search_code , search_wiki , search_work_items 这三个搜索工具，将Azure DevOps强大的搜索能力赋予了AI。

场景 ：团队新成员想知道如何处理“数据库连接超时”错误。你可以让AI：“在‘Platform’项目的所有代码仓库里，搜索‘connection timeout’这个字符串，看看其他服务是怎么处理的。” AI调用 search_code ，返回包含该字符串的文件列表和片段。

或者，你想查找某个架构决策记录：“在项目维基里搜索‘ADR’和‘消息队列选型’相关的页面。” AI通过 search_wiki 工具来完成。

这些搜索工具的强大之处在于，AI可以将多个搜索结果进行综合、去重和总结，给你一个更全面的答案，而不是简单的链接列表。

5. 高级配置与安全最佳实践

把服务器跑起来只是第一步，要在生产环境或团队中可靠、安全地使用，还需要一些额外的考量。

5.1 认证方案选型深度分析

前面提到了三种认证方式，这里详细对比一下它们的适用场景和注意事项：

认证方式 优点 缺点 最佳适用场景
PAT 1. 简单直接，易于配置。
2. 兼容Azure DevOps Services和Server。
3. 权限可精细控制。 		1. PAT是长期凭证，有泄露风险。
2. 需要手动管理（创建、轮换、吊销）。
3. 无法利用Azure AD的集中身份管理。 		1. 本地开发测试。
2. 非Azure环境部署。
3. 访问本地Azure DevOps Server。
Azure Identity 1. 无需管理密钥（使用托管身份时）。
2. 支持自动凭证轮换。
3. 与Azure生态系统集成好，可利用Azure Policy进行管控。 		1. 仅适用于Azure DevOps Services。
2. 在非Azure环境配置稍复杂（需服务主体）。
3. 权限控制依赖于Azure AD应用注册的API权限。 		1. 部署在Azure资源上（VM, App Service, AKS）。
2. 需要高安全性和自动化凭证管理的生产环境。
Azure CLI 1. 对开发者最友好，复用本地登录状态。
2. 无需处理任何令牌。 		1. 仅适用于交互式开发环境。
2. 依赖本地 az 登录状态，不适合后台服务。
3. 权限是用户级别的，可能过大。 		仅限 开发者本地机器上的调试和体验。

安全建议 ：

  • 绝不 将PAT等敏感信息硬编码在代码或配置文件中提交到代码仓库。务必使用 .env 文件或安全的密钥管理服务（如Azure Key Vault）。
  • 为PAT设置最短的有效期（如30天），并建立定期轮换机制。
  • 使用Azure Identity的托管身份时，确保运行服务器的Azure资源（如VM）本身具有访问Azure DevOps所需的最小权限。
  • 可以考虑在MCP服务器前增加一个简单的反向代理（如Nginx），进行IP白名单限制、速率限制和基础认证，增加一层防护。

5.2 环境变量与配置管理

除了认证相关的变量，还有一些配置项值得关注：

  • LOG_LEVEL : 生产环境建议设为 warn 或 error ，减少日志输出。调试问题时可以临时改为 debug ，会打印出详细的请求和响应信息，对于排查认证失败或API调用错误非常有用。
  • AZURE_DEVOPS_API_VERSION : 通常不需要设置，使用默认的最新版本即可。但在某些情况下，如果你的Azure DevOps Server版本较老，或者某个API行为在新版本有变化，你可以通过此变量锁定一个特定的API版本以保证兼容性。
  • 默认项目的作用域 ： AZURE_DEVOPS_DEFAULT_PROJECT 为工具调用提供了便利，但要注意，当AI在对话中明确指定了另一个项目时，应以AI指定的为准。这个默认值只是一个后备选项。

5.3 与不同AI客户端的集成细节

这个MCP服务器遵循标准协议，理论上可以接入任何支持MCP的客户端。除了Claude Desktop和Cursor AI，像Windsurf、Continue等编辑器插件也可能支持。

配置文件的细微差别 ：

  • Claude Desktop : 配置文件路径固定，格式如前所述。
  • Cursor AI : Cursor的MCP配置可能在其设置界面完成，或者也需要一个类似的JSON配置文件，具体位置需查阅Cursor文档。原理是相通的。
  • 作为独立服务器 ：你也可以不通过这些桌面客户端，而是自己写一个脚本，通过标准输入输出（stdio）或HTTP与这个MCP服务器通信。这对于构建自定义的AI工作流或集成到其他系统中非常有用。项目源码中的 index.ts 就是启动stdio服务器的入口。

实操心得 ：在配置多个MCP服务器时，注意给每个服务器起一个独特的键名（如上面配置中的 "azureDevOps" ）。这样在AI助手的界面里，你能清晰地区分不同来源的工具。如果遇到连接问题，首先检查客户端的日志文件（Claude Desktop有日志输出），通常会有连接失败的具体原因，比如命令路径错误、环境变量未找到等。

6. 常见问题排查与调试技巧

即使配置正确，在实际使用中也可能遇到各种问题。这里记录了一些我踩过的坑和解决方法。

6.1 认证与连接类问题

问题1：服务器启动失败，提示“Invalid authentication method”或“Missing required environment variable”。

  • 排查 ：检查 .env 文件或客户端配置中的 AZURE_DEVOPS_AUTH_METHOD 值。它必须是 pat , azure-identity , azure-cli 中的一个（大小写不敏感）。确保 AZURE_DEVOPS_ORG_URL 已设置且格式正确（以 https:// 开头）。
  • 解决 ：修正环境变量值。对于URL，确保它指向组织根目录（如 https://dev.azure.com/yourorg ）或集合根目录（本地TFS，如 https://tfs-server:8080/tfs/DefaultCollection ）。

问题2：使用PAT认证，但AI调用工具时返回“401 Unauthorized”。

  • 排查 ：
    1. PAT是否已过期？去Azure DevOps重新生成一个。
    2. PAT的权限范围（Scopes）是否足够？比如，调用 create_work_item 需要 Work Items (read & write) 范围。调用 get_file_content 需要 Code (read) 。
    3. 本地环境变量 AZURE_DEVOPS_PAT 的值是否正确？是否有特殊字符需要转义？在终端执行 echo $AZURE_DEVOPS_PAT （Linux/Mac）或 echo %AZURE_DEVOPS_PAT% （Windows）检查，注意是否包含多余空格或换行。
  • 解决 ：在Azure DevOps中，为PAT勾选所有需要用到的权限范围。更新环境变量，并重启MCP服务器和AI客户端。

问题3：使用Azure CLI认证，提示“CredentialUnavailableError: Azure CLI not installed”或登录无效。

  • 排查 ：
    1. 本地是否安装了Azure CLI？运行 az --version 确认。
    2. 是否已登录？运行 az account show ，如果未登录，运行 az login 。
    3. 登录的账号是否有权访问目标Azure DevOps组织？Azure DevOps的访问依赖于Azure AD，请确保登录的AAD账号是该组织的成员。
  • 解决 ：完成Azure CLI安装和登录。如果组织使用不同的AAD租户，可能需要使用 az login --tenant <tenant-id> 。

6.2 工具调用与API类问题

问题4：AI调用 list_projects 成功，但调用 list_repositories 失败，提示“项目未找到”或“403”。

  • 排查 ：检查调用 list_repositories 时是否传入了 project 参数。如果没有，服务器会使用 AZURE_DEVOPS_DEFAULT_PROJECT 。请确认该默认项目名拼写完全正确（大小写敏感）。此外，确认你的PAT或账号在该项目中有“读取”仓库的权限。
  • 解决 ：明确指定项目参数，或确保默认项目配置正确。在Azure DevOps中检查用户或服务主体在项目中的权限。

问题5： create_work_item 失败，提示“字段‘System.AssignedTo’的值‘某某某’无效”。

  • 排查 ：Azure DevOps工作项的“分配给”字段，需要的是用户的唯一标识，通常是用户的邮件地址或“显示名 <邮件地址>”的格式。直接输入中文名或英文名可能无法识别。
  • 解决 ：让AI先调用 get_work_item 获取一个已有工作项，看看其中的 System.AssignedTo 字段是什么格式。或者，使用用户的Principal Name（UPN），即邮箱地址，最为稳妥。

问题6： get_file_content 获取大文件时超时或返回不完整。

  • 排查 ：Azure DevOps API对单个文件大小可能有默认限制，或者MCP服务器/客户端有超时设置。
  • 解决 ：对于非常大的文件（如数MB的日志文件），这不是一个合适的查看方式。考虑让AI通过 search_code 搜索关键片段，或者直接去Azure DevOps门户查看。如果是文本文件但稍大，可以尝试让AI分多次获取（如果工具支持指定行范围）。

6.3 性能与日志调试

问题7：AI助手响应慢，尤其是执行搜索或列出大量数据时。

  • 排查 ：这可能是因为查询范围太大。例如， search_code 跨所有仓库、所有分支搜索一个通用词汇，会非常耗时。
  • 解决 ：让AI使用更精确的搜索词，并利用工具提供的筛选参数，如 repository （指定仓库）、 path （指定路径）来缩小范围。对于 list_work_items ，使用Wiql查询语句进行过滤，而不是获取全部。

问题8：如何查看详细的运行日志以定位问题？

  • 解决 ：将 LOG_LEVEL 环境变量设置为 debug 。这会让MCP服务器在控制台打印出详细的HTTP请求和响应信息，包括请求的URL、头部、响应状态码和体（可能被截断）。这对于开发者调试自定义工具或排查复杂的API交互问题至关重要。 注意 ：调试完成后，在生产环境请改回 info 或 warn ，避免日志泛滥和潜在的信息泄露。

7. 扩展思路：定制化与二次开发

这个项目的模块化设计让它非常易于扩展。假设你的团队在使用Azure DevOps Test Plans，而官方工具集尚未支持，你可以自己添加。

步骤大致如下 ：

  1. 创建新功能模块 ：在 src/features/ 目录下创建 test-plans/ 文件夹。
  2. 实现工具函数 ：在模块内创建 handlers/ ，实现具体的工具，例如 getTestPlan.ts , createTestRun.ts 。这些函数需要调用Azure DevOps的Test API。
  3. 注册工具 ：在模块的 index.ts 中，使用MCP SDK提供的 server.tool() 方法，定义工具的名称、描述、输入参数schema，并绑定到刚才实现的处理函数。
  4. 集成到主服务器 ：确保主服务器文件（如 src/index.ts ）能够自动发现并加载你这个新模块。现有的架构通常已经做好了动态加载。
  5. 测试 ：重新构建并运行服务器，在AI客户端中刷新MCP服务器列表，你应该能看到新添加的工具。

更高级的定制 ：你还可以修改现有工具的行为。比如，默认的 create_work_item 可能只支持部分字段。你可以修改其处理函数，添加对你们团队自定义字段的校验和填充逻辑。或者，在 get_pipeline_run 返回的数据中，加入你们内部监控系统的链接。

这个项目提供了一个坚实的基础框架，而真正的力量在于你如何根据自己团队的工作流来定制它，让AI助手真正成为提升DevOps效率的得力伙伴。

Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区