@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 the
v<version> git tag. The workflow's verify job hard-fails the whole release
on any mismatch, so npm and JSR can never drift apart. The MCP Registry also
requires package.json to 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.