Skip to main content
Glama

zkproofport-ai

by app.zkproofport.ai
OverviewDiscussionsAdmin

prove

Submit proof inputs to generate a ZK proof via the x402 single-step flow. Atomically verifies USDC payment on-chain and runs the Noir circuit in a TEE to produce a Groth16 SNARK proof.

IMPORTANT: MCP tool calls have timeout limitations that make this tool UNSUITABLE for the 30-90 second proof generation process. This tool returns a redirect message. Use the REST endpoint directly: POST https://stg-ai.zkproofport.app/api/v1/prove (staging) POST https://ai.zkproofport.app/api/v1/prove (production)

x402 SINGLE-STEP FLOW:

  1. POST /api/v1/prove with { circuit, inputs } — no payment yet

  2. Server returns 402 with nonce in body

  3. Pay USDC using nonce, get tx hash

  4. Retry POST /api/v1/prove with same body + X-Payment-TX and X-Payment-Nonce headers

REQUEST BODY SCHEMA: { "circuit": "coinbase_kyc" | "coinbase_country", "inputs": { "signal_hash": "", // 0x, 32 bytes: keccak256(abi.encodePacked(address, scope, circuitId)) "nullifier": "", // 0x, 32 bytes: privacy-preserving unique identifier "scope_bytes": "", // 0x, 32 bytes: keccak256 of the scope string "merkle_root": "", // 0x, 32 bytes: Merkle root of authorized attesters "user_address": "", // 0x, 20 bytes: the KYC wallet address "signature": "", // 65-byte hex: eth_sign(signal_hash) by KYC wallet "user_pubkey_x": "", // 32-byte hex: secp256k1 public key X coordinate "user_pubkey_y": "", // 32-byte hex: secp256k1 public key Y coordinate "raw_transaction": "", // 0x-prefixed RLP-encoded EAS attestation TX (padded to 300 bytes by server) "tx_length": , // actual byte length of raw_transaction BEFORE zero-padding "coinbase_attester_pubkey_x": "", // 32-byte hex: Coinbase attester secp256k1 X coordinate "coinbase_attester_pubkey_y": "", // 32-byte hex: Coinbase attester secp256k1 Y coordinate "merkle_proof": ["", ...], // array of 32-byte hex sibling hashes (one per tree level) "leaf_index": , // 0-based index of attester leaf in the Merkle tree "depth": , // number of levels in the Merkle tree (max 8) "country_list": ["", ...], // optional: only for coinbase_country circuit "is_included": // optional: only for coinbase_country circuit } }

VERIFIER ADDRESSES (Ethereum Mainnet, chain ID 1): coinbase_kyc (coinbase_attestation): 0xf3d5a09d2c85b28c52ef2905c1be3a852b609d0c coinbase_country (coinbase_country_attestation): 0x78792554e1582cb49d858eacb5c3607b42d28224

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputsYesAll circuit inputs required to generate the ZK proof.
circuitYesWhich circuit to use.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly warns that the tool returns a redirect message rather than a proof, explains the payment requirement, mentions the TEE execution, and provides verifier addresses. This is substantial behavior context beyond what the input schema conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly structured and front-loaded with the critical timeout warning, but it is far too long: the inline REQUEST BODY SCHEMA repeats nearly all parameter documentation that already exists in the input schema. Many sentences simply duplicate structured data and do not earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite its verbosity, the description is complete for a complex tool with no output schema. It covers the full payment protocol, the redirect behavior, timeout constraints, alternate REST endpoints, circuit choices, required input fields, and verifier addresses. An agent has enough context to decide not to call the MCP tool and to use the proper REST flow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 adds a few small extras, such as noting that raw_transaction is zero-padded to 300 bytes by the server and that verifier addresses map to specific circuits, but the large inline request body schema largely duplicates the input schema rather than adding new parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: "Submit proof inputs to generate a ZK proof via the x402 single-step flow." It further explains the mechanism (USDC payment verification, Noir circuit, TEE, Groth16 SNARK), clearly distinguishing this from the sibling get_guide and get_supported_circuits tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states that the MCP tool is UNSUITABLE due to timeout limitations and instructs the agent to use the REST endpoint instead, naming both staging and production URLs. It also provides a numbered x402 flow with exact request/response steps, leaving no ambiguity about when and how to invoke the underlying operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All zkproofport-ai toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources