CodeMani Founding access

Website → MCP · Repo → MCP · receipts attached

Agent tools that show their work.

CodeMani packs a bounded website or repository into a hash-sealed capsule and materializes it as an MCP server your agents can call. Every artifact carries a receipt any third party can replay. Everything outside the declared profile is refused, in writing.

  • Headless by design: JSON in, JSON out, typed exit codes
  • The CLI runs local with no third-party dependencies; your source stays on your machine
  • A failing check commits nothing. The output directory never appears
mcp_server_manifest.json sha256 9f3a…c21d
{
  "schema":
    "codemani.web_mcp_materialization_receipt.v1",
  "status": "PASS",
  "profile_id":
    "codemani.webpage_to_mcp.static_readonly.v1",

  "input_mani_sha256": "b21e…77aa",  # capsule, pinned
  "outputs": {
    "server_py": { "sha256": "9f3a…c21d" }
  },
  "resource_count": 1,
  "tool_count":     2,

  # smoke ran against the staged server,
  # before anything was committed
  "smoke": { "checks": 9, "passed": 9 },
  "atomic_output_committed": true
}

Sample receipt. Real receipts are generated against your content, and name exactly what they do not prove.

01 · The problem

Feeding an agent is easy now.
Trusting the feed isn’t.

Every scraper and converter can turn a website or a repo into agent context. Almost none can tell you what it included, what it silently dropped, or whether the tool it built still matches the content it came from. So teams either hand-check what their agents consume, or they don’t, and find out later.

CodeMani takes the other position: a tool is only as good as the evidence it carries. Content is admitted under an explicit profile, sealed by hash into a capsule, materialized as an MCP server, and smoke-verified before anything commits. You get a receipt for what was built, and a typed refusal for what wasn’t.

02 · How it works

Four steps, each one auditable.

1

Pack

Your page or repo is profiled and sealed into a signed .mani capsule — content, intent, and boundaries bound to exact hashes. Nothing is edited in place; the capsule is the contract.

2

Admission

A profile declares exactly what is permitted. Interactive pages, scripts, oversize inputs, and unknown shapes are rejected before a capsule is even written — with typed reasons, not warnings.

3

Materialize & verify

The capsule materializes into a read-only MCP server inside an atomic staging area. Live JSON-RPC smoke checks run against the staged server first. A failing smoke commits nothing; the destination never appears.

4

Receipt

The committed server ships with a hash-bound manifest: input capsule, output bytes, tool inventory, smoke results. An independent party can recompute every hash without asking us anything.

$ codemani web-mcp pack --html page.html --out page.mani
$ codemani web-mcp materialize --mani page.mani --out-dir server/ --smoke --smoke-query "pricing"

03 · The receipt

The deliverable is the proof.

Most vendors hand you an artifact and ask you to trust them. CodeMani hands you an artifact and a receipt that lets you trust nothing, because you can check it yourself.

  • Identity. Every input, profile, and output hash that participated. Pinned, not paraphrased.
  • Decisions. What was admitted and what was refused, with the typed reason for each refusal.
  • Verification. The smoke checks that ran against the staged output and their exact results.
  • Exclusions. Everything the profile did not cover, stated in the receipt itself.
  • Replay. The hashes and the command an independent party runs to reproduce the verification.
profile_refusal.json typed refusal
{
  "schema": "codemani.webpage_profile_receipt.v1",
  "status": "PROFILE_REQUIRED",
  "reason": "unsupported_interactive_or_script_tags",

  "unsupported_counts": { "form": 1, "script": 3 },
  "required_profile":
    "codemani.webpage_interactive_profile.v1",

  # no capsule written, no server built,
  # no best-effort guess
  "committed_files": 0
}

Refusals are deliverables too. Your agent always knows what was left out, and why.

04 · Coverage

What carries a receipt today — and what doesn’t.

We publish the boundary because the boundary is the product. Coverage grows profile by profile, and each profile is promoted only with its own evidence.

Receipt-carrying today

  • Static webpage → read-only MCP server, smoke-verified before commit
  • Repository → MCP symbol and docs context, behind explicit crawl and execution boundaries
  • Bounded Python subset → CommonJS, with direct behavior oracles

Outside the boundary

  • Interactive web apps, logins, and arbitrary crawling — typed refusal, no partial output
  • Arbitrary-language translation and autonomous production refactoring
  • Legacy-mainframe conversion — assessment under written scope only

05 · Custody engagements

What a bounded engagement delivers.

  1. Source, profile, and policy identities — hash-pinned
  2. Admitted and rejected operations, each with its reason
  3. The generated artifact — if the profile admits one
  4. Behavior-oracle and smoke results, case by case
  5. The replayable receipt and an independent verifier
  6. Rollback material for every change
  7. A plain-language list of everything that was not proved

Assessments run inside your environment: source bytes stay with you, and only aggregate counts leave. Anything beyond an assessment operates under a written scope and mutual NDA before we touch a repository.

06 · Pricing

Pay per certificate, not per promise.

The CLI is free.

web-mcp and repo-mcp pack and materialize run on your machine — no account, no third-party dependencies, receipts included. Early access while the public release gate clears.

Request the CLI

Hosted packs

$29 per 1,000 packs

The same pack-and-materialize path, run for you. For agents without a local runtime, or teams that want capsules and servers built on demand. Identical receipts to the free CLI — convenience is the only thing you’re paying for.

  • Same receipt format as the CLI
  • Typed refusals count, but cost nothing
  • Early access — capacity is limited

Custody

custom

Private engine catalogs, pinned to your infrastructure. Bounded transformation pilots and estate assessments under written scope. For teams whose auditors will read the receipts.

  • Private catalogs, BYOC deployment
  • Named engineer, written evidence cadence
  • Procurement and security paperwork supported
Talk to us

Checkout is handled by Stripe; card details never touch our servers. Prices are launch placeholders and may change. Hosted and certified lanes are early access with limited capacity — the receipt format is identical across free and paid lanes, so nothing you verify today breaks later.

07 · Questions

Straight answers.

Does “certified” mean a compliance certification?

No. A CodeMani receipt is a hash-bound, replayable record of what was built and what was verified — bytes, behavior, and decisions. Regulatory or compliance attestations are a separate matter, and we don’t claim them.

Why would I pay per certificate instead of per conversion?

Because the conversion is the cheap part — the free CLI does it on your laptop. A certificate is generated per request, bound to your exact inputs, and can’t be copied from someone else’s run. You pay when the answer has to hold up, not when bytes move.

What can you turn into MCP tools today?

Static webpages and repository symbol/docs context, each behind an explicit profile, plus a deliberately bounded Python-to-CommonJS path. Anything else fails closed with a typed refusal. Coverage grows profile by profile, never by quietly widening scope.

Do you see our source code?

The CLI runs entirely on your machine; nothing leaves it. Hosted lanes process only what you send. Assessments run in your environment with only aggregate counts leaving, and pilots operate under a mutual NDA with a written scope.

What happens when content is outside the profile?

You get a typed refusal receipt naming exactly what was declined and why — before any capsule or server is written. No silent fallbacks, no partial output, no best-effort guesses. Refusals are part of the deliverable.

How do we know a receipt is real?

Recompute it. Every receipt carries the hashes of its inputs and outputs and the command that replays the verification against the same pinned bytes. It’s designed to be checked by someone who doesn’t trust us — that’s the point of it.