Proof MCP server

Read from the package source without running it. The installed server may list more.

• add_challenge

  Record an objection (red-team challenge) against a concept, with a severity (low/medium/high) and optional one-line verdict. New objections start UNADDRESSED; every objection must be addressed before the proof gate clears. Appends to any existing challenge on the concept.

• add_conceptwrite action

  Create a new concept (Node). Set parentId whenever you know where this belongs: it becomes a CHILD of that concept and a partition edge is auto-created. Omitting parentId leaves the concept ROOTLESS (no parent at all, not the project root): rootless concepts pile up as an unreadable flat cloud, so only omit it when this genuinely is a new top-level idea. Use find_orphans + set_parent afterward to

• add_evidence

  Attach a piece of evidence to a concept: 'support' (FOR the idea) or 'counter' (AGAINST it), with the claim text and an optional source citation. Evidence is one leg of the proof gate — a concept needs at least one supporting piece to be provable.

• add_kref

  Convenience: create a k-ref (knowledge reference) edge from fromId → toId. Equivalent to link_concepts with kind=k-ref.

• add_to_idea

  Add a single concept to an existing Idea (idempotent).

• archive_concept

  Archive a concept (status=archived). Reversible via unarchive_concept.

• bulk_add_conceptswrite action

  Create many concepts in a single atomic transaction. `items` is an array; each item carries label / description? / parentId? / projectId? / sheet? / tags?. Set parentId on every item you can: an item with no parentId lands ROOTLESS, and a bulk run that leaves many concepts rootless turns the canvas into an unreadable flat cloud. project_id is resolved per-item (explicit > inherited from parent > w

• claim_handoff

  Claim a pending handoff by its run id (from list_pending_handoffs). Atomically takes ownership: the run transitions to 'running' and is attributed to this device, so it can't be double-claimed. Returns the brief to work from. After you finish, close the run with update_agent_run (status + summary + pushedRef/prUrl).

• create_ideawrite action

  Create a new Idea (a named grouping of concepts) with an optional color and optional starting node membership.

• create_projectwrite action

  Create a new Project (problem-with-direction) with a name and brief. Optional `direction`. When you add concepts under this project, set parentId on each one so it joins the semantic tree: a project full of rootless concepts reads as an unreadable flat cloud. Use find_orphans + set_parent to repair one that already has rootless concepts.

• delete_ideawrite action

  Delete an Idea. Membership rows cascade via FK; the underlying concepts are untouched.

• delete_projectwrite action

  Delete a project. By default its concepts are LEFT behind as orphans (find them later with find_orphans). Pass deleteNodes:true to also hard-delete every concept in the project (each cascades its subtree) so no orphans are created.

• expand_concept

  Recursive Branch — expand a concept by `breadth` children at each of `depth` levels (depth*breadth ≤ 60). Commits each level immediately so the webapp shows partial results as the run progresses. Optionally takes an `angle` hint that biases the underlying EXPLORE operator. Best when the anchor has few or no children yet; on a dense subtree consider `run_operator(family="explore")` so the operator

• find_concepts

  Find concepts by label/substring match. Returns up to k hits, each with id, label, status.

• find_orphans

  Surface concepts no normal traversal reaches, scoped to your workspace: 'projectless' (in no project — typically left behind by delete_project) and 'danglingParent' (parent_id points at a deleted node). Read-only. Clean up with remove_concepts (delete) or set_parent (re-home).

• get_agent_runwrite action

  Fetch one agent-run record by id (intent, status, summary, error, start/end times). Use to read the brief you were given or to confirm a status update landed.

• get_concept

  One concept by id, optionally with its ancestry (parent chain), direct children, and idea memberships.

• get_concept_proof

  Read one concept's full proving state: its evidence, the challenge objections, which project criteria it meets, any recorded proof, and the computed proof gate (what still blocks validation).

• get_project_graph

  Every node + edge inside one project. Returns a graph the agent can reason over end-to-end. Use for project-wide questions.

• get_runwrite action

  Fetch an async operator run by its runId. Returns { status: "running" | "done" | "error" }; when "done", the `result` field holds the operator output (candidates / committedIds). Waits up to ~8s for completion before returning, so a simple poll loop converges fast. run_operator / run_operator_and_commit / expand_concept hand back a runId whenever their work exceeds the ~8s fast-path window.

• get_subtree

  A node and its descendants up to a given depth. Pass the concept as `id` (or `rootId`). Use when the user asks "tell me about everything under X".

• get_verification_record

  Fetch one full verification record (its per-file outcomes: cleared / approved / flagged, with reasons and notes). Read-only.

• get_workspace_summary

  Counts of nodes / edges / projects / ideas + a one-line overview of each project and idea. Always start here when you don't know what's in the workspace.

• link_conceptswrite action

  Create an edge between two concepts. kind is one of: 'k-ref' (knowledge reference), 'derived-from' (provenance link), 'semantic-adjacency' (sibling kinship). Partition (parent/child) edges are managed via add_concept / set_parent.

• list_agent_runs

  List agent runs newest-first, optionally narrowed to one project. Use to see recent runs and their outcomes.

• list_concepts

  List concepts in the workspace or one project. Returns id / label / status / parentId / tags up to `limit` entries (default 500). Use BEFORE making changes to learn what already exists.

• list_edges

  List every edge in the workspace (or restricted to a project). Filter by kind: partition / k-ref / semantic-adjacency / derived-from / imported-from.

• list_pending_handoffs

  List PENDING handoffs (queued agent runs) the user sent from Proof for THIS device to pick up. Each entry carries the full build brief (problem, concepts to build, acceptance criteria, things to avoid) so you can start immediately. Call this at the start of a session — if a handoff is waiting, claim it with claim_handoff and begin. Includes untargeted handoffs by default.

• list_projects

  Every project in the workspace with brief, direction, lifecycle, and node count. Use this to figure out which project the user is asking about.

• list_proofs

  List the proving snapshot for every concept that has any proving state — across the workspace, or restricted to one project (which also reports criteria coverage). Each entry shows support/counter counts, challenge progress, criteria met, and whether the gate is ready.

• list_recent_decisions

  Nodes the user has explicitly resolved (validated, starred, or archived) recently. Use to surface "what did we conclude last week" without a full scan.

• list_sheets

  List one project's sheets (canvas pages) — id, name, and order, excluding deleted sheets. Nodes with no sheet render on the project's default sheet. Pass a listed name or id as `sheet` to add_concept / bulk_add_concepts to place new concepts on a specific sheet.

• list_verification_records

  List the SIGNED verification records (human code-review sign-offs) across the workspace or one project, newest-first. Read-only: this is the human's accountable record — the agent inspects it, it cannot create one.

• recolor_idea

  Change an Idea's color (any CSS color string).

• record_proof

  Record a concept's proof and promote it to validated. Snapshots the proof gate (support, criteria met, objections addressed) into a durable proof record. Refuses when the gate isn't clear and returns the blockers; pass force:true to record anyway. The signer is the authenticated user.

• remove_conceptwrite action

  Hard-delete a concept and its descendants (walks the subtree via parent_id AND partition edges). Edges and project/idea memberships cascade via FK. Refuses to delete a project root node. For many at once, use remove_concepts.

• remove_conceptswrite action

  Bulk hard-delete: delete many concepts in one call (each cascades its own subtree). Returns per-id results. Ids already swept up in another id's cascade come back ok:false (not-found) — expected, not fatal. Pair with find_orphans for cleanup.

• rename_idea

  Rename an Idea.

• run_operatorwrite action

  Run an ASIT / TRIZ / Contradiction / Free / Combine / Explore operator against one concept (the anchor). Returns CANDIDATE concepts WITHOUT committing them — call `bulk_add_concepts` (or `run_operator_and_commit`) to persist. Use this when you want the agent to vet the candidates before writing. The anchor must already live in a project; the operator pulls in ancestry + validated knowledge in the

• run_operator_and_commitwrite action

  Same as `run_operator`, but immediately writes every top-level candidate as a child of the anchor with a partition edge and a provenance row stamped origin='mcp'. Use when the agent is confident the candidates should land directly on the canvas (e.g. inside an autonomous expand loop). Children-of-children proposed in `partitions[].children` are NOT auto-committed — request them via a separate run.

• search_concepts

  Substring search across concept labels, descriptions, partition attributes, rationale, and tags. Use this when the user mentions a concept by name and you don't have its id. (Semantic search is a Phase 19.5 enhancement.)

• set_idea_members

  Replace an Idea's full membership with `nodeIds`. Reconciles the junction table: inserts missing pairs, deletes pairs no longer in the set. Returns added / removed counts.

• set_parent

  Re-parent an existing concept: nodeId's parent becomes newParentId (or detached when null). Updates BOTH node.parent_id AND the partition edge so the canvas tree stays in sync.

• set_project_criteria

  Replace a project's success criteria with `criteria` (plain sentences) — the gate record_proof checks before a concept can be validated. Merges by text: a sentence already on the project keeps its existing criterion id (so concepts that meet it stay met), new sentences mint new criteria, and sentences you leave out are removed. Returns the resulting list.

• set_project_identity

  Set a project's IDENTITY — one plain sentence stating what the project fundamentally does for its user — and optionally the design `dimensions` its concept decomposition runs along. The webapp's identity-first analysis writes these too, so only set them when asked or when they are empty (check get_project_graph).

• set_standing

  Set a concept's STANDING — how known / proven the idea is in the wider world. `standing` ∈ 'novel' | 'emerging' | 'established' | 'unknown'. `rationale` is a one-sentence justification (saved as `standing_rationale`). Use this when classifying / judging novelty.

• star_concept

  Toggle the starred flag on a concept (user-favorite marker).

• submit_review_summarywrite action

  Attach the agent's OWN review notes to its run so the human reviewer sees them BEFORE signing off: a summary of what changed, the risks you see, and any files a human should inspect closely. This is inspect + assist only — it does NOT create or sign a verification record (the human's accountable act stays in the Verify surface).

• unarchive_concept

  Revive a previously-archived concept (status=open). Idempotent on already-open nodes.

• update_agent_runwrite action

  Update the agent-run row you were handed (its id is on the handoff brief as "Agent run id"). Set status to running / succeeded / failed / cancelled and optionally a result summary or error. When you finish, also report pushedRef (the branch you pushed) and/or prUrl (the PR you opened) so the human can review the exact diff, and verificationRecordId once a record is signed. A terminal status stamps

• update_conceptwrite action

  Update an existing concept's label, description, tags, partitionAttribute, rationale, or status. Only the fields provided are changed.

• update_projectwrite action

  Update a project's name / brief / direction / lifecycle. Only fields provided are changed.

• validate_concept

  Mark a concept as validated (status=validated). Optionally also overwrite `rationale`. Idempotent on already-validated nodes.

• Code scan33 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitylocal package, no credentials required12/15
• Maintenancelast push 20 days ago15/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

92/100

higher than 90% of 4,460 AI and agents servers

Tools

53

the typical AI and agents server has 6

Tools that change things

32%

typical: 0%. Fewer write tools means less an agent can break

Downloads a week

35

more than 25% of 1,538 AI and agents servers with a package

Proof: common questions

Is Proof MCP server safe?

Yes, by our scan: it is graded A (92/100). Read the Proof safety report

How do I install Proof?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does Proof need an API key?

Not as far as the registry entry and our scan can tell: no credentials are declared or required.

Is Proof maintained?

The last commit was 61 days ago (2026-09-04). The latest release is v1.0.0.

What can I use instead of Proof?

Servers from other publishers that do the same job: SuperCompress MCP server, CHAP Coordinator MCP server and three.ws Provenance MCP server.

How does Proof compare with other AI and agents MCP servers?

safety score 92/100 (higher than 90% of 4,460 AI and agents servers); tools 53 (the typical AI and agents server has 6); tools that change things 32% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.