Skip to main content
Glama
zkproofport

zkproofport-ai

by zkproofport
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

generate_proof

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.

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.

  • "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

TableJSON Schema
NameRequiredDescriptionDefault
jwtNoOIDC JWT token (id_token) for oidc_domain circuit
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 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_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.
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. 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"
+]
  2. 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"
+}
  3. 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"
+]
  4. 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"
+}
  5. First observedv0.2.9

TDQS

A4.6/5.0
Behavior4/5

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

No annotations exist, so the description carries the full load, and it does substantial work: it discloses that an action request returns awaiting_approval with a human-facing URL, that ordinary proofs auto-sign, that the request must be repeated unchanged with approval_id, and that ATTESTATION_KEY cannot stand in for the human. It stops short of covering failure modes, payment settlement failures, or idempotency/retry behavior.

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?

Front-loads the one-line purpose and the routing decision before any detail, then uses clear CIRCUITS / WITH ACTION / RETURNS headings. The length is defensible for a 12-param tool with nested objects, though the circuit blurbs are chatty (e.g. the 'not merely that somebody eligible signed something' aside).

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?

With no output schema, the description still states the two possible return shapes (awaiting_approval or the full ProofResult with proof bytes, public inputs, timing) and points to verify_proof for on-chain verification. For a tool carrying 12 parameters, nested objects, and zero annotations, it covers purpose, routing, circuit requirements, async approval flow, and returns without leaving an agent unable to call it 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, but the description adds real value the schema lacks: it maps required parameters to circuits (country_list + is_included for coinbase_country; jwt + scope for oidc_domain) and explains that action is optional only for giwa_attestation and rejected elsewhere. Payment params (pay_on, pay_with, max_payment) are left entirely to the schema.

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?

Opens with a specific verb+resource ('All-in-one ZK proof generation') and immediately enumerates the three steps it collapses (prepare inputs, request challenge, submit proof). It names the sibling tools it substitutes for, so an agent can distinguish it from prepare_inputs/request_challenge/submit_proof without opening any schema.

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 routing: '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 gives the when-condition for the action path and names get_action_approval as the follow-up tool, plus warns that ATTESTATION_KEY cannot authorize on the human's behalf.

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