Skip to main content
Glama
Sign In
zkproofport-ai

zkproofport-ai

by zkproofport
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

generate_proof

Generate zero-knowledge proofs in one call by preparing inputs, requesting a challenge, and submitting proof, so AI agents can prove identity claims 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, optionally binding the wallet's signature to ONE EIP-712 action (as giwa_attestation). Without action it signs the request signal hash.

  • "coinbase_country": Proves the user's country of residence is (or is not) in a given list, optionally binding the wallet's signature to ONE EIP-712 action (as coinbase_kyc). 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.

  • "human_passport": Proves the wallet holds an unexpired Human Passport score at or above min_score, without revealing the wallet or the exact score; optionally binds ONE EIP-712 action (as coinbase_kyc). Requires min_score and chain (the chain id the person recorded the score on).

  • "giwa_attestation": GIWA attestation, optionally binding the wallet's signature to ONE EIP-712 action. Without action it signs the request signal hash. With one, the proof carries that action's hash, so a contract can check WHICH instruction was authorised -- not merely that somebody eligible signed something. 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

NameRequiredDescriptionDefault
jwtNoOIDC JWT token (id_token) for oidc_domain circuit
chainNoRequired for human_passport: the chain id the Human Passport score is recorded on -- 8453 Base, 10 OP Mainnet, 42161 Arbitrum One, 59144 Linea, 534352 Scroll, 324 zkSync Era. Ask the user; there is no default.
scopeNoScope string for nullifier derivation. Defaults to "proofport" if omitted. For oidc_domain circuit, this is the domain scope string.
actionNoThe EIP-712 action to authorise. Optional for coinbase_kyc, coinbase_country, giwa_attestation and human_passport; 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_onNoWhich chain to pay on: a CAIP-2 id ("eip155:84532") or a plain name ("base-sepolia", "ethereum-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.
circuitYesWhich circuit to use
pay_withNoWhich wallet pays, when the service charges. "key" signs with PAYMENT_PRIVATE_KEY. "cdp" uses a Coinbase CDP server wallet (CDP_API_KEY_ID, CDP_API_KEY_SECRET, CDP_WALLET_SECRET). 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.
providerNoOIDC provider. "google" (default) for Google Workspace, "microsoft" for Microsoft 365.
min_scoreNoRequired for human_passport: the Human Passport score threshold in points (e.g. 20; above 0, at most four decimals). The server finds the wallet's score on the chain named by `chain` and refuses, before payment, a wallet with none or below it.
approval_idNoResume the SAME original action request using the approval_id returned with awaiting_approval. Keep all original parameters unchanged.
is_includedNotrue = prove country IS in list, false = prove NOT in list. Required for coinbase_country circuit.
max_paymentNoMaximum USDC proof fee allowed by the user.
country_listNoISO 3166-1 alpha-2 country codes. Required for coinbase_country circuit.
approved_paymentNoExact user-approved terms. Set extra.verifyingContract to the offer asset (EIP-3009). Changed fee, recipient, token, chain or signing domain is rejected before signing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.50
    • addedInput schema / properties / chain
      Added value: +{
+  "description": "Required for human_passport: the chain id the Human Passport score is recorded on -- 8453 Base, 10 OP Mainnet, 42161 Arbitrum One, 59144 Linea, 534352 Scroll, 324 zkSync Era. Ask the user; there is no default.",
+  "type": "number"
+}
    • changedInput schema / properties / min_score / description
      Previous value: -"Required for human_passport: the Human Passport score threshold in points (e.g. 20; above 0, at most four decimals). The server finds the wallet's score on Base and refuses, before payment, a wallet with none or below it."New value: +"Required for human_passport: the Human Passport score threshold in points (e.g. 20; above 0, at most four decimals). The server finds the wallet's score on the chain named by `chain` and refuses, before payment, a wallet with none or below it."
  2. Changed3 schema fields changedv0.2.49
    • changedInput schema / properties / action / description
      Previous value: -"The EIP-712 action to authorise. Optional for coinbase_kyc, coinbase_country 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."New value: +"The EIP-712 action to authorise. Optional for coinbase_kyc, coinbase_country, giwa_attestation and human_passport; 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 / circuit / enum
      Previous value: -[
-  "coinbase_kyc",
-  "coinbase_country",
-  "oidc_domain",
-  "giwa_attestation"
-]New value: +[
+  "coinbase_kyc",
+  "coinbase_country",
+  "oidc_domain",
+  "giwa_attestation",
+  "human_passport"
+]
    • addedInput schema / properties / min_score
      Added value: +{
+  "description": "Required for human_passport: the Human Passport score threshold in points (e.g. 20; above 0, at most four decimals). The server finds the wallet's score on Base and refuses, before payment, a wallet with none or below it.",
+  "type": "number"
+}
  3. Changed1 schema field changedv0.2.48
    • changedInput schema / properties / action / description
      Previous value: -"The EIP-712 action to authorise. Optional for 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."New value: +"The EIP-712 action to authorise. Optional for coinbase_kyc, coinbase_country 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."
  4. Changed6 schema fields changedv0.2.46
    • changedInput schema / properties / action / description
      Previous 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."New value: +"The EIP-712 action to authorise. Optional for 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. 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."New value: +"Exact user-approved terms. Set extra.verifyingContract to the offer asset (EIP-3009). 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",
-  "giwa_attestation"
-]New value: +[
+  "coinbase_kyc",
+  "coinbase_country",
+  "oidc_domain",
+  "giwa_attestation"
+]
    • changedInput schema / properties / pay_on / description
      Previous value: -"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."New value: +"Which chain to pay on: a CAIP-2 id (\"eip155:84532\") or a plain name (\"base-sepolia\", \"ethereum-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."
    • changedInput schema / properties / pay_with / description
      Previous value: -"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."New value: +"Which wallet pays, when the service charges. \"key\" signs with PAYMENT_PRIVATE_KEY. \"cdp\" uses a Coinbase CDP server wallet (CDP_API_KEY_ID, CDP_API_KEY_SECRET, CDP_WALLET_SECRET). 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."
    • changedInput schema / properties / pay_with / enum
      Previous value: -[
-  "key",
-  "cdp",
-  "circle",
-  "arc"
-]New value: +[
+  "key",
+  "cdp"
+]
  5. Changed1 schema field changedv0.2.45
    • 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"
