zkproofport-ai

generate_proof

Generate a zero-knowledge proof in a single call to validate identity claims—Coinbase KYC, country, OIDC domain, Arc eligibility, or GIWA attestation—without exposing personal data.

Instructions

All-in-one ZK proof generation. Handles: prepare inputs, request challenge, and submit proof in a single call. Use this when you want the simplest path to a proof. For fine-grained control over each step, use prepare_inputs, request_challenge, and submit_proof individually.

CIRCUITS:

"coinbase_kyc": Proves the user passed Coinbase KYC verification.
"coinbase_country": Proves the user's country of residence is (or is not) in a given list. Requires country_list and is_included.
"oidc_domain": Proves the user authenticated via OIDC and their email belongs to a specific domain. Requires jwt and scope.
"arc_eligibility": Coinbase KYC, optionally binding the wallet's signature to ONE EIP-712 action. Without action it signs the request signal hash. The proof carries that action's hash, so a contract can check WHICH instruction was authorised -- not merely that somebody eligible signed something. Verified on Arc Testnet (chain 5042002).
"giwa_attestation": GIWA attestation, optionally binding one EIP-712 action. Uses a GIWA-attested wallet; verified on GIWA Sepolia (chain 91342).

WITH ACTION: Returns awaiting_approval with an approval URL for the HUMAN to review and sign in their wallet. Keep the request parameters unchanged, query get_action_approval, then repeat with approval_id when approved. ATTESTATION_KEY cannot authorize an action on the human's behalf. Ordinary proofs without action retain automatic signing.

RETURNS: awaiting_approval or the full ProofResult with proof bytes, public inputs, and timing information. Use verify_proof separately to verify on-chain.

Input Schema

TableJSON Schema

Name	Required	Description
`jwt`	No	OIDC JWT token (id_token) for oidc_domain circuit
`scope`	No	Scope string for nullifier derivation. Defaults to "proofport" if omitted. For oidc_domain circuit, this is the domain scope string.
`action`	No	The EIP-712 action to authorise. Optional for arc_eligibility and giwa_attestation; rejected for other circuits. Any structure is provable: the circuit hashes it without reading it, so a deposit, a grant of authority or an agreement in prose all work. The wallet signs exactly these fields, and the proof carries their hash.
`pay_on`	No	Which chain to pay on: a CAIP-2 id ("eip155:5042002") or a plain name ("arc-testnet", "arc-testnet-nano", "base-sepolia"). Call request_challenge to see what a service offers. Omitted takes the first chain offered. The payer signs an authorization and the service settles it, so no gas or native balance is needed on the paying chain -- only USDC. "arc-testnet-nano" is Arc nanopayments: the authorization goes to Circle Gateway, which verifies it off chain in under a second and settles it later in a batch with thousands of others, so the gas per payment approaches zero. It requires a Gateway balance -- deposit first with the deposit_to_gateway tool -- and is the right choice for an agent buying many proofs. "arc-testnet" settles each payment on chain immediately and costs gas every time.
`circuit`	Yes	Which circuit to use
`pay_with`	No	Which wallet pays, when the service charges. "arc" is an Arc agent wallet — Circle holds it, it carries spending policies the agent cannot ignore, and Circle CLI signs with it (install: npm i -g @circle-fin/cli, then circle wallet login <email> --testnet). "key" signs with PAYMENT_PRIVATE_KEY. "cdp" uses a Coinbase CDP server wallet (CDP_API_KEY_ID, CDP_API_KEY_SECRET, CDP_WALLET_SECRET). "circle" uses a Circle developer-controlled wallet (CIRCLE_API_KEY, CIRCLE_ENTITY_SECRET, CIRCLE_WALLET_ID) when that wallet supports the selected offer. Omit it and the single configured wallet is used; omit it with none configured against a paying service and the error names what to set. Wallet and chain are separate choices; both must support the actual offered signing domain.
`provider`	No	OIDC provider. "google" (default) for Google Workspace, "microsoft" for Microsoft 365.
`approval_id`	No	Resume the SAME original action request using the approval_id returned with awaiting_approval. Keep all original parameters unchanged.
`is_included`	No	true = prove country IS in list, false = prove NOT in list. Required for coinbase_country circuit.
`max_payment`	No	Maximum USDC proof fee allowed by the user.
`country_list`	No	ISO 3166-1 alpha-2 country codes. Required for coinbase_country circuit.
`approved_payment`	No	Exact user-approved terms. For direct EIP-3009 set extra.verifyingContract to the offer asset; for Gateway copy its required extra.verifyingContract. Changed fee, recipient, token, chain or signing domain is rejected before signing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.45Sep 23, 2026

