Published-content MCPs — public context without private repo access

A public reader asked the right question in the wrong shape: “Can an agent just see the repo so it understands StoneyTECH?”

The question sounds harmless until the boundary appears. A repository is not a publication. It contains half-written drafts, branch scaffolds, private notes, environment names, local paths, dead experiments, compliance receipts, work-claim evidence, deployment wiring, and all the little operational fossils making a real project real. Even with secrets properly excluded, the repository still says more than the public site means to say.

The answer should not be “give the agent the repo.” The answer should be: give the agent the same public context a careful human reader can see, in a reliable navigation shape.

The published-content MCP exists for this boundary.

The problem is not access. It is scope.

When people say “make the agent understand the company,” they usually reach for more access. More pages. More docs. More repos. More channels. The word “context” becomes a permission slip.

StoneyTECH solves a different problem: how outside agents can converge on the public narrative without drifting into the private operating system behind it.

Those are different scopes.

Published context is the set of pages, articles, axioms, build notes, public repository notes, and applied-evidence records intentionally placed in front of readers. It is the organization explaining itself.

Operational context is the machinery behind the work: private repositories, internal review workflows, tribunal payloads, work claims, compliance ledgers, deployment secrets, branch history, drafts, and internal planning. It may be true. It may even be useful. But it is not automatically public just because an agent could technically read it.

The published-content MCP exists to keep those scopes separate.

A Public MCP Should Be A Projection, Not A Tunnel

The wrong public MCP creates a tunnel into the workspace. It has a “search repo” tool, a “read file” tool, maybe a browser tool pointed at the private preview environment. It works beautifully right up until a reader asks a broad question and the model answers from unpublished material.

The right public MCP is a projection. It exposes a generated public artifact, not the workspace itself.

In this case the artifact is the generated stoneytech.public_content.v1 contract. The same site source building stoneytech.net emits it. It contains public routes, Learn and Demystify articles, axioms, build entries, public repository notes once they exist, applied evidence, search entries, content hashes, and an exclusion manifest.

The MCP at https://public-content-mcp.stoneytech.net/mcp reads the public contract. It gets no side door into the private repo. It does not scrape the live site and invent structure. It does not ask the model to infer safe files. The boundary exists before the model enters the room.

The determinism-ladder move: push “what is public?” down into a generated contract and tests, then let the agent operate on the result.

The negative data contract is the product.

Most demos talk about what a tool can access. Security work starts with what it cannot access.

For the StoneyTECH public MCP, the negative contract is explicit:

• No draft posts or preview routes.
• No private repository contents.
• No private repository names unless already published on the site.
• No internal review workflows, tribunal payloads, model votes, internal run identifiers, webhook URLs, or credentials.
• No work-claim graph records, leases, fencing tokens, or reconciliation records.
• No compliance ledger internals, raw findings, audit database paths, or unpublished control evidence.
• No secrets, session cookies, OAuth client secrets, signing keys, Cloudflare bindings, OpenRouter keys, or deployment tokens.
• No write, mutate, deploy, reconcile, claim, or private coordination tools.

The list is not housekeeping. It is the public promise. If the MCP can answer a question only by crossing one of those boundaries, the correct answer is a boundary-aware refusal or a narrower answer from published material.

This matters because a public agent surface has a special failure mode: it can sound more authoritative than the website while carrying weaker boundaries. A human reader sees the current page. An IDE agent can blend retrieved fragments, tool outputs, and guesses into one confident paragraph. The MCP has to make the authority boundary boring enough to block improvisation past it.

Static Sites Fit This Job

Static sites have a useful property for public AI context: they already distinguish between source and publication.

The source tree can be messy. The built site is deliberate. Static generation says, “these are the intended published pages, from these inputs, at this commit.” It gives agent-readable context a clean substrate.