+}
  6. Changed3 schema fields changedv0.2.44
    • 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"
+]
  7. Changed6 schema fields changedv0.2.43
    • 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"
+}
  8. First observedv0.2.9

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does most of it well: it discloses the awaiting_approval state machine (keep parameters unchanged, call get_action_approval, retry with approval_id), the signing-authority constraint that ATTESTATION_KEY cannot authorize for the human, and the auto-signing behavior for action-less proofs. It stops short of covering failure handling, idempotency, or whether payment is captured when the request parks in awaiting_approval.

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 purpose and the sibling alternative are front-loaded before the long circuit catalogue, and headers (CIRCUITS, WITH ACTION, RETURNS) make the block skimmable. For a 14-parameter, five-circuit tool the length is mostly justified, though a few requirement sentences duplicate what the schema descriptions already state.

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?

There is no output schema, and the description compensates by naming both possible returns (awaiting_approval or the full ProofResult with proof bytes, public inputs, and timing) and by pointing to verify_proof for on-chain verification. Combined with the per-circuit and approval-flow detail, an agent has everything needed to call this correctly.

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 baseline is 3; the description earns above that by supplying cross-parameter conditional requirements the flat schema cannot express — which circuit needs country_list/is_included, jwt/scope, or min_score/chain, and which circuits accept or reject action. It also explains that any EIP-712 structure is provable since the circuit only hashes it. Some circuit prerequisites are nonetheless restated in both description and schema, diluting the marginal gain.

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+resource ('All-in-one ZK proof generation') and immediately enumerates the three sub-steps it wraps (prepare inputs, request challenge, submit proof). It explicitly contrasts itself with the fine-grained siblings prepare_inputs, request_challenge, and submit_proof, so the agent can route without inspecting schemas.

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?

It gives an explicit when-to-use ('simplest path to a proof') and when-to-use-something-else rule naming the three alternative tools for fine-grained control. The CIRCUITS block further tells the agent which parameters each circuit needs and where action is optional versus rejected, which is the main decision surface for this tool.

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

Deploy Server

Other Tools