@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.
Recommended Servers
playwright-mcp
A Model Context Protocol server that enables LLMs to interact with web pages through structured accessibility snapshots without requiring vision models or screenshots.
Magic Component Platform (MCP)
An AI-powered tool that generates modern UI components from natural language descriptions, integrating with popular IDEs to streamline UI development workflow.
Audiense Insights MCP Server
Enables interaction with Audiense Insights accounts via the Model Context Protocol, facilitating the extraction and analysis of marketing insights and audience data including demographics, behavior, and influencer engagement.
VeyraX MCP
Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.
graphlit-mcp-server
The Model Context Protocol (MCP) Server enables integration between MCP clients and the Graphlit service. Ingest anything from Slack to Gmail to podcast feeds, in addition to web crawling, into a Graphlit project - and then retrieve relevant contents from the MCP client.
Kagi MCP Server
An MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.
E2B
Using MCP to run code via e2b.
Neon Database
MCP server for interacting with Neon Management API and databases
Exa Search
A Model Context Protocol (MCP) server lets AI assistants like Claude use the Exa AI Search API for web searches. This setup allows AI models to get real-time web information in a safe and controlled way.
Qdrant Server
This repository is an example of how to create a MCP server for Qdrant, a vector search engine.