So published content generates the public contract; no second hand-maintained CMS. The article list comes from src/posts/learn and src/posts/demystify, excluding drafts. The axiom catalog comes from the public axiom data. The build catalog comes from the public build data, with private repo notes collapsed out of the public repository list unless they are actual public GitHub URLs. The route count and content hashes stay deterministic.

Quiet engineering changes the trust model. The MCP is not claiming, “trust the model’s summary of StoneyTECH.” It is claiming, “here is the same published corpus the site built, with testable hashes and counts.”

Why not just publish JSON?

The first cheaper alternative is the generated JSON itself. It stays part of the design. Anyone can fetch the contract directly from /stoneytech-public-content.v1.json.

But JSON alone pushes too much work into every client. Each IDE would need to decide how to list content, rank search results, fetch a single article, explain the public narrative, and handle boundary questions. Every client would rebuild the same little layer differently.

The second cheaper alternative is a client package. It will probably help later with tests and local development, but it remains code someone has to install and call. IDE agents do not usually import a TypeScript package in the middle of a conversation. They connect to tools.

MCP earns its place here because the public surface serves agents outside the workspace. A remote Streamable HTTP MCP gives them a boring connection shape: list content, fetch content, search content, list axioms, fetch applied evidence, explain the public narrative. It is not heavier than the problem because the problem is cross-client public context, not one script in one repo.

Drift gates keep the story honest.

The dangerous version of this project is not a dramatic breach. It is a quiet mismatch.

The site says anonymous citation-first learning. The MCP says something older. The site has thirteen articles. The MCP index has twelve. A build becomes live, but the endpoint still thinks it remains planned. A private repo note slips into a public repository list because one field looked like a URL.

Those are drift problems, and drift problems need sentinels.

The public-content test suite checks the generated contract. The MCP tests check the read-only tools against the contract. The live drift gate connects to https://public-content-mcp.stoneytech.net/mcp and verifies the public identity, article count, axiom count, build count, public repository count, canonical URLs, and deployed source commit against the site artifact.

Axiom #9 appears in small form: acceptance criteria before the artifact earns trust. Axiom #13 appears too: ship with the failure mode named. The failure mode is not “MCP broken.” The failure mode is “the MCP and the published site tell different stories.”

Clean history is part of public trust.

The eventual public repository should not be a dump of the private workspace history. It should be a clean reusable artifact: Worker source, schema, tests, README, examples, Cloudflare config, content-contract docs, and threat model.

This is not vanity. It is scope-before-sharing. If the goal is to help other teams build their own published-content MCPs, the public repo should teach the pattern without carrying private construction noise. The private StoneyTECH history can remain useful internally. The public StoneyTECH repository should be useful to a reader.

This is the difference between sharing a method and exposing a basement.

The customer pattern hiding inside it.

Once this works for StoneyTECH, the product shape is obvious enough to be dangerous, so it needs the same boundary discipline:

A customer could publish a read-only MCP for its approved public corpus: website pages, docs, public changelogs, public support articles, maybe public GitHub READMEs. Customers could connect an IDE agent and ask questions against the approved material. The MCP would cite source URLs and refuse private-data requests. The same publishing pipeline updating the site would regenerate the contract.

For private customer corpora, the shape changes. Auth comes in. Tenant boundaries come in. Retention policy comes in. The public StoneyTECH MCP does not smuggle those decisions in early. It proves the smallest version first: public, read-only, generated, testable, drift-checked.

The StoneyTECH public repository north star: not “look at this tool,” but “look at this useful boundary.”

Spirit

The future of AI-readable organizations is not every agent getting root access to every workspace. Root access everywhere is not intelligence. It is scope collapse with better autocomplete.

The better path is publication as an artifact. Decide what is public. Generate it. Hash it. Test the exclusions. Expose it through a narrow interface. Let agents help readers navigate intended published material, and require a boundary-aware answer when a question needs unpublished context.

A public MCP should not become a workspace wormhole. It should be a contract-bound projection of intentionally published material.

This sounds less glamorous than “connect the agent to everything.” Good. The boring boundary is the useful part.