addedInput schema / properties / approval_id

Added value: +{
+  "description": "Resume the SAME original action request using the approval_id returned with awaiting_approval. Keep all original parameters unchanged.",
+  "type": "string"
+}

Changed3 schema fields changedv0.2.44Sep 22, 2026

changedInput schema / properties / action / description

Previous value: -"The EIP-712 action to authorise. Required for arc_eligibility and rejected for every other circuit. Any structure is provable: the circuit hashes it without reading it, so a deposit, a grant of authority or an agreement in prose all work. The wallet signs exactly these fields, and the proof carries their hash."New value: +"The EIP-712 action to authorise. Optional for arc_eligibility and giwa_attestation; rejected for other circuits. Any structure is provable: the circuit hashes it without reading it, so a deposit, a grant of authority or an agreement in prose all work. The wallet signs exactly these fields, and the proof carries their hash."

changedInput schema / properties / approved_payment / description

Previous value: -"Exact user-approved terms. The SDK rejects any changed fee, recipient, token, chain or Gateway signing domain before signing the actual challenge."New value: +"Exact user-approved terms. For direct EIP-3009 set extra.verifyingContract to the offer asset; for Gateway copy its required extra.verifyingContract. Changed fee, recipient, token, chain or signing domain is rejected before signing."

changedInput schema / properties / circuit / enum

Previous value: -[
-  "coinbase_kyc",
-  "coinbase_country",
-  "oidc_domain",
-  "arc_eligibility"
-]New value: +[
+  "coinbase_kyc",
+  "coinbase_country",
+  "oidc_domain",
+  "arc_eligibility",
+  "giwa_attestation"
+]

Changed6 schema fields changedv0.2.43Sep 15, 2026

addedInput schema / properties / action

