@bounded-systems/bounded-tools-mcp
Local, read-only MCP server that provides verified access to bounded.tools' signed static API, including the Web-Build Conformance report and SPDX SBOM, with byte-for-byte verification against a Sigstore-signed manifest.
README
@bounded-systems/bounded-tools-mcp
A local, read-only MCP server (and a matching CLI) over bounded.tools' signed static API.
It exposes the parts of the site that are served as verifiable, content-addressed
JSON — the Web-Build Conformance report and the SPDX SBOM — to any MCP client
(Claude Desktop, Claude Code, etc.), and verifies every response byte-for-byte
against the site's Sigstore-signed sha256 manifest before handing it back. If
the bytes a client would receive don't match the signed manifest, it refuses to
return them.
It runs locally over stdio — the client spawns it as a subprocess. There is no hosted server and no network listener, which preserves the site's static / no-attack-surface posture.
A thin implementation of a generic core
This package is thin. All of the reusable machinery — the verifying fetch
client, the sha256 manifest + Sigstore checks, and the
VerbSpec → MCP (tools + resources) / VerbSpec → CLI projection — lives in
@bounded-systems/static-mcp.
bounded-tools-mcp supplies only:
- the verbs (
src/verbs.ts) —get_conformance,get_sbom, each authored once as a@bounded-systems/verbspecVerbSpec; - the resource catalog (
src/catalog.ts) — thetools://…resources; - the config values (
src/config.ts) — the origin and expected signer identity; and - the entry (
src/index.ts) — which picks a surface and hands the spec to the core.
src/verbs.ts ─┐
src/catalog.ts ├─▶ buildToolsSpec(config) ─▶ @bounded-systems/static-mcp
src/config.ts ─┘ serveVerifiedStaticMcp(spec, config) (MCP, stdio)
runStaticCli(spec, config, argv) (CLI)
Two surfaces, one definition. verbspec projects each verb to both an MCP tool and a CLI subcommand. The exact same verb set backs the MCP tools and the CLI commands — no second definition, no drift.
What's exposed (and what isn't)
bounded.tools is a static site whose verifiable surface is intentionally small. Only artifacts the site serves as signed, content-addressed JSON are exposed here — each is fetched and verified byte-for-byte against the signed manifest:
| Served as | Artifact | Exposed |
|---|---|---|
| signed JSON | api/v1/conformance.json |
✅ get_conformance · tools://conformance |
| signed JSON | sbom.spdx.json |
✅ get_sbom · tools://sbom |
| signed JSON | site.webmanifest |
✅ tools://webmanifest (resource only) |
| signed HTML + Markdown | the blog (blog/*.html, blog/*.md) |
❌ not JSON — see below |
Honesty over surface area. The blog is covered by the signed manifest, but it is served as HTML + Markdown, not as a JSON feed or per-post JSON documents. The verified-static core fetches-and-JSON-parses each artifact, so exposing the blog as a "tool" would mean fabricating a JSON shape the site does not actually serve. It is therefore left out rather than faked. If bounded.tools later publishes a signed
posts.json(and per-post JSON),list_posts/get_postverbs drop straight in, exactly as insite-mcp.
Install / run
Requires Node ≥ 18.17. The verbspec dependency is published to JSR, so installs
resolve it through JSR's npm bridge — the included .npmrc sets
@jsr:registry=https://npm.jsr.io. (Consuming from a fresh environment, add that
one line to your npm config.)
# MCP server over stdio (what an MCP client launches):
npx -y @bounded-systems/bounded-tools-mcp
# CLI — the SAME verbs, printing the verified JSON:
npx -y @bounded-systems/bounded-tools-mcp get_conformance
npx -y @bounded-systems/bounded-tools-mcp get_sbom
The MCP server logs a readiness line to stderr (stdout is the MCP channel):
bounded-tools-mcp ready (stdio) → https://bounded.tools; signature mode=off
MCP client configuration
{
"mcpServers": {
"bounded-tools": {
"command": "npx",
"args": ["-y", "@bounded-systems/bounded-tools-mcp"],
"env": { "BOUNDED_TOOLS_MCP_SIGNATURE_MODE": "warn" }
}
}
}
Resources
| Resource URI | Endpoint | Contents |
|---|---|---|
tools://conformance |
api/v1/conformance.json |
Web-Build Conformance Standard report (HTML / WCAG 2.2 / ARIA) |
tools://sbom |
sbom.spdx.json |
SPDX software bill of materials |
tools://webmanifest |
site.webmanifest |
W3C web app manifest (PWA site metadata) |
Tools / CLI commands (read-only)
The same two verbs, on both surfaces:
| Tool / command | Args | Returns |
|---|---|---|
get_conformance |
— | The Web-Build Conformance report |
get_sbom |
— | The SPDX software bill of materials |
Resource reads and tool results carry a _meta.verification block (the
manifest-relative path, source URL, the verified sha256, and the manifest
signature status). The CLI prints the verified JSON; a verification failure exits
non-zero with nothing on stdout.
Verification / trust model
The site publishes a single signed manifest, https://bounded.tools/site.sha256
(sha256sum format), and a Sigstore bundle over it, site.sha256.sigstore.json.
The core enforces:
- Per-file hash check (always on). Fetch the manifest once per process; for
every resource, fetch it, SHA-256 the received bytes, and require that digest
to equal the manifest entry. A tampered file, a stale CDN edge, or a MITM →
mismatch →
VerificationErrorinstead of a response. A path absent from the manifest is likewise refused. - Manifest signature check (optional).
BOUNDED_TOOLS_MCP_SIGNATURE_MODE=warn|requireverifies the Sigstore bundle against the deploy workflow identity (…/bounded-systems/site/.github/workflows/deploy.yml@refs/heads/main, OIDC issuerhttps://token.actions.githubusercontent.com). This is the same keyless identity published inhttps://bounded.tools/provenance.json.
Configuration
| Variable | Default | Meaning |
|---|---|---|
BOUNDED_TOOLS_MCP_BASE_URL |
https://bounded.tools |
Origin serving the site + API + manifest |
BOUNDED_TOOLS_MCP_SIGNATURE_MODE |
off |
off | warn | require |
BOUNDED_TOOLS_MCP_SIGNER_IDENTITY |
deploy workflow SAN | Expected Sigstore certificate identity |
BOUNDED_TOOLS_MCP_SIGNER_ISSUER |
GitHub Actions OIDC | Expected Sigstore OIDC issuer |
BOUNDED_TOOLS_MCP_FETCH_TIMEOUT_MS |
15000 |
Per-request fetch timeout |
Development
npm install # resolves @bounded-systems/static-mcp (npm) + verbspec (JSR bridge)
npm run build # tsc → dist/
npm test # node --test via tsx (server + CLI; no network)
npm run typecheck
node scripts/headless-check.mjs # live end-to-end against bounded.tools
Publishing
One tag publishes the same version to three registries, mirrored. Pushing a
v* tag runs publish.yml, which fans out to:
| # | Registry | Identifier | Auth |
|---|---|---|---|
| 1 | npm | @bounded-systems/bounded-tools-mcp |
trusted publishing (OIDC) + provenance |
| 2 | JSR (mirror) | @bounded-systems/bounded-tools-mcp |
tokenless OIDC (npx jsr publish) |
| 3 | MCP Registry | io.github.bounded-systems/bounded-tools-mcp |
GitHub-OIDC namespace auth (mcp-publisher) |
There are no long-lived secrets — every registry authenticates with the
job's short-lived GitHub Actions OIDC token (id-token: write). npm needs
npm ≥ 11.5 (the workflow upgrades npm to guarantee this). The mcp-registry job
is decoupled from the npm job (needs: verify, NOT needs: npm): the
registry proves package ownership by reading the mcpName field off the
already-published npm package, so it can run/retry independently.
[!IMPORTANT] Versions must stay in sync. The release version lives in four places that must all match:
package.json,deno.json,server.json, and thev<version>git tag. The workflow'sverifyjob hard-fails the whole release on any mismatch, so npm and JSR can never drift apart. The MCP Registry also requirespackage.jsonto carry"mcpName": "io.github.bounded-systems/bounded-tools-mcp"(it reads that field off the published npm package to prove ownership).
One-time setup (maintainer) — do these BEFORE the first tag
(a) npm — Trusted Publisher (on npmjs.com)
- Sign in as an owner of the
@bounded-systemsscope. - Open the package page for
@bounded-systems/bounded-tools-mcp→ Settings → Trusted Publisher. For a brand-new package you may need to publish0.1.0once manually (or create the package), then switch to trusted publishing. - Choose GitHub Actions and enter:
- Organization / user:
bounded-systems - Repository:
bounded-tools-mcp - Workflow filename:
publish.yml - Environment: (leave blank)
- Organization / user:
- Save. No token is generated or stored anywhere.
(b) JSR — create + link the package (on jsr.io)
- Sign in to jsr.io with GitHub and create the package
@bounded-systems/bounded-tools-mcpunder the@bounded-systemsscope. - Open the package's Settings tab → under GitHub Repository enter
bounded-systems/bounded-tools-mcpand click Link. Linking the repo enables tokenless OIDC publishing from this workflow.
(c) MCP Registry — nothing to pre-authorize
The io.github.bounded-systems/* namespace is auto-authorized via GitHub
OIDC: because this repo lives under github.com/bounded-systems,
mcp-publisher login github-oidc proves ownership from the Actions run itself.
Cut a release (the single command)
# 1. Bump the version in ALL of: package.json, deno.json, server.json. Commit.
# 2. Tag with the SAME version and push — this is the only command:
git tag v0.1.0 && git push origin v0.1.0
Local dry-runs (verify without publishing)
npm pack --dry-run # npm tarball contents
npx --yes jsr publish --dry-run --allow-slow-types # JSR (or: deno publish --dry-run --allow-slow-types)
mcp-publisher validate ./server.json # MCP Registry schema check
bounded-tools-mcp depends on
@bounded-systems/static-mcp; that core is published independently (its ownv*tag → JSR + npm) before cutting this tag.
License
MIT — see LICENSE.
推荐服务器
Baidu Map
百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。
Playwright MCP Server
一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。
Magic Component Platform (MCP)
一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。
Audiense Insights MCP Server
通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。
VeyraX
一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。
graphlit-mcp-server
模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。
Kagi MCP Server
一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。
e2b-mcp-server
使用 MCP 通过 e2b 运行代码。
Neon MCP Server
用于与 Neon 管理 API 和数据库交互的 MCP 服务器
Exa MCP Server
模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。