ConnectWise Manage

ConnectWise Manage MCP 服务

让你的 AI 助手直接与 ConnectWise Manage 协作。 通过自然对话而非点击 CWM 界面，搜索工单、记录工时、查找公司和联系人，以及管理项目。

这是一个 Model Context Protocol（MCP） 服务，为 Claude（或任何兼容 MCP 的 AI）提供 84 种工具，涵盖 ConnectWise Manage 服务商日常依赖的各项操作。支持云托管和可自托管的 CWM 实例，只需将其指向你的服务即可。

属于 MSP Claude Plugins 生态系统的一部分——这是一个不断发展的 AI 集成套件，面向 MSP 技术栈，包含 Autotask、Datto RMM、IT Glue、HaloPSA、NinjaOne、Huntress 等。由 MSP 为 MSP 打造。

一键部署

关于注册表身份验证的说明： 此服务仅依赖公开的 npm 软件包，因此 Cloudflare 和 DigitalOcean 云构建器会匿名安装其依赖项，一键部署无需令牌。（如果未来的版本添加了私有的 @wyre-ai/* 依赖项，则需要提供具有 read:packages 权限的 GitHub PAT 作为构建变量——Cloudflare Workers 使用 NODE_AUTH_TOKEN，DigitalOcean 使用构建时的 GITHUB_TOKEN 密钥。）

安装已发布的软件包： 已发布的软件包位于 GitHub Packages npm 注册表，每次安装都需要进行身份验证（即使是公开的软件包也一样）。要安装该软件包，请使用具有 read:packages 权限的 GitHub PAT，让 npm 向 npm.pkg.github.com 进行身份验证：

export NODE_AUTH_TOKEN=$(gh auth token)
npm install @wyre-ai/connectwise-manage-mcp

若要使用 Entra ID OAuth 2.1 部署到 Azure Container Apps，请参阅 AZURE_ACA_DEPLOYMENT.md。

配置

环境变量

变量	必需	说明
CW_MANAGE_COMPANY_ID	用于 stdio 和 AUTH_MODE=env	你的 ConnectWise 公司标识符
CW_MANAGE_PUBLIC_KEY	用于 stdio 和 AUTH_MODE=env	API 成员公钥
CW_MANAGE_PRIVATE_KEY	用于 stdio 和 AUTH_MODE=env	API 成员私钥
CW_MANAGE_CLIENT_ID	用于 stdio 和 AUTH_MODE=env	来自 ConnectWise Developer Portal 的客户端 ID
CW_MANAGE_URL	否	API 基础 URL（见下文）
CW_MANAGE_REJECT_UNAUTHORIZED	否	对于自签名证书，设为 false（默认值：true）
MCP_TRANSPORT	否	stdio（默认值）或 http
MCP_HTTP_PORT	否	HTTP 端口（默认值：8080）
MCP_HTTP_HOST	否	当 MCP_TRANSPORT=http 时的绑定地址。默认为 127.0.0.1。配置了 CONDUIT_S2S_SECRET 时会遵循此值。容器镜像将其设为 0.0.0.0。
CONDUIT_S2S_SECRET	HTTP 模式下必需	服务间密钥。如果此值为空或是已知占位符（changeme、secret、your-s2s-secret、replace-me 等），HTTP 服务会记录错误并以非零状态码退出。未设置时，Compose 不会启动。切勿提交真实值。在 .env.example 中将其留空。
MCP_ALLOW_INSECURE_DEV	否	仅用于本地开发，设为 1 后可在未设置 CONDUIT_S2S_SECRET 的情况下启动 HTTP。进程会记录警告、不强制执行 X-Gateway-S2S，并且仅监听 127.0.0.1（更宽泛的 MCP_HTTP_HOST 值会被覆盖）。仍会拒绝占位符密钥。
AUTH_MODE	否	env（默认值）或 gateway。Gateway 模式要求每个 /mcp 请求都包含 X-CW-Company-Id、X-CW-Public-Key、X-CW-Private-Key 和 X-CW-Client-Id。env 模式会在 S2S 身份验证成功后使用 CW_MANAGE_*。

/health 无需身份验证，也不会读取 ConnectWise 凭据。stdio 传输不会使用 CONDUIT_S2S_SECRET。

HTTP 身份验证

设置 MCP_TRANSPORT=http 和 CONDUIT_S2S_SECRET 后，每个 /mcp 请求都必须包含 X-Gateway-S2S。标头值为：

t=<unix seconds>,v1=<hex hmac-sha256>

v1 是以 CONDUIT_S2S_SECRET 为密钥，对 ASCII 字符串 t=<unix seconds> 计算的 HMAC-SHA256（十六进制、小写）。时间戳必须与服务器时钟相差不超过 300 秒。缺少标头或标头无效时会返回 401。进程绝不会将密钥写入日志。

X-Gateway-S2S: t=1710000000,v1=<hmac-sha256("t=1710000000")>

在 AUTH_MODE=gateway 模式下，/mcp 还要求包含 X-CW-Company-Id、X-CW-Public-Key、X-CW-Private-Key 和 X-CW-Client-Id（X-CW-URL 为可选项）。这些标头是该请求的凭据来源。缺少任何必需标头的请求都会返回 401。

当 MCP_OAUTH_ENABLED=true 时，Entra OAuth 发现路由仍可用。设置密钥后，POST /mcp 仍要求有效的 X-Gateway-S2S 标头。

API 基础 URL（CW_MANAGE_URL）

实例类型	URL
云端（北美）	https://api-na.myconnectwise.net（默认值）
云端（欧洲）	https://api-eu.myconnectwise.net
云端（澳大利亚）	https://api-au.myconnectwise.net
可自托管	https://cwm.yourcompany.com

对于自托管实例，请将 CW_MANAGE_URL 设为服务器的基础 URL。除非 URL 已包含该路径，否则服务器会自动追加 /v4_6_release/apis/3.0。

如果自托管实例使用自签名证书，还需设置 CW_MANAGE_REJECT_UNAUTHORIZED=false。

获取 API 密钥

1. 登录 ConnectWise Manage 实例
2. 前往 System > Members > API Members
3. 创建具有适当权限的新 API 成员
4. 为该成员生成 API 密钥
5. 从 ConnectWise Developer Portal 获取客户端 ID

可用工具

交互式工单卡片（MCP Apps）

在 MCP Apps 宿主（Claude Desktop/web）中，cw_get_ticket 会渲染为交互式卡片，可在卡片内通过 cw_add_ticket_note 往返添加备注；此操作始终发布仅供内部查看的备注（internalAnalysisFlag）。在其他宿主中，纯 JSON 行为保持不变。卡片默认采用中性样式，可通过注入 window.__BRAND__ 或设置 MCP_BRAND_* 环境变量（MCP_BRAND_NAME、MCP_BRAND_LOGO_URL、MCP_BRAND_PRIMARY_COLOR、MCP_BRAND_ACCENT_COLOR、MCP_BRAND_BG、MCP_BRAND_TEXT）进行品牌定制，无需重新构建。

工单

• cw_search_tickets — 按条件搜索服务工单
• cw_get_ticket — 按 ID 获取工单
• cw_get_ticket_configurations — 列出与服务工单关联的配置引用（分页）
• cw_update_ticket_configurations — 按顺序批量添加或移除工单配置关联，并报告每项操作的结果
• cw_create_ticket — 创建新的服务工单。可选的 parentTicketId（与 cw_get_ticket 返回的字段相同）可将工单创建为该父工单的子工单。
• cw_update_ticket — 更新工单（JSON Patch）
• cw_get_ticket_notes — 获取工单的所有备注（包括子工单备注）
• cw_add_ticket_note — 向工单添加备注（讨论、内部或解决方案）。除非 processNotifications 为 true，否则不会发送任何邮件。emailContactFlag、emailResourceFlag、emailCcFlag 和 emailCc 不是 ServiceNote 字段，不会发送（提交这些字段会导致 ConnectWise 返回 400）。仅当标志为 true 时，才会启用 processNotifications。收件人取自工单的 automaticEmailContactFlag、automaticEmailResourceFlag、automaticEmailCcFlag 和 automaticEmailCc。可选的 memberId 会作为 member.id 发送并设置作者；省略时，Manage 会将备注归于 API 成员。创建响应会根据已存储的备注类型返回 internalFlag / externalFlag，因此内部备注不会同时被报告为外部备注。

公司

• cw_search_companies — 搜索公司
• cw_get_company — 按 ID 获取公司
• cw_create_company — 创建新公司
• cw_update_company — 更新公司（JSON Patch）

联系人

• cw_search_contacts — 搜索联系人。使用 typeName、typeId 或 childConditions（例如 types/name = "Primary"）筛选联系人类型。在 conditions 中使用 types / types/name 无效，因为类型属于子集合，会返回 400 ApiFindCondition；该工具会将这些子句移至 childConditions。联系人使用 firstName 和 lastName，而不是 name。字符串值使用双引号（firstName = "Ada"）；也接受单引号，并会将其改写。
• cw_get_contact — 按 ID 获取联系人
• cw_create_contact — 创建新联系人。由于不同租户的通信类型名称各异，系统会从 GET /company/communicationTypes 获取电子邮件和电话类型（emailFlag / phoneFlag，每个连接缓存 10 分钟），而不是假定类型名称为 "Email" / "Direct"。可选的 emailTypeId、emailTypeName、phoneTypeId、phoneTypeName 可覆盖查找结果（ID 优先于名称；名称未知时会列出可用类型）。
• cw_list_communication_types — 列出租户的通信类型（GET /company/communicationTypes），以查找 cw_create_contact 和 cw_update_contact 所需的 ID
• cw_update_contact — 更新联系人（对 PATCH /company/contacts/{id} 执行 JSON Patch）。路径包括 firstName、lastName、title、inactiveFlag、site、communicationItems（电子邮件和电话；由于不同租户的类型名称各异，请使用来自 cw_list_communication_types 的 type: { id }）以及 customFields。此补丁不包含联系人类型。
• cw_update_contact_types — 添加或移除联系人类型，例如 "Decision Maker"（POST / DELETE /company/contacts/{id}/typeAssociations）。添加联系人已有的类型不会产生重复项。

项目

• cw_search_projects — 搜索项目
• cw_get_project — 根据 ID 获取项目
• cw_create_project — 创建新项目
• cw_search_project_tickets — 搜索项目下的工单
• cw_get_project_ticket — 根据 ID 获取特定项目工单
• cw_get_project_ticket_notes — 获取项目工单的所有备注（包括子工单备注）
• cw_add_project_ticket_note — 向项目工单添加备注（讨论、内部备注或解决方案）。不会发送电子邮件标记。可选的 memberId 用于设置作者（member.id）。

时间条目

• cw_search_time_entries — 搜索时间条目
• cw_get_time_entry — 根据 ID 获取时间条目
• cw_create_time_entry — 创建新的时间条目。ConnectWise 在创建时会忽略条目的 emailContactFlag、emailResourceFlag 和 emailCcFlag，并改为复制工单的 automaticEmail* 标记。对于服务工单和项目工单，每个保持为 false（默认值）的电子邮件标记都会在创建时关闭对应的工单标记，之后再恢复。如果切换失败，则不会创建条目。suppressTicketAutoEmail: false 会关闭该切换。请参阅备注、时间条目和客户电子邮件。
• cw_update_time_entry — 更正时间条目（对 PATCH /time/entries/{id} 使用 JSON Patch）。当计量协议将 actualHours 舍入为 0.25 时，可使用此工具进行修正。
• cw_delete_time_entry — 删除时间条目（DELETE /time/entries/{id}）。对于已开票的条目，Manage 会拒绝删除。

日程条目

• cw_search_schedule_entries — 搜索已预订的资源时间
• cw_list_schedule_types — 列出日程类型（服务、项目、销售、会议）
• cw_list_schedule_statuses — 列出日程状态（暂定、确定）
• cw_create_schedule_entry — 为工单、活动或项目工单预订资源时间
• cw_update_schedule_entry — 更新日程条目（JSON Patch）

成员

• cw_search_members — 搜索成员／技术人员
• cw_get_member — 根据 ID 获取成员

配置项

• cw_search_configurations — 搜索配置项（资产）
• cw_get_configuration — 根据 ID 获取配置项

服务参考数据

• cw_list_boards — 列出服务看板
• cw_list_priorities — 列出工单优先级
• cw_list_statuses — 列出看板的状态

活动

• cw_search_activities — 搜索活动
• cw_get_activity — 根据 ID 获取活动
• cw_create_activity — 创建新活动

协议

• cw_search_agreements — 搜索协议
• cw_get_agreement — 根据 ID 获取协议
• cw_get_agreement_additions — 获取协议的附加项（行项目）
• cw_update_agreement_addition — 使用 JSON Patch 更新附加项（数量、生效日期、取消日期、向客户开票等）；支持不会执行写入的 dryRun 预览
• cw_create_agreement_addition — 在协议上创建新的附加项
• cw_search_agreement_recaps — 搜索协议计费摘要（已用、剩余、超额、下一张发票）
• cw_get_agreement_recap — 获取单个协议的计费摘要

发票

• cw_search_invoices — 搜索发票（CW conditions、orderBy，例如 id desc）
• cw_get_invoice — 按 ID 获取发票
• cw_update_invoice — 使用 JSON Patch 更新一张发票（PATCH /finance/invoices/{id}）；返回的已更新发票与 cw_get_invoice 的结构相同。允许的路径（可省略开头的斜杠）：status/id 或 status（{ id }）、attention、dueDate、date、reference、customerPO、internalNotes、billToCompany 和 billingSite（每项都可使用 { id } 或通过 /id 指定；billToSite 可作为 Manage 中 billingSite 的别名）。Manage 发票没有 billToContact 字段——请使用 attention 填写联系人姓名。调用 Manage 前会拒绝自定义字段和付款字段。dryRun: true 会 GET 发票，在内存中应用补丁，并返回 { dryRun: true, saved: false, preview }，不执行写入。不支持批量模式——请遍历各 ID（并发数为 3–5），并逐张报告结果。请先将账单状态名称解析为 ID；切勿猜测 ID。Manage 的 400/401/403/404/409 错误会原样返回；429 会重试一次；只有当所有操作都是 replace 时，5xx 才会重试一次（包含 add 或 remove 的 PATCH 仅在 429 时重试）。要求 API 成员的角色具有 财务 › 发票：编辑 权限。

采购

• cw_search_purchase_orders — 搜索采购订单
• cw_get_purchase_order — 按 ID 获取采购订单
• cw_get_purchase_order_items — 获取采购订单中的明细项
• cw_search_procurement_products — 搜索采购产品项（添加到工单、项目、订单或商机中的 SKU）
• cw_get_procurement_product — 按 ID 获取采购产品项

销售订单

• cw_search_sales_orders — 搜索销售订单
• cw_get_sales_order — 按 ID 获取销售订单
• cw_get_sales_order_products — 获取销售订单中的产品项

商机

• cw_search_opportunities — 搜索商机
• cw_get_opportunity — 按 ID 获取商机
• cw_search_opportunity_forecasts — 搜索商机预测明细
• cw_search_opportunity_notes — 搜索商机备注
• cw_search_sales_stages — 列出销售管道阶段

目录（产品）

• cw_search_catalog_items — 搜索产品目录项
• cw_get_catalog_item — 按 ID 获取目录项
• cw_create_catalog_item — 创建新的目录项
• cw_update_catalog_item — 更新目录项（JSON Patch）
• cw_list_catalog_categories — 列出目录类别
• cw_list_catalog_subcategories — 列出目录子类别
• cw_list_manufacturers — 列出制造商

采购库存

仓库库存和库存调整。通过 API 更改现有库存数量的唯一支持方式是执行调整：先创建表头，再添加明细行，最后关闭以过账。

• cw_list_warehouses — 列出库存仓库
• cw_list_warehouse_bins — 列出仓库货位，可选指定一个仓库
• cw_get_inventory_on_hand — 报告每个货位中所有现有库存不为零的物品，包括负数，并提供单位成本和扩展价值
• cw_list_adjustment_types — 列出库存调整类型
• cw_create_adjustment — 创建调整表头（不移动库存）
• cw_add_adjustment_detail — 添加一条带符号的调整明细行，序列化物品需提供序列号
• cw_get_adjustment — 获取调整表头及其所有明细行
• cw_close_adjustment — 过账调整。除通过反向调整外，无法撤销

使用这些功能前，值得了解 ConnectWise API 的两项限制。调整没有 summary 字段：自由文本字段为 reason（最多 100 个字符）和 notes。此外，没有任何端点会公开平均成本，因此 cw_get_inventory_on_hand 报告的 unitCost 是目录项自身的 cost 字段，即当前成本，而不是 ConnectWise 用于评估库存的加权平均成本。

健康状态

• cw_test_connection — 测试连接（访问 /system/info）

备注、时间记录和客户邮件

• 由工单决定谁会收到邮件。 ConnectWise 会向工单的自动邮件标志所设置的收件人发送邮件：automaticEmailContactFlag、automaticEmailResourceFlag、automaticEmailCcFlag，以及 automaticEmailCc 中的地址。
• 工时记录。 ConnectWise 不支持针对这些邮件按记录单独覆盖设置。创建记录时，它会忽略该记录的 emailContactFlag、emailResourceFlag 和 emailCcFlag，将工单的标志复制到新记录中，并据此发送邮件。若要让某位收件人不收到邮件，cw_create_time_entry 会在创建期间暂时关闭相应的工单标志，然后再将其重新打开。只要某个记录标志为 false（默认值），而对应的工单标志为开启状态，就会执行此操作。
  • 如果无法读取工单，或无法关闭标志（例如，API 成员无权编辑工单），则不会创建工时记录。
  • 重新打开标志时会重试：最多 3 次，间隔依次为 200 ms 和 600 ms，避免 ConnectWise 的暂时性错误导致标志一直处于关闭状态。
  • 如果工时记录创建成功后所有重试都失败，结果不会标记为错误，因为记录已经存在，不能再次创建（错误结果会促使调用方重试，从而重复记录工时）。第一项内容为一条 WARNING，说明工时记录已创建并附上其 ID，之后每行列出一个仍处于关闭状态的工单标志。接下来是工时记录 JSON。最后一项为 JSON 状态块，包含 timeEntryCreated: true、timeEntryId、autoEmailRestoreFailed: true、ticketId、flagsLeftOff、restoreAttempts 和 restoreWith。在重新打开标志之前（使用 cw_update_ticket，或对项目工单使用 PATCH /project/tickets/{id}），ConnectWise 不会为该工单自动向这些收件人发送邮件。
  • 服务还会向 stderr 写入一行错误级别的 JSON 日志（"event":"cw_time_entry_auto_email_restore_failed"），其中包含工单 ID 和路径、flagsLeftOff、timeEntryCreated、timeEntryId、尝试次数、连接标识（API 基础 URL + 公司 ID），以及经过清理的 ConnectWise 错误信息（状态码和引用 ID）。日志中绝不会包含密钥或凭据。
  • 如果创建本身失败且恢复也失败，结果会报错，说明创建失败或无法确认（POST 请求可能已在出错前到达 ConnectWise，因此重试前请在 ConnectWise 中检查该记录），并列出仍处于关闭状态的标志。同时会写入相同的日志行，其中 timeEntryCreated: false 表示创建未得到确认。如果关闭标志的操作中途失败、且必须重新打开标志，也会进行相同的重试并写入日志。
  • 对同一工单的并发 cw_create_time_entry 调用会按顺序排队逐个执行（读取、切换、提交、恢复），并以 ConnectWise 连接（API 基础 URL + 公司 ID）和工单为键。**此锁仅在进程内生效：**它只涵盖同一个 stdio 服务、一个 Node HTTP 服务或一个 Worker isolate 内的并行调用；它不会协调多个副本、不同的 Worker isolate，或其他工具和人员对同一工单的编辑，因此在此期间从其他位置创建记录仍可能触发邮件。不同工单的创建仍会并行执行。如果可能同时创建同一工单的工时记录，请将 HTTP 服务作为单个副本运行（例如 Conduit 部署 sidecar 时使用的 Azure Container Apps 设置 minReplicas = maxReplicas = 1）。使用多个副本时，或在请求可能分发到不同 isolate 的 Cloudflare Workers 上运行时，对同一工单的两次创建可能交错执行：一条记录可能在另一条记录重新打开标志后才提交（该收件人会收到邮件）；或者某次调用可能将另一次调用的“关闭”状态误认为原始状态，导致标志一直处于关闭状态。
  • 在这段短暂时间内，同一工单上记录的其他工时也不会触发自动邮件。对工单执行 PATCH 还会更新工单的 lastUpdated，并可能触发工单更新工作流规则。
  • 传入 suppressTicketAutoEmail: false 可跳过切换操作，保留 ConnectWise 的默认行为。计入费用代码或活动的工时记录不会操作工单。
• 备注。 仅当备注的 processNotifications 为 true，且对应的工单自动邮件标志已开启时，工单备注才会触发邮件。除非你自行设置 processNotifications，否则传入 emailContactFlag、emailResourceFlag 或 emailCcFlag 为 true 时，cw_add_ticket_note 会设置 processNotifications。这些标志名称绝不会提交到备注本身。
• 备注不支持单独指定收件人。 ConnectWise 备注 API 无法为单条备注指定收件人或抄送地址。若要更改备注邮件的收件人，请先更改工单的自动邮件标志和 automaticEmailCc（例如使用 cw_update_ticket），再添加备注。

使用

与 Claude Desktop 搭配使用

添加到你的 claude_desktop_config.json：

{
  "mcpServers": {
    "connectwise-manage": {
      "command": "npx",
      "args": ["@wyre-ai/connectwise-manage-mcp"],
      "env": {
        "CW_MANAGE_COMPANY_ID": "your-company-id",
        "CW_MANAGE_PUBLIC_KEY": "your-public-key",
        "CW_MANAGE_PRIVATE_KEY": "your-private-key",
        "CW_MANAGE_CLIENT_ID": "your-client-id"
      }
    }
  }
}

对于可自托管的实例：

{
  "mcpServers": {
    "connectwise-manage": {
      "command": "npx",
      "args": ["@wyre-ai/connectwise-manage-mcp"],
      "env": {
        "CW_MANAGE_URL": "https://cwm.yourcompany.com",
        "CW_MANAGE_COMPANY_ID": "your-company-id",
        "CW_MANAGE_PUBLIC_KEY": "your-public-key",
        "CW_MANAGE_PRIVATE_KEY": "your-private-key",
        "CW_MANAGE_CLIENT_ID": "your-client-id",
        "CW_MANAGE_REJECT_UNAUTHORIZED": "false"
      }
    }
  }
}

使用 Docker

仓库中提供的 Compose 服务为网关模式。它不会设置 CW_MANAGE_*，也不会使用 env_file，因此项目 .env 无法向容器注入静态供应商凭据。Compose 仍会从该文件插值 CONDUIT_S2S_SECRET 和 LOG_LEVEL。镜像在容器内监听 0.0.0.0；发布的端口绑定到回环地址。

CONDUIT_S2S_SECRET="$CONDUIT_S2S_SECRET" docker compose up -d

使用 openssl rand -hex 32 生成密钥。未设置 CONDUIT_S2S_SECRET 时，Compose 会拒绝启动。每个 /mcp 请求都必须携带 X-Gateway-S2S（参见 HTTP 身份验证）以及 X-CW-* 凭据标头。

单租户 HTTP（AUTH_MODE=env）仍需要 S2S 密钥，然后使用 CW_MANAGE_*：

docker run \
  -e CONDUIT_S2S_SECRET="$CONDUIT_S2S_SECRET" \
  -e AUTH_MODE=env \
  -e CW_MANAGE_COMPANY_ID=your-company-id \
  -e CW_MANAGE_PUBLIC_KEY=your-public-key \
  -e CW_MANAGE_PRIVATE_KEY=your-private-key \
  -e CW_MANAGE_CLIENT_ID=your-client-id \
  -p 127.0.0.1:8080:8080 \
  ghcr.io/wyre-ai/connectwise-manage-mcp:latest

docker-compose.caddy.yml 是由 Caddy 代理的单租户配置。它仍需要 CONDUIT_S2S_SECRET。

HTTP 传输（网关模式）

使用 HTTP 传输运行多租户网关部署。设置 CONDUIT_S2S_SECRET 后进程才会启动：

CONDUIT_S2S_SECRET="$CONDUIT_S2S_SECRET" MCP_TRANSPORT=http AUTH_MODE=gateway node dist/index.js

每个 /mcp 请求都需要有效的 X-Gateway-S2S 标头以及 X-CW-Company-Id、X-CW-Public-Key、X-CW-Private-Key 和 X-CW-Client-Id（X-CW-URL 为可选项）。

不带密钥的本地 HTTP 仅供开发使用。它绑定到 127.0.0.1，并记录警告：

MCP_TRANSPORT=http MCP_ALLOW_INSECURE_DEV=1 npm start

开发

# Install dependencies
npm install

# Build
npm run build

# Run in development (stdio)
npm run dev

# HTTP refuses to start until CONDUIT_S2S_SECRET is set
CONDUIT_S2S_SECRET="$CONDUIT_S2S_SECRET" MCP_TRANSPORT=http npm start

# Local HTTP only, without a service-to-service secret (always binds 127.0.0.1)
MCP_TRANSPORT=http MCP_ALLOW_INSECURE_DEV=1 npm start

# Type check
npm run typecheck

# Run tests
npm test

贡献

1. Fork 此仓库
2. 创建功能分支（git checkout -b feature/amazing-feature）
3. 提交更改（git commit -m 'Add amazing feature'）
4. 推送到该分支（git push origin feature/amazing-feature）
5. 发起 Pull Request

许可证

Apache-2.0

---

由 WYRE Technology 构建 — 属于 MSP Claude Plugins 生态系统的一部分