Added value: +{
+  "additionalProperties": false,
+  "description": "The EIP-712 action to authorise. Required for arc_eligibility and rejected for every other circuit. Any structure is provable: the circuit hashes it without reading it, so a deposit, a grant of authority or an agreement in prose all work. The wallet signs exactly these fields, and the proof carries their hash.",
+  "properties": {
+    "domain": {
+      "additionalProperties": false,
+      "properties": {
+        "chainId": {
+          "type": "number"
+        },
+        "name": {
+          "type": "string"
+        },
+        "verifyingContract": {
+          "type": "string"
+        },
+        "version": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "name",
+        "version",
+        "chainId",
+        "verifyingContract"
+      ],
+      "type": "object"
+    },
+    "message": {
+      "additionalProperties": {},
+      "type": "object"
+    },
+    "primaryType": {
+      "type": "string"
+    },
+    "types": {
+      "additionalProperties": {
+        "items": {
+          "additionalProperties": false,
+          "properties": {
+            "name": {
+              "type": "string"
+            },
+            "type": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "name",
+            "type"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "domain",
+    "types",
+    "primaryType",
+    "message"
+  ],
+  "type": "object"
+}

addedInput schema / properties / approved_payment

Added value: +{
+  "additionalProperties": false,
+  "description": "Exact user-approved terms. The SDK rejects any changed fee, recipient, token, chain or Gateway signing domain before signing the actual challenge.",
+  "properties": {
+    "amount": {
+      "pattern": "^\\d+$",
+      "type": "string"
+    },
+    "asset": {
+      "type": "string"
+    },
+    "extra": {
+      "additionalProperties": false,
+      "properties": {
+        "name": {
+          "type": "string"
+        },
+        "verifyingContract": {
+          "type": "string"
+        },
+        "version": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "name",
+        "version",
+        "verifyingContract"
+      ],
+      "type": "object"
+    },
+    "network": {
+      "type": "string"
+    },
+    "payTo": {
+      "type": "string"
+    },
+    "scheme": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "network",
+    "scheme",
+    "amount",
+    "asset",
+    "payTo",
+    "extra"
+  ],
+  "type": "object"
+}

changedInput schema / properties / circuit / enum

Previous value: -[
-  "coinbase_kyc",
-  "coinbase_country",
-  "oidc_domain"
-]New value: +[
+  "coinbase_kyc",
+  "coinbase_country",
+  "oidc_domain",
+  "arc_eligibility"
+]

addedInput schema / properties / max_payment

Added value: +{
+  "description": "Maximum USDC proof fee allowed by the user.",
+  "pattern": "^\\d+(\\.\\d{1,6})?$",
+  "type": "string"
+}

addedInput schema / properties / pay_on

Added value: +{
+  "description": "Which chain to pay on: a CAIP-2 id (\"eip155:5042002\") or a plain name (\"arc-testnet\", \"arc-testnet-nano\", \"base-sepolia\"). Call request_challenge to see what a service offers. Omitted takes the first chain offered. The payer signs an authorization and the service settles it, so no gas or native balance is needed on the paying chain -- only USDC. \"arc-testnet-nano\" is Arc nanopayments: the authorization goes to Circle Gateway, which verifies it off chain in under a second and settles it later in a batch with thousands of others, so the gas per payment approaches zero. It requires a Gateway balance -- deposit first with the deposit_to_gateway tool -- and is the right choice for an agent buying many proofs. \"arc-testnet\" settles each payment on chain immediately and costs gas every time.",
+  "type": "string"
+}

addedInput schema / properties / pay_with

Added value: +{
+  "description": "Which wallet pays, when the service charges. \"arc\" is an Arc agent wallet — Circle holds it, it carries spending policies the agent cannot ignore, and Circle CLI signs with it (install: npm i -g @circle-fin/cli, then circle wallet login <email> --testnet). \"key\" signs with PAYMENT_PRIVATE_KEY. \"cdp\" uses a Coinbase CDP server wallet (CDP_API_KEY_ID, CDP_API_KEY_SECRET, CDP_WALLET_SECRET). \"circle\" uses a Circle developer-controlled wallet (CIRCLE_API_KEY, CIRCLE_ENTITY_SECRET, CIRCLE_WALLET_ID) when that wallet supports the selected offer. Omit it and the single configured wallet is used; omit it with none configured against a paying service and the error names what to set. Wallet and chain are separate choices; both must support the actual offered signing domain.",
+  "enum": [
+    "key",
+    "cdp",
+    "circle",
+    "arc"
+  ],
+  "type": "string"
+}

First observedv0.2.9Apr 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries full behavioral disclosure. It explains that the tool is a composite flow, returns either awaiting_approval or a full ProofResult with timing info, and requires human approval for action-bound proofs while ordinary proofs auto-sign. It also notes that ATTESTATION_KEY cannot authorize actions, which is a critical limitation. This is thorough and goes beyond basic operation.

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

Conciseness4/5

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

The description is lengthy but well-structured with clear sections (CIRCUITS, WITH ACTION, RETURNS) and front-loaded with the core purpose. The length is justified by the complexity of the tool (12 parameters, 5 circuits, action approval flow). It is not wasteful; every section contributes necessary information.

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?

For a tool with 12 parameters, nested objects, multiple circuits, and a two-step approval flow, the description covers all essential aspects: the combined operation, circuit-specific requirements, the action binding behavior, return types, and the separate verify_proof step. It is sufficiently complete for an agent to decide when to use it and how to handle the flows.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description does not need to repeat parameter details. It adds value by tying parameters to circuits (e.g., 'Requires country_list and is_included' for coinbase_country, 'Requires jwt and scope' for oidc_domain) and by explaining the approval_id flow and the action parameter's role. This supplements the schema descriptions with cross-parameter context.

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 states a clear purpose: 'All-in-one ZK proof generation' that combines three steps (prepare inputs, request challenge, submit proof) in a single call. It explicitly differentiates itself from the individual step tools by naming them as alternatives for fine-grained control. The circuit list also clarifies the specific use cases.

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?

Explicit guidance is given: 'Use this when you want the simplest path to a proof. For fine-grained control over each step, use prepare_inputs, request_challenge, and submit_proof individually.' It also provides circuit-specific requirements (e.g., coinbase_country requires country_list and is_included) and explains the action approval flow, including when to query get_action_approval and reuse approval_id.

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

Deploy Server

generate_proof

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools