Skip to main content
Glama

certified-mcp

ci license python tests mcp

Give your agent something it cannot talk its way past.

An MCP server exposing certificate verification, equivalence proving, and pre-registration sealing as tools. An agent that edits a design, a proof, or a benchmark config has no way to check its own work — so it reports success. These tools return a verdict re-derived from the artifact, not asserted about it.

Install

pip install "certified-mcp @ git+https://github.com/nickharris808/certified-mcp.git@main"

Not on PyPI yet. The name certified-mcp is unregistered, so pip install certified-mcp installs nothing today — use the line above, which installs exactly the same code. When the package is published this note goes and the plain name works.

Its four dependencies are declared as git references, so that one line pulls them too.

Related MCP server: agent-gate

30-second quickstart

Add to your MCP client config (Claude Desktop, Cursor, or any MCP host):

{
  "mcpServers": {
    "certified": { "command": "certified-mcp" }
  }
}

Then ask your agent something it would otherwise have to guess at:

"I refactored this adder. Prove it's still equivalent to the original."

prove_equivalence(inputs=["a","b"], circuit_a=[...], circuit_b=[...])
-> {"verdict": "EQUIVALENT", "receipt_verifies": true}

Or, when it isn't:

-> {"verdict": "COUNTEREXAMPLE", "counterexample": {"1": true, "2": false}}

The agent gets a concrete failing input, not "this appears correct."

Tools

Tool

What it does

verify_certificate

Re-derives a manufacturing admission verdict from the certificate's own numbers; checks integrity; refuses a bundle that certifies nothing

explain_certificate

Turns a REFUTED/REJECT verdict into a specific list: which loci are safe, unsafe or straddling, the margin each had, the margin it needed, and how far short it fell. Computes nothing new — it re-presents the arithmetic the verdict already rests on

verify_receipt

Re-runs a DRAT proof (or re-simulates a counterexample) over the committed formula

prove_equivalence

Proves two small combinational circuits equivalent, or returns a differing input

check_drat

Checks a DRAT refutation from any solver; names the first lemma that doesn't follow

seal_criteria

Seals acceptance criteria before measuring, without revealing them

check_seal

Detects criteria changed after sealing

score_verifier

Scores a verifier against the failure atlas

explain_defect

Explains a defect class: why the forgery looks valid, and what catches it

Why an agent benefits specifically

Three failure modes this addresses directly:

  1. Confident wrongness. An agent that refactors logic will say it preserved behaviour. prove_equivalence returns a counterexample input when it didn't.

  2. Moving the goalposts. An agent tuning against a benchmark will quietly relax the threshold. seal_criteria before the run makes that detectable — including by the agent itself.

  3. Trusting a proof it was handed. check_drat accepts proofs from any solver and re-checks every lemma, so a fabricated proof is caught rather than cited.

Everything here is local and read-only

No network. Nothing uploaded. No telemetry. Every tool either reads a file you name or computes over arguments you pass.

None of these tools can produce a manufacturing certificate — only check one. That asymmetry is deliberate and is enforced by a test. Checking is cheap and should be everywhere; producing a certificate worth checking requires the certification engine, which is a separate closed product.

Implementation

Standard library only, MCP stdio protocol, ~300 lines. You can read the whole server before deciding to run it — which, for something you are wiring into an agent with filesystem access, you should.

Licence

Apache-2.0.

Honest scope — what these tools prove, and what they do not

Question

Answer

Can an agent check a certificate, proof or seal with these?

Yes, all locally and read-only.

Does verify_certificate returning UNVERIFIED mean the certificate is bad?

No. It means the tool abstained for want of a trust anchor. An agent must not report it as either pass or fail.

Can any tool here produce a certificate?

No — enforced by a test. These are checkers.

Does anything here validate physics?

Never.


The rest of the toolkit

A recorded verdict is a claim to be checked, never an input to be trusted. Nine repositories are built on it.

The whole story, and the objections answered, live at certified-oss — start there if this is the first one you have opened.

lcert-verify

Re-derive a manufacturing certificate's verdict. Stdlib only.

equiv-receipt

Prove two circuits equivalent, with a receipt anyone can re-check.

prereg-seal

Seal acceptance criteria before you measure.

cert-atlas

28 labelled forgeries and a metric no degenerate verifier can win.

certified-mcp

The above, as tools your AI agent can call.

lcert-verify-web

The verifier in a browser. Nothing uploaded.

Try it now, no install: 🔏 the verifier Space · Browse the forgeries: 📊 the atlas dataset

Where the free edition stops

Everything here checks. None of it produces a certificate that is physically meaningful — that needs sound enclosures over real process models, which is a separate commercial product. If you need certificates rather than a way to check them, that is the conversation to have.

Documentation

Portfolio-wide: Tutorial · Concepts · FAQ · Architecture · API reference

Licence, citation, contributing

Apache-2.0 — see LICENSE. If you use this, please cite it: CITATION.cff.

The most valuable contribution is a forgery this project fails to catch — see CONTRIBUTING.md and the portfolio-wide guide.


A recorded verdict is a claim to be checked, never an input to be trusted.

certified-mcp is one of nine repositories built on that. The whole story, and the objections answered, live at certified-oss — start there if this is the first one you have opened.

Available Tools

9 tools
check_dratA

Check a DRAT refutation against a CNF in DIMACS form. Accepts proofs from any solver. Returns whether every lemma is RUP and, on failure, the index and content of the first lemma that does not follow.

Inputs: cnf_path (required), drat_path (required).

check_sealA

Check that an acceptance specification still matches its seal. Detects criteria that were changed after sealing. Returns matched=false with the two digests if they diverge.

Inputs: spec (required), seal, seal_path.

explain_certificateA

Explain WHY a certificate reached its verdict, locus by locus: which loci are safe, unsafe or straddling, the margin each had, the margin it needed, and how far short it fell. Use this after verify_certificate returns REFUTED or a certificate records a REJECT — it turns an opaque refusal into a specific, actionable list. Computes nothing new; it re-presents the arithmetic the verdict already rests on.

Inputs: bundle_dir (required), limit.

explain_defectA

Explain a certificate defect class from the atlas taxonomy: why the forgery looks valid, and which check catches it. Call with no key to list every defect.

Inputs: key.

prove_equivalenceA

Prove two small combinational circuits equivalent, or return a counterexample input. Circuits are given as gate lists over named signals. Returns a receipt any third party can re-check. Small instances only — this is a demonstration prover, not a production one.

Inputs: inputs (required), circuit_a (required), circuit_b (required), out_path.

score_verifierA

Score a verifier command against the certificate failure atlas. Returns detection (forgeries rejected), precision (valid artifacts accepted), and atlas_score = the minimum of the two, plus exactly which forgeries got through.

Inputs: command (required), atlas_dir (required).

seal_criteriaA

Seal an acceptance specification BEFORE measuring, so it cannot be adjusted afterward. Returns a digest that commits to the criteria without revealing them. Call this before running an experiment, not after.

Inputs: spec (required), note, out_path.

verify_certificateA

Verify a manufacturing certificate bundle. Re-derives the admission verdict from the certificate's own numbers rather than reading it, and checks integrity. Returns a verdict: VERIFIED, REFUTED, VACUOUS, or UNVERIFIED. IMPORTANT: without an expected_sha256 (a fingerprint obtained OUT OF BAND, not from the bundle itself) the verdict is UNVERIFIED — the tool abstains, because internal consistency alone cannot rule out a forgery whose inputs and verdict were edited together. UNVERIFIED means 'cannot tell', NOT 'the certificate is bad'. Do not report it as either pass or fail.

Inputs: bundle_dir (required), allow_empty, expected_sha256, accept_without_anchor.

verify_receiptA

Verify a logic-equivalence receipt. Re-runs the DRAT proof check (or re-simulates the counterexample) over the committed formula, and recomputes the hash chain. The verdict is re-derived, never read from the receipt.

Inputs: receipt_path (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.1/5.0

    Scored across 9 tools

    Disambiguation4/5

    Most tools have distinct purposes, but the verify_* family (verify_certificate, verify_receipt) and check_drat all involve checking proofs, which could cause confusion. However, the descriptions clearly differentiate artifact types and workflows.

    Naming Consistency5/5

    Tool names consistently follow a verb_noun pattern (e.g., verify_certificate, check_drat, explain_defect). No mixed conventions or vague verbs; every name conveys its action and target.

    Tool Count5/5

    With 9 tools, the server is well-scoped for a certification/verification domain. Each tool serves a clear role, and the count is within the ideal 3-15 range.

    Completeness4/5

    The toolset covers the core verification lifecycle: proving, checking, verifying, explaining, and sealing. Minor gaps exist (e.g., no tool to create certificates or manage the atlas), but these are likely external to this server's purpose.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      An MCP server that provides fact-checking capabilities and truth anchoring for AI agents using verified data sources.
      MIT
    • A
      license
      B
      quality
      C
      maintenance
      An MCP server that enforces fail-closed deterministic checks, independent refute-first review, and tamper-evident hash-chained receipts for AI agent outputs before claiming completion.
      4
      3
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      MCP server that enables AI agents to verify each other's trust scores, register, submit reviews, and find trusted agents before transacting.
      4
      20 npm
      MIT