Server data from the Official MCP Registry
Read-only MCP server over robertdelanghe.dev's Sigstore-verified static API (stdio).
Read-only MCP server over robertdelanghe.dev's Sigstore-verified static API (stdio).
Valid MCP server (3 strong, 1 medium validity signals). No known CVEs in dependencies. Package registry verified. Imported from the Official MCP Registry.
10 files analyzed · 1 issue found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
This plugin requests these system permissions. Most are normal for its category.
Set these up before or after installing:
Environment variable: SITE_MCP_SIGNATURE_MODE
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-bounded-systems-site-mcp": {
"env": {
"SITE_MCP_SIGNATURE_MODE": "your-site-mcp-signature-mode-here"
},
"args": [
"-y",
"@bounded-systems/site-mcp"
],
"command": "npx"
}
}
}From the project's GitHub README.
A local, read-only MCP server (and a matching CLI) over robertdelanghe.dev's signed static API.
It exposes the site's identity data — profile, writing, the GitHub corpus, the
résumé credential, the OpenAPI doc — 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.
This package is now 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.
site-mcp supplies only:
src/verbs.ts) — list_posts, get_post,
get_conformance, each authored once as a @bounded-systems/verbspec
VerbSpec;src/catalog.ts) — the
site://… resources;src/config.ts) — the origin and
expected signer identity; andsrc/index.ts) — which picks a surface and
hands the spec to the core.src/verbs.ts ─┐
src/catalog.ts ├─▶ buildSiteSpec(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
site-mcp's MCP tools and its CLI commands — no second definition, no drift.
Requires Node ≥ 18.17. site-mcp's 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/site-mcp
# CLI — the SAME verbs, printing the verified JSON:
npx -y @bounded-systems/site-mcp list_posts
npx -y @bounded-systems/site-mcp get_conformance
npx -y @bounded-systems/site-mcp get_post agent-authored-code-drift
The MCP server logs a readiness line to stderr (stdout is the MCP channel):
site-mcp ready (stdio) → https://robertdelanghe.dev; signature mode=off
{
"mcpServers": {
"robertdelanghe": {
"command": "npx",
"args": ["-y", "@bounded-systems/site-mcp"],
"env": { "SITE_MCP_SIGNATURE_MODE": "warn" }
}
}
}
| Resource URI | Endpoint | Contents |
|---|---|---|
site://profile | profile.json | Headline, intro, label, links |
site://posts | posts.json | JSON Feed of writing (post list) |
site://post/{slug} | posts/{slug}.json | A single post (templated; list enumerates from the feed) |
site://corpus | corpus.json | GitHub corpus: stats + highlights |
site://conformance | conformance.json | Per-page DOM conformance report |
site://resume-vc | resume.vc.json | Résumé as a Verifiable Credential |
site://openapi | openapi.json | The OpenAPI 3.2 document for the API |
The same three verbs, on both surfaces:
| Tool / command | Args | Returns |
|---|---|---|
list_posts | — | The posts feed (slug, title, summary, tags) |
get_post | slug | A single post by slug |
get_conformance | — | The conformance / accessibility report |
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.
The site publishes a single signed manifest, https://robertdelanghe.dev/site.sha256
(sha256sum format), and a Sigstore bundle over it, site.sha256.sigstore.json.
The core enforces:
VerificationError instead of a response. A path absent from the
manifest is likewise refused.SITE_MCP_SIGNATURE_MODE=warn|require
verifies the Sigstore bundle against the deploy workflow identity
(…/bdelanghe/site/.github/workflows/deploy.yml@refs/heads/main).Sigstore backend /
@bounded-systems/verify. The optional manifest-signature step is intended to delegate to@bounded-systems/verify, the canonical in-process bundle verifier. As ofverify@0.1.0that package ships as a self-executing CLI with no exported function (importing it runs and exits the process), so the core keeps a minimal, behaviorally-identical copy of the check and the gap is filed upstream. See static-mcp's README.
| Variable | Default | Meaning |
|---|---|---|
SITE_MCP_BASE_URL | https://robertdelanghe.dev | Origin serving the site + API + manifest |
SITE_MCP_SIGNATURE_MODE | off | off | warn | require |
SITE_MCP_SIGNER_IDENTITY | deploy workflow SAN | Expected Sigstore certificate identity |
SITE_MCP_SIGNER_ISSUER | GitHub Actions OIDC | Expected Sigstore OIDC issuer |
SITE_MCP_FETCH_TIMEOUT_MS | 15000 | Per-request fetch timeout |
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
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/site-mcp | trusted publishing (OIDC) + provenance |
| 2 | JSR (mirror) | @bounded-systems/site-mcp | tokenless OIDC (npx jsr publish) |
| 3 | MCP Registry | io.github.bounded-systems/site-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).
[!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/site-mcp"(it reads that field off the published npm package to prove ownership).
The MCP Registry job runs after the npm job, because the registry verifies
ownership by reading mcpName from the freshly-published npm package.
These three registry-side authorizations only need to happen once. Two of the three (JSR, MCP Registry) are pure repo-link / OIDC — no tokens are minted.
(a) npm — Trusted Publisher (on npmjs.com)
@bounded-systems scope.@bounded-systems/site-mcp → Settings →
Trusted Publisher. For a brand-new package you may need to publish 0.1.0
once manually (or create the package), then switch to trusted publishing.bounded-systemssite-mcppublish.yml ← (was publish-npm.yml)(b) JSR — create + link the package (on jsr.io)
@bounded-systems/site-mcp
under the @bounded-systems scope.bounded-systems/site-mcp and click Link. Linking the repo is what enables
tokenless OIDC publishing from this workflow (same idea as npm's trusted
publisher). No token is created.(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 of the namespace from the Actions run itself.
There is no registry-side claim/consent/linking step to do in advance — the
first publish.yml run authenticates and registers the server on its own.
(Package-ownership of the npm entry is proven separately by the mcpName field;
see the note above.)
# 1. Bump the version in ALL of: package.json, deno.json, server.json
# (and the package entry in 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
That one v* tag triggers publish.yml → npm + JSR + MCP Registry, all at the
same version. You can also run it from the Actions tab via workflow_dispatch
(which reuses the package.json version in place of a tag).
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
site-mcp depends on
@bounded-systems/static-mcp; publish the core first (its ownv*tag → JSR + npm), then cut site-mcp's tag.
MIT — see LICENSE. The site data itself is published under CC BY 4.0.
Be the first to review this server!
by Modelcontextprotocol · Developer Tools
Web content fetching and conversion for efficient LLM usage
by Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
by Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.