Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Verifies Bernstein run receipts and hash chains; lists the shipped presets and adapters. Read-only.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
适用于网页版、桌面版和手机版 Claude:
https://mcp.bernstein.run/mcp在终端中运行这条命令
claude mcp add --transport http bernstein https://mcp.bernstein.run/mcp粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"bernstein": {
"url": "https://mcp.bernstein.run/mcp"
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"bernstein": {
"type": "http",
"url": "https://mcp.bernstein.run/mcp"
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
ChatGPT 只能连接互联网上的服务器:
https://mcp.bernstein.run/mcp菜单名称可能因套餐和版本不同而略有差异。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
我们还没有读取这个服务器的工具列表;我们会轮流检查各个端点。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月8日
注册名称已通过 GitHub 账户 sipyourdrink-ltd 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
尚未检查;我们会轮流检查各个端点
尚未检查;我们会轮流检查各个端点
尚未检查;我们会在检查端点时读取工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在作者的云端运行。通过互联网连接,无需安装,但你发送的内容会经过作者的服务器。
GitHub 仓库最后更新于–,最新版本(0.2.0)于2个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。它通过 URL 连接,所以接受远程 MCP 服务器的应用也可以使用,例如开启开发者模式的 ChatGPT。
同一分类中有:Spec Driven Development, Remote Desktop Commander, Thalovant MCP
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:↓ 每周下载量i★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Connect MCP clients to Thalovant control-plane and hub runtime APIs over stdio or Streamable HTTP.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
Stateless, read-only MCP endpoint at https://mcp.bernstein.run that verifies bernstein run receipts and hash chains. No account, no key, nothing stored, nothing fetched.
claude mcp add --transport http bernstein https://mcp.bernstein.run/mcp
| Tool | Result |
|---|---|
verify_receipt | recomputes every chain a run receipt embeds, rebuilds the signed subject, checks the Ed25519 signature; verdict + one line per check, plus the verdict as a signed statement (below) |
explain_receipt | the same verification, narrated: what the run recorded, where it diverges, what the result does and does not prove |
verify_chain | walks journal rows, lineage entries or audit events on their own (pass the file text for byte-exact rows); names the first broken link |
verify_trace_record | TRACE v0.2 conformance checks on one Trust Record, stateless, no account: vendored schema, profile rules, the embedded signature with the key in cnf.jwk (EdDSA, ES256, ES384); record_sha256 is the RFC 8785 digest a child hop links to |
verify_delegation_chain | walks a set of Trust Records from the leaf to the root and classifies the chain (verified, provenance-invalid, authorization-invalid, unverifiable) with the same codes as the delegation-link corpus |
verify_agent_manifest | stateless check of a signed agent manifest (v0.2 COSE envelope): vendored schema, profile, canonicalization, embedded signature (Ed25519, P-256, P-384); optional trust record cross-check via references[]; verdicts valid / invalid / unverifiable |
explain_trace_mapping | how a bernstein run maps onto a TRACE v0.2 Trust Record, claim by claim; pass a receipt to fill in what its journal answers |
list_presets / get_preset | the compliance presets this release ships |
list_adapters | the agent adapters bundled with this release |
server_info | version and limits |
Same walk as bernstein verify-receipt, reachable from any MCP client or the paste form at /verify. A verdict's page address is the receipt's own digest.
| Proves | Does not prove |
|---|---|
| the embedded rows are exactly the rows that were signed | that the embedded key belongs to who you think (trust-on-first-use; pin the operator's published key yourself) |
| nothing was edited, reordered, dropped or appended after signing | audit-range HMAC values (keyed by the producing install; their linkage and content hash are still checked) |
Pass the receipt file's contents as a string: an already parsed object cannot tell 1 from 1.0, and the reference hashes the original spelling.
Every verdict comes back as a DSSE envelope (signed_verdict) signed with this deployment's Ed25519 key: the payload is a JCS-canonical statement naming the receipt by digest, the verdict, every check, and an appraisal block in the EAR status vocabulary (affirming / contraindicated / none). Keep it next to the receipt; anyone can re-check it offline against the public key at /.well-known/bernstein-mcp/keys.json (kid = RFC 7638 thumbprint). The signature covers the DSSE PAE of application/vnd.bernstein.verdict+json, the same construction the receipt itself uses. It attests that *this verifier reached this verdict for these bytes at this time* — nothing about the receipt's producer.
bernstein-attest turns a Claude Code or Codex CLI session into a signed run receipt that this server verifies.
npx bernstein-attest init # registers hooks for both agents (user scope); --claude-code / --codex / --project to narrow
bernstein-attest link # verify link + one Markdown line for a PR description bernstein-attest verify .bernstein/receipts/ .json
Codex runs project hooks only after they are trusted once with /hooks in an interactive session; codex exec skips untrusted hooks without printing anything. With --project, Claude Code hooks go to .claude/settings.local.json and Codex hooks to .codex/hooks.json; both name the bundle under your home directory, so keep .codex/hooks.json out of version control.
Recorded per tool call: tool name, hashes of its input and output, success flag, repo-relative path for files the call wrote (hash only for paths outside the project), the program name of a shell command (first token, path stripped, at most 32 characters). Not recorded: prompts, model output, command text, file contents, absolute paths. The receipt is sealed at the end of every turn that recorded something new, and every 2 000 rows; the file lives in .bernstein/receipts/ and can be committed with the change it describes. Because later turns reseal the same file, run npx bernstein-attest link right before committing it so the link you paste names the current bytes.
| Request body | 1 MiB |
| Rows per chain | 2 000 (larger receipts: verify locally) |
| Rate | 60 requests/min per address on POST /mcp and POST /verify |
| Logging | one JSON line per request: route, method, status, JSON-RPC method, tool, verdict, producer family, MCP client name/version, country, colo. Never the address, a header, the body or the receipt |
vectors/ holds eight golden vectors generated by the Python reference (scripts/gen_vectors.py against the pinned bernstein source). The TypeScript verifier must reproduce each vector's verdict, every check, the binding bytes and the receipt digest byte for byte (test/vectors.test.ts). vectors/session/ holds three frozen session receipts written by bernstein-attest (scripts/gen-session-vectors.mjs).
npm install
npm test # no-fetch guard + vitest npm run typecheck npm run dev # wrangler dev
src/ may not call fetch, eval or new Function; CI fails otherwise. Deploying: see DEPLOY.md. Licence: Apache-2.0.