Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vcc-prover Prove electricity consumption of 1500.734 using the recipe in examples/recipe.json"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Client-side Zero-Knowledge Prover MCP server and CLI toolchain for Energy Web Verified Compute.
Powered by NoirJS and bb.js (WebAssembly). Runs completely on your local machine with zero native C++ or nargo toolchain installations.
Zero-Knowledge Privacy: Private activity meter readings and CSPRNG blinding salts never leave your machine.
UltraHonk Proof Backend: State-of-the-art ZK proving via @aztec/bb.js.
Pure Node.js: Portable across macOS, Linux, and Windows (Node.js >= 20).
Claude Desktop & Cowork Ready: Includes .mcpb manifest and stdio MCP server for immediate agent integration.
Related MCP server: null-402-mcp
Download the latest vcc-prover.mcpb from GitHub Releases.
Double-click the .mcpb file to install it directly into Claude Desktop.
Open Claude Desktop and start using the status, prove, and verify tools.
Add the server definition to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"vcc-prover": {
"command": "node",
"args": [
"/path/to/vcc-prover-mcp/bin/vcc-prove-mcp.js"
]
}
}
}Clone the repository and install runtime dependencies:
git clone https://github.com/energyweb/vcc-prover-mcp.git
cd vcc-prover-mcp
npm install --omit=devRun CLI tools directly:
# Check prover status
node bin/vcc-prove.js --help
# Generate a zero-knowledge proof
node bin/vcc-prove.js --recipe examples/recipe.json --input "Electricity consumed=1500.734"
# Verify a proof package locally
node bin/vcc-verify.js --recipe examples/recipe.json --package ~/.vcc/packages/<hash>.jsonTool | Parameters | Description |
| None | Reports NoirJS and bb.js Wasm engine status and versions. |
|
| Computes Poseidon2 commitments and generates an UltraHonk proof without disclosing private readings. Takes the circuit and verifying key from the recipe. |
|
| Verifies the UltraHonk proof binary against the pinned verification key locally. |
The recipe is whatever get_workspace_instructions returned, saved to a file. It carries the
compiled circuit and the verifying key, so there is nothing to install, and the hashes those
artifacts must match, which prove checks before it does any work. It also carries
submit_via, so submit needs nothing but the path to the package prove wrote.
This prover holds no credential for the Methodology Graph and does not post anything to it.
The agent submits, by calling the Graph's own submit_proof_package with the proof as an
argument, so the ~19KB of base64 crosses a message. That means:
call prove with include_proof: true to get the bytes,
pass the package fields through as prove wrote them: package_format_version,
public_signals (already the ordered 0x array), formula, proof_sha256, toolchain,
send proof_sha256 with the proof, always. The server checks the two against each other and
refuses a mismatch rather than recording a round nobody can verify,
if it does refuse, call verify with include_proof: true for a clean copy off disk. Do not
re-prove; fresh salts make a different proof, not the same one again.
Private Data Isolation: Proof generation draws cryptographic blinding salts and computes commitments $C_X$ and $C_Y$ locally over BN254. Plaintext inputs and salts are written to ~/.vcc/private/<hash>.json with restricted file permissions (0600).
Verifiable Computation: Anyone with the public proof package can verify that the calculation adhered to the pinned formula without seeing the underlying activity volume.
MIT License.
Produce a zero-knowledge proof package from private activity data using bb.js and Noir. Writes the full package and private disclosures to disk. Returns the path to the package; does not leak salts in tool response.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | The private activity values as decimal strings, keyed by parameter name or meaning. | |
| recipe | No | The recipe object exactly as get_workspace_instructions returned it. | |
| recipe_path | No | File path to recipe.json if recipe object is not provided directly. | |
| include_proof | No | Return the raw base64 proof in the response as well as writing it to disk (default: false). Ask for it when you are the one submitting to the Methodology Graph, since submit_proof_package takes the proof as an argument. Send the proof_sha256 from the same response with it: the server checks the two against each other and refuses a proof that was altered on the way. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and handles it well: it discloses the side effect of writing the full package and private disclosures to disk, states the return value is a path, and explicitly notes that salts are not leaked in the response. It does not cover error conditions or prerequisites, but the main behavioral traits are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. It front-loads the core action, then states the side effect and return value, and ends with a critical privacy guarantee. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 params, nested objects, no output schema) and absent annotations, the description covers the essentials: what it does, what it writes to disk, what it returns, and a privacy safeguard. The schema fills in the parameter-specific details, so the description is nearly complete. It could have mentioned how the result connects to verify or next steps, but that is not critical for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema already provides; it reinforces the notion of private activity data but does not explain recipe, recipe_path, or include_proof beyond the schema's own rich descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Produce') and identifies the exact resource ('zero-knowledge proof package from private activity data'), along with implementation detail (bb.js and Noir). It clearly distinguishes from sibling tools verify and status by focusing on proof generation rather than verification or status reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a zero-knowledge proof package needs to be produced from private activity data. However, it does not explicitly contrast with verify or status, nor does it state when not to use this tool. The include_proof parameter adds a targeted use case (submitting to Methodology Graph), but that lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report toolchain status (NoirJS, bb.js) and installed formula artifacts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Report' implies a read-only inspection, and the scope is stated, but the description does not explicitly disclose side-effect-free behavior, prerequisites, or what form the status output takes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that front-loads the action ('Report') and immediately names the target areas. Every word contributes, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status command, the description is largely sufficient: it identifies what is reported and which components are covered. It could be slightly more explicit about output format or formula-artifact specifics, but the low complexity reduces the need for such detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings, and the empty schema already confirms no inputs are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and a clear resource ('toolchain status (NoirJS, bb.js) and installed formula artifacts'). It is easy to distinguish from the sibling tools 'prove' and 'verify', which perform proof actions rather than status reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is for checking the current toolchain/installation state, but it does not explicitly say when to use status versus prove or verify. There is no exclusions or alternative guidance, so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an UltraHonk proof package locally against the verifying key using bb.js without network access.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe | No | The recipe object pinning the formula and verifying key. | |
| package | No | The proof package object if package_path is not provided. | |
| recipe_path | No | File path to recipe.json if recipe object is not provided directly. | |
| package_path | No | File path to the proof package JSON written by prove. | |
| include_proof | No | Return the verified package including the raw base64 proof (default: false). This is how to read a clean copy back off disk: if submit_proof_package refuses a proof for not matching its proof_sha256, the copy was altered in transit and the one on disk is good. Do not re-prove instead; fresh salts produce a different proof, not the same one again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that verification is local and offline, which is a meaningful behavioral trait. The include_proof parameter description adds valuable behavioral context about how to recover a clean proof copy and warns against re-proving. However, with no annotations provided, the description carries the full burden and could have disclosed more about failure modes or side effects, though the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is a single, dense sentence that front-loads the core purpose and key constraint. The include_proof parameter description is longer but earns its place by explaining a non-obvious workflow and warning against a common mistake. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a verification tool with 5 parameters, 100% schema coverage, and no output schema, the description is largely complete. It explains the core operation, the offline nature, and the nuanced include_proof behavior. It could have mentioned what the tool returns on success/failure, but the absence of an output schema and the clear purpose make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds value beyond the schema by explaining the purpose of include_proof in a real workflow (reading a clean copy back off disk, avoiding re-proving). This goes beyond the schema's basic 'Return the verified package including the raw base64 proof' and justifies a score above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check'), a specific resource ('UltraHonk proof package'), the method ('locally against the verifying key using bb.js'), and a key constraint ('without network access'). This clearly distinguishes it from siblings like prove and status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to verify a proof package locally without network access. It doesn't explicitly name alternatives or exclusions, but the context of siblings (prove, status) and the clear local/offline scope provide adequate guidance. The include_proof parameter also gives practical guidance about when to use it (reading a clean copy back off disk).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0provestatusverifyScored across 3 tools
Each tool maps to a clearly distinct lifecycle stage: generating proofs, verifying proofs, and reporting environment status. There is no overlap in purpose or output.
prove and verify follow a clean verb pattern, while status is a noun rather than a verb. The naming is still predictable and readable, with only a minor deviation.
Three tools is well-scoped for a focused proving/verification utility. Each tool earns its place without unnecessary surface area.
The set covers the essential proof lifecycle: create a proof, verify a proof, and check toolchain readiness. There are no obvious gaps or dead ends for the stated purpose.
ZKEvidenceOracle - 14 zero-knowledge proof tools for compliance evidence: Groth16, PLONK.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Privacy-first document verification anchored to the public ledger.
Cryptographically anchored evidence for agents: verified run receipts, proof-gated settlement.
