mcp-pulse

mcpcost

这个 MCP 服务是否正常运行？它会占用多少上下文窗口？

实时面板：mcpcost.ulehla.dev

mcpcost 会探测 官方 MCP 注册表中的每个远程服务，并为每个服务记录：

• 是否响应 initialize 和 tools/list，以及响应速度
• 它协商的协议版本
• 是否需要身份验证、使用哪种方案（来自 WWW-Authenticate），以及客户端如何连接：使用动态客户端注册的 OAuth、使用发布者提供的客户端 ID 进行 OAuth，或使用密钥（从服务的公开 OAuth 元数据中读取）
• 是否要求付费（HTTP 402）
• 拥有多少个工具，以及这些工具定义需要多少令牌

mcpcost：你自己的服务需要多少令牌？

npx mcpcost                     # reads Claude Code, Claude Desktop, Cursor, VS Code, Windsurf and Gemini CLI configs
npx mcpcost --config .mcp.json  # one file
npx mcpcost --budget 30000      # exit 1 when the total is above the budget, for CI
npx mcpcost --claude            # exact counts from the Anthropic count_tokens endpoint (free, needs ANTHROPIC_API_KEY)
npx mcpcost mcp                 # the same measurements as an MCP server over stdio, for your agent

它会按照客户端的启动方式启动每个已配置的服务，列出工具，并打印每个服务及所有服务的令牌开销。请参阅 packages/mcpcost。

需要身份验证的服务

返回 401 的服务可以连接，但在提供凭据之前不会进行测量。只需保存一次凭据；之后每次测量该 URL 时都会使用这些凭据。

npx mcpcost auth https://mcp.linear.app/mcp                                   # OAuth: register, consent in the browser, store the tokens
npx mcpcost auth https://api.githubcopilot.com/mcp/ --header "Authorization: Bearer ghp_…"   # an API key instead
npx mcpcost auth --list                                                       # what is stored, without the secrets

OAuth 流程遵循 MCP 授权规范：发现、动态客户端注册、PKCE，以及在 127.0.0.1 上设置回调。只有同意屏幕这一步需要人工操作。之后，令牌会保存在 ~/.mcpcost/credentials.json（权限模式为 0600，或保存到 $MCPCOST_CREDENTIALS）；npx mcpcost 会为该 URL 发送令牌，刷新后的令牌也会写回文件。

面板也采用相同方式：npm run credentials:push 会将文件复制到 D1 表 credentials；每日运行会在探测前读取凭据，之后写回刷新后的令牌，并将服务标记为“使用凭据测量”。如果服务撤销或令刷新令牌过期，则需要再次执行同意步骤。

没有凭据时，面板仍会显示许多受限服务的工具集：工具定义不依赖令牌，因此，当发布者的代码库在 npm 或 PyPI 上保存了相关包时，probe/derive-packages.ts 会找到该包，并由每周运行的容器使用占位值进行测量。服务页面随后会注明“来自发布者的软件包”。probe/derived-aliases.json 会映射少数注册表条目中未注明代码库的服务。

在 CI 中作为 GitHub Action 使用

- uses: ondraulehla/mcpcost@v1
  with:
    config: .mcp.json   # one or more config files, one per line
    budget: 30000       # fail when the tool definitions cost more than this

作业摘要会生成一个表格，列出每个服务、测量结果和令牌开销，以及开销最高的工具。新增一个需要 40 000 个令牌的服务时，拉取请求检查会失败。设置 claude: true 并在 env 中配置 ANTHROPIC_API_KEY，即可通过免费的 count_tokens 端点获取精确计数；默认使用 o200k_base 估算。输出：tokens、servers、over-budget。

在拉取请求中，此 Action 还会测量基准分支上的相同配置文件，并发布一条评论，说明两者差异：新增、移除和变更的服务、每个服务的令牌变化、新的总量以及预算判定。每次推送都会更新评论，不会重复发布。作业需要 pull-requests: write 权限；如果没有该权限，此步骤会发出警告，但检查仍会运行。设置 comment: false 可关闭此功能。完整工作流见 .github/examples/mcp-budget.yml。

在 Claude Code 中作为插件使用

在 Claude Code 会话中：

/plugin install mcpcost --marketplace ondraulehla/mcpcost

也可以在 Shell 中运行：claude plugin marketplace add ondraulehla/mcpcost，然后运行 claude plugin install mcpcost@mcpcost。

该插件会添加一个技能 /mcpcost:measure，用于对配置运行 npx mcpcost 并读取结果；还会添加看板的 MCP 服务，这样 Claude 就能在服务器加入配置前查询或探测它。插件本身的开销：上下文中会包含一段技能描述，以及 4 个由 Claude Code 延后到工具搜索中的工具。

看板

mcpcost.ulehla.dev 从 D1 数据库在边缘渲染，并每晚刷新。它加载的脚本只有主题切换脚本和 Cloudflare Web Analytics 信标；后者无需 Cookie 即可统计页面浏览量。

• 概览：有响应的服务器占比、令牌成本百分位数，以及用于检查任意服务器的表单
• 检查：实时探测一个 URL，步骤与每日运行相同；精确令牌数在浏览器中计算
• 统计：按原因划分的结果、令牌成本和工具数量的百分位数、工具集开销最大的服务器、协议版本、身份验证方案、传输方式、最大的发布者
• 服务器：按名称、标题、描述和主机进行全文搜索（匹配词语前缀，因此 git copilot 可以找到 GitHub Copilot 服务器）；可按结果、协议和传输方式筛选，提供 7 种排序方式，且每个筛选条件都是可分享的普通 URL
• 服务器页面：状态、延迟、协议、功能、开销最大的工具、工具集相同的服务器、历史记录、徽章和电子邮件提醒：服务器停止响应、恢复响应，或其工具集或令牌成本发生变化时发送邮件
• 比较：并排比较 2 到 5 个服务器，包括状态、访问权限、工具、精确令牌数、占 200k 上下文窗口的比例、延迟、成本最低的服务器及差值；使用 /compare?s=<name>&s=<name>，每个服务器页面都提供此链接
• 跟踪：不在注册表中的服务器可以从检查页面添加跟踪；每日探测会以 url/<host>/<path> 为名称测量它
• 主机：列出规模最大的 500 个发布者，以及它们实际提供的不同工具集数量
• 报告：每月发布一期 MCP 注册表现状，根据每日运行结果编写，并提供包含所有服务器数据的 CC BY 4.0 数据集

面向 Agent 和脚本

• JSON：/api/s/<name>.json、/api/lookup.json?url=…（看板中某个端点 URL 对应的行，不进行探测）、/api/servers.json?q=…&status=ok&sort=tokens、/api/check.json?url=…、/api/summary.json。列表 API 对来自同一地址的请求限流：10 秒内最多 6 次；响应会缓存 3 小时。
• 为注册表重新检查证据，获取最新一次运行的数据：/data/mcpcost-evidence-latest.json.gz（行结构与 modelcontextprotocol/registry#1715 相同，每次每日运行后更新），索引文件为 /data/mcpcost-evidence-latest.index.json。
• 通过 Streamable HTTP 提供 MCP 服务，无需身份验证：https://mcpcost.ulehla.dev/mcp，包含工具 lookup_server、search_servers、compare_servers、check_server、registry_summary。注册表的清单位于 site/server.json。
• /llms.txt 列出了所有内容。/tokens 回答了一个常见问题：一个 MCP 服务会占用多少上下文令牌。

看板上的每个服务器都有自己的页面和徽章：

[![mcpcost](https://mcpcost.ulehla.dev/badge/io.github.you/your-server.svg)](https://mcpcost.ulehla.dev/s/io.github.you/your-server)

首次完整运行，2026-10-03

注册表中有 38 942 条最新条目。其中 24 294 条有远程端点，探测在 40 分钟内连接了所有端点。

结果	服务	占比
在线：initialize 和 tools/list 成功	12 975	53 %
需要身份验证（401、403）	5 836	24 %
不是 MCP：HTTP 200，但没有有效的 MCP 回复	1 800	7 %
未找到（404、405、410）	881	4 %
无 DNS	728	3 %
受速率限制（429）	500	2 %
需要付费（402）	434	2 %
服务错误（5xx）	349	1 %
其他	307	1 %
TLS 错误	259	1 %
超时	204	1 %
连接被拒绝	21	0 %

在作出响应的 12 975 个服务中：

• 工具集的中位数耗费 1 727 个令牌，90 百分位数为 7 429，99 百分位数为 28 200
• 208 个服务耗费超过 20 000 个令牌，46 个超过 50 000 个，3 个超过整个 200k 上下文窗口
• 耗费最多的是 com.replynodes/mcp：66 个工具，431 925 个令牌
• 服务的工具数量中位数为 8，最多为 1 385
• initialize 延迟中位数为 455 ms，90 百分位数为 1.5 s
• 60 % 协商使用协议 2025-11-25，24 % 仍使用 2025-03-26，4 % 使用 2024-11-05
• 122 个服务使用协议 2026-07-28 响应，而当前的 TypeScript SDK 会拒绝该协议

注册表中的条目分布不均。在 16 534 个主机中，16 161 个只发布一个服务。有五个主机合计发布了超过 6 000 条目：一个 Workers 子域名有 2 365 条几乎相同的条目；一个网关有 1 716 条目，其中 1 321 条在 initialize 时返回 JSON-RPC 错误；还有一个主机有 276 条目，全部返回 402。

月度报告和数据集

/report/2026-10 是 MCP 注册表现状，2026 年 10 月：注册表的各项数据、从首次完整运行到 2026-10-24 这次运行期间发生的变化、令牌成本、身份验证、数据分布、协议版本、注册表无法捕获的内容，以及用六句话说明的方法。该页面只读取 runs 表（当月截至运行日的各次运行，一次查询），并缓存一天，因此在免费套餐中不产生费用。/report 列出各月份；site/src/lib/reports.ts 中每份报告都有一条记录，标明其固定对应的运行日期。与之配套的数据集 data/mcpcost-2026-10.json.gz 位于网站上，每个经过探测的服务占一行，包含名称、主机、传输方式、状态、HTTP 状态、身份验证方案和类型、协议版本、工具数量、o200k 估算值、Claude 的精确计数，以及探测时间。某一行的数据，就是该服务器当天的 /api/s/<name>.json 返回内容。许可协议为 CC BY 4.0；文档顶部注明了许可协议、字段列表和引用方式。probe/dataset.ts 在每天运行时都会写入 data/latest/dataset.json 及其 gzip 文件（保存在运行产物中）；当 gzip 文件小于 10 MB 时，--publish site/public/data/mcpcost-YYYY-MM.json.gz 会将其复制到网站：静态文件优先于 Worker 提供，无需消耗请求额度。更大的文件则会作为 GitHub release 资源发布。发布一个月份的报告：运行探测或将运行产物下载到 data/latest，运行 node --import tsx probe/dataset.ts --publish site/public/data/mcpcost-YYYY-MM.json.gz，将该月份添加到 reports.ts，编写页面，并将文件一并提交。

同一次运行还会生成注册表复核证据，采用 modelcontextprotocol/registry#1715 中约定的行格式：entry、checked_at、check（端点或软件包）、state（alive、auth、transient、dead、unknown）和 evidence。probe/dataset.ts 每天都会将其与数据集一同写入，当月副本位于 /data/mcpcost-evidence-YYYY-MM.json.gz。最新运行始终位于 /data/mcpcost-evidence-latest.json.gz，旁边还有 /data/mcpcost-evidence-latest.index.json（运行日期、按状态和检查类型划分的条目数、大小、SHA-256、格式）。这两个文件都不在 git 中。探测流程会将文件作为产物 evidence-<run id> 保存，而 deploy.yml 会在每次构建前将其放入 site/public/data：每次探测成功后都会执行，并且每次推送时也会执行，因此推送不会导致文件从网站上消失。probe/evidence-latest.ts 会拒绝不完整的文件，此时网站会保留已有文件。探测运行后进行的部署会按当前状态构建 main，与手动部署相同；它属于单独的工作流运行，因此不会导致探测失败。

工作原理

registry ──▶ probe/run.ts ──▶ data/raw/probe-run.json
                                   │
                        probe/build-data.ts
                                   │
               data/latest/{servers,summary,hosts}.json
                                   │
                           probe/to-sql.ts ──▶ import.sql ──▶ D1
                                                                │
                              site/ (Astro on Workers) ◀────────┘

• packages/mcpcost/ 库和 CLI mcpcost：注册表客户端、远程和 stdio 探测、配置发现、令牌计数
• probe/ 批量运行器和数据管道
• site/ 看板：使用 Cloudflare adapter 部署在 Workers 上的 Astro 7，从 D1 渲染，使用 FTS5 搜索、SVG 徽章；除主题切换和分析信标外，不含客户端 JavaScript
• .github/workflows/probe.yml 每天运行整个管道：探测、计数、build-data、to-sql、导入 D1。运行生成的 summary.json、servers.json 和 hosts.json 会作为工作流产物上传；下次运行会与之比较，只导入发生变化的行，每天写入行数不超过免费套餐的 100 000 行
• .github/workflows/deploy.yml 在 site/ 发生变化时部署网站

方法

• 传输方式。 探测器使用官方 TypeScript SDK 作为客户端。优先使用 Streamable HTTP；只有远程端点仅支持 SSE 时才使用 SSE。
• 不建立 GET 流。 探测器会对 SDK 的独立 GET 请求返回 405，因此不会打开服务器到客户端的流。探测器不需要服务器主动发送消息，而且有些服务器会在该流打开时卡住 tools/list（DeepWiki 曾将其挂起 15 s，同时一直没有响应 POST）。
• 精确 Token 数量。 每日运行时，探测器会对每个正常运行的服务器调用 Anthropic 的 count_tokens 端点；设置了 GEMINI_API_KEY 时，也会调用 Gemini 的 countTokens 端点（CLI 参数：--gemini）。先调用 Anthropic：一次请求包含服务器的工具和一个标记工具，另一次请求仅包含标记工具；两次结果的差值就是这些工具在 claude-opus-5-5 中占用的 Token 数量。第二次统计会在每个工具名称前加上 Claude Code 的 mcp__<server>__ 前缀。该端点免费，且不会调用模型。只有工具定义发生变化时，才会再次统计该服务器。约 5 % 的服务器发布的 schema 会被该端点拒绝；页面会显示估算值及原因。
• 估算值。 每个工具都会序列化为包含 name、description 和 input_schema 的紧凑 JSON，并使用 o200k_base 分词器进行统计。在中位数情况下，精确统计值约为估算值的 1.9 倍。估算无需密钥，且对所有服务器使用相同的方法。
• 相同工具集。 对排序后的工具名称和 schema 大小进行哈希，以标记在不同名称下提供相同工具的服务器。
• 超时。 每个请求的超时时间为 15 秒。每个主机同一时间最多运行一个探测器。
• 获取访问权限。 对于返回 401 或 403 的服务器，探测器会读取 OAuth 受保护资源元数据（RFC 9728）和第一个授权服务器的元数据（RFC 8414，然后是 OpenID 发现）：授权服务器、作用域、发布者指南、动态客户端注册（RFC 7591）、PKCE、授权类型。服务器页面会将其显示为“获取访问权限”，JSON API 中则显示为 authKind 和 authMetadata。整个过程只需两到四个简短请求，不需要令牌或用户同意；不会改变探测结果。
• 身份标识。 每个请求都会携带 User-Agent mcpcost/<version> (+https://github.com/ondraulehla/mcpcost)。如要排除某个服务器，请使用其注册表名称提交 issue。

运行

npm install
npm run probe -- --sample 200 --per-host 2        # a sample, results in data/samples/
npm run probe -- --all --out data/raw/probe-run.json
node --import tsx probe/build-data.ts --in data/raw/probe-run.json --out data/latest
node --import tsx probe/to-sql.ts --in data/latest --out data/latest/import.sql
npm test --workspaces --if-present

站点在本地运行，并使用本地 D1：

cd site
npm run db:schema:local && npm run db:import:local
npm run dev

MCP 端点无需 SDK 即可响应 initialize、tools/list、ping 以及 site/src/lib/mcp-snapshot.json 中的通知；其他请求都会交给 SDK 处理。快照必须包含 SDK 自身的响应，否则站点构建会失败：更改工具定义后，运行 npm run mcp:snapshot -w site，并在同一个提交中提交新文件。构建也会运行的 npm test -w site 会逐字节对比这两份响应。

分享链接会显示一张卡片：site/public/og/ 中的一张 1200x630 PNG。这里有一张默认卡片，以及分别用于 October 报告、Compare 和 Statistics 的卡片。site/src/lib/og.ts 列出了卡片及其文字。布局会将页面的卡片放入 og:image 和 twitter:image；页面也可以向布局提供自己的图片。npm run og -w site 会使用 satori 和 resvg（以 WebAssembly 形式）重新绘制卡片。该命令可离线运行，使用 node_modules 中的字体和 Layout.astro 的颜色变量。如果已提交的卡片与脚本当前绘制的内容不一致，npm test -w site 就会失败：更改卡片、字体或颜色变量后，请在同一个提交中提交新的 PNG。卡片不包含每日数据，因为这些数据很快就会过时。卡片是静态文件，会在 Worker 之前提供，因此不会产生请求费用。若要将默认卡片用作 GitHub 仓库的社交预览，请在仓库设置的 Social preview 下上传 site/public/og/default.png。

发送提醒邮件需要发送域名：可以使用 Cloudflare Email Sending（Workers Paid 计划，然后在 site/wrangler.jsonc 中配置 send_email 绑定），也可以使用 Resend（在该服务中验证域名，然后运行 npx wrangler secret put RESEND_API_KEY）。如果没有配置，监控表单会提示无法发送确认邮件。

部署需要一个 Cloudflare 账户，并且其中要有一个名为 mcpcost 的 D1 数据库（运行 wrangler d1 create mcpcost，然后将 id 填入 site/wrangler.jsonc）。工作流需要仓库密钥 CLOUDFLARE_API_TOKEN（Workers Scripts: Edit、D1: Edit）和 CLOUDFLARE_ACCOUNT_ID。每次运行时，两个工作流都会应用 site/schema.sql 和 site/migrations/ 中待处理的文件。显示令牌计数上的两个索引（迁移 007 和 008）是例外：每次构建都会为每个服务写入一行，因此探测工作流会在导入前一天应用其中一个索引，为导入留出其余写入额度。新数据库需要手动应用这两个索引一次。

边缘规则

Workers 免费计划会统计 Worker 响应的每个请求，403 也算，与页面请求一样。2026-10-22 和 23 日，使用 Chrome 用户代理、来自托管服务地址（Meta 的云、Alibaba Cloud、RapidSeedbox）的爬虫每小时生成 4 000 个列表变体，耗尽了账户每天 100 000 次请求的额度，尽管 Worker 拒绝了它们。阻止它们的规则必须在 Worker 运行之前生效：site/edge/rules.mjs 通过 API 编写区域的 WAF 规则，并且支持幂等操作。

• 一条自定义规则，在整个主机上阻止 Meta 的训练爬虫 meta-externalagent：这是一个已验证的机器人，会无视 robots.txt；截至 2026-10-24 05:42 UTC 的十二小时内，它发出了 Worker 31 000 个请求中的 28 000 个，却没有带来任何读者（链接预览工具 facebookexternalhit 不会被阻止）
• 一条自定义规则，在整个主机上阻止这些网络，但已验证的机器人除外
• 一条自定义规则，对所有非已验证机器人的列表变体（/servers?…）发起托管质询；浏览器通过一次后即可继续，脚本则无法通过。列表 API（/api/servers.json）不受此规则影响：脚本和 Agent 无法通过质询，因此 API 在速率限制规则下保持开放
• 一条自定义规则，在列表变体上阻止已验证的机器人：robots.txt 对所有人都禁止访问这些路径，搜索引擎不会请求，而 Meta 的爬虫（使用 Chrome Agent 字符串的 meta-externalagent）在 2026-10-23 每小时访问了 3 000 个此类路径
• 免费计划唯一一条速率限制规则：来自同一地址的列表变体请求在十秒内超过六次时，阻止十秒

CLOUDFLARE_API_TOKEN=… node site/edge/rules.mjs --dry-run   # shows what it would write
CLOUDFLARE_API_TOKEN=… node site/edge/rules.mjs

边缘规则工作流（.github/workflows/edge.yml）会在文件变更合并到 main 时运行脚本，也可以手动运行；运行时需要 CLOUDFLARE_ZONE_TOKEN 密钥：该令牌在对应区域上具有 Zone: Zone WAF: Edit 和 Zone: Zone: Read 权限。探测脚本使用的令牌不具备这两项权限。site/src/middleware.ts 中间件会保留相同的拒绝规则，作为第二层防护，适用于区域规则看不到的 workers.dev 主机。

监控

site/edge/watch.mjs 会报告在一段时间内访问了看板的对象以及产生的成本：从账户分析数据中获取每小时的 Worker 请求数和 D1 行数，再从 Worker 日志中获取请求背后的网络、Agent 和 URL 形式。监控边缘工作流（.github/workflows/watch.yml）每小时运行一次，统计自上次计划运行以来的数据（GitHub 有时会延迟运行计划任务，也会跳过一些小时）；阈值以该时间窗口内最糟糕的一小时为准。若超过阈值（每小时 5 000 个 Worker 请求；来自未标明爬虫的 Agent 的某个网络每小时 800 个请求；来自某个网络的列表变体每小时 300 个请求，不论它如何自称；每小时一百万行 D1 数据；对应变量为 WATCH_*），运行状态会变红，并创建带有 edge-watch 标签的问题，或将该小时添加到已有的未关闭问题中。表格会标出网络；其 ASN 会写入 site/edge/rules.mjs 中的 SCRAPER_ASNS，边缘规则工作流会在 Worker 运行前阻止该网络。报告还会列出这些小时内读取行数最多的 D1 查询。若区域令牌具有 Zone: Analytics: Read 权限，报告还会显示区域在 Worker 运行前拦截了什么。

CLOUDFLARE_API_TOKEN=… CLOUDFLARE_ACCOUNT_ID=… node site/edge/watch.mjs                                   # the last hour
CLOUDFLARE_API_TOKEN=… CLOUDFLARE_ACCOUNT_ID=… node site/edge/watch.mjs 2026-10-22T22:00:00Z 2026-10-23T06:00:00Z   # one night

手动运行并启用 quiet 时，只会写入报告：回看过去的时间窗口不会创建问题，也不会因为某个小时已报告过而将运行状态变红。

gh workflow run watch.yml -f from=2026-10-24T19:00:00Z -f quiet=true

旧主机

截至 2026-10-15，网站的主机名为 mcp-pulse.ulehla.dev。旧主机仍是 Worker 的一个路由，site/src/middleware.ts 中间件会将其上的每个请求以 301 重定向到 mcpcost.ulehla.dev。

静态资源在 Worker 之前提供，Astro 适配器也会在中间件之前提供预渲染页面，因此旧主机上的 site/public/ 文件或预渲染页面会返回 200。wrangler.jsonc 中的 run_worker_first 不会改变这一点。因此，robots.txt、llms.txt 和方法论页面都是路由，爬虫读取的每个页面都会经过中间件。只有 favicon、/_astro/ 下的字体、/og/ 下的社交卡片、/data/ 下的数据集，以及搜索引擎验证文件仍是静态资源。

如需在完全不调用 Worker 的情况下也重定向这些资源，请在 Cloudflare 控制面板的 ulehla.dev 区域中添加 Redirect Rule（Rules、Redirect Rules、Create rule）：

• 匹配传入请求的条件：Hostname 等于 mcp-pulse.ulehla.dev
• 然后：Dynamic redirect，表达式 concat("https://mcpcost.ulehla.dev", http.request.uri.path)，状态码 301，开启保留查询字符串

Redirect Rules 在 Worker 和静态资源之前运行，因此该规则涵盖所有路径。中间件仍会作为 workers.dev 主机的后备方案，因为区域规则看不到该主机。

发布

标签 v0.Y.Z 会启动 Release 工作流（.github/workflows/release.yml）。该工作流会检查五个文件中的版本是否与标签版本一致（node scripts/version.mjs --check），运行测试和 npm run check -w site，并打包。随后，它会将包连同来源证明发布到 npm，将 site/server.json 发布到 MCP 注册表，并创建 GitHub Release。无需 npm token、OTP 或 mcp-publisher login：npm 信任该工作流文件（可信发布），而注册表会使用本次运行的 GitHub OIDC token。

在 npmjs.com 上只需设置一次。请在首次发布当天完成：新的可信发布者如果 2 天内未发布，就会过期。

1. 打开包 mcpcost，然后进入 Settings。在 Trusted Publisher 部分选择 GitHub Actions。
2. Organization or user：ondraulehla。Repository：mcpcost。Workflow filename：release.yml。Environment name：留空。
3. 在 Allowed actions 下，允许 npm publish。2026-09-03 之后创建的可信发布者只允许 npm stage publish，暂存版本需要通过 2FA 批准。
4. 保存。使用 npm 11.15.0 或更高版本并启用 2FA 时，也可在 shell 中运行：npm trust github mcpcost --file release.yml --repo ondraulehla/mcpcost --allow-publish。

首次发布后，在 Settings、Publishing access 中启用“Require two-factor authentication and disallow tokens”，即可阻止所有使用 token 的发布。工作流仍可继续发布。

一次发布：

node scripts/version.mjs patch       # or minor, or 0.3.5: sets the version in the five files
git commit -am "mcpcost 0.3.5: …"    # the message of this commit becomes the release notes
git push origin main
git tag v0.3.5 && git push origin v0.3.5

• 要在打标签前测试设置：进入 Actions、Release、Run workflow，并选中“Dry run”框。该工作流会运行检查、npm publish --dry-run 和注册表登录，但不会发布任何内容。警告“npm did not accept this workflow”表示 npmjs.com 上的可信发布者配置不匹配。Dry run 不会检查允许的操作。
• 附注标签（git tag -a v0.3.5 -m "…"）会将其消息用作发布说明。
• 如果某次运行失败，请重新运行失败的任务。每个发布步骤都会跳过已被 npm 或注册表发布过的版本。
• 在 main 上运行且不选中“Dry run”，会在不推送标签的情况下发布：发布流程会在该提交上创建标签。
• 包的发布永远不会成为 Latest release（--latest=false）。因此，仓库的 Latest release 会保持为 GitHub Action 的发布版本（v1.1.0），Marketplace 页面也会显示该版本。该 Action 有自己的发布版本 v1.x.y，通过 GitHub 上的发布表单发布到 Marketplace，其标签 v1 会指向最新版本。工作流不会修改这些内容。只有标签 v0.Y.Z 才会启动该工作流，因此在包采用自己的标签方案之前，其版本会保持在 1.0.0 以下。

许可证

MIT