Skip to main content
Glama
zkproofport

zkproofport-ai

by zkproofport
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

request_challenge

Request a challenge to obtain the nonce, live payment offers, and optional TEE key without transmitting private witness inputs. Use the returned nonce with submit_proof to proceed.

Instructions

Step 2 of the step-by-step flow: Request a challenge from the server. Pass inputs: {} to discover the live payment offers, nonce and optional TEE key without transmitting private witness inputs. You MUST pass the returned "nonce" to submit_proof — without it the server just issues another challenge. MCP submit_proof does not sign payments or encrypt inputs; use generate_proof or the SDK for paid/encrypted orchestration.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputsYesUse {} to discover the nonce, payment offers and optional TEE key without transmitting private witness inputs. Also accepts a JSON string or object from trusted local code; any supplied witness is sent to the selected prover and must stay out of model context, dApp/UI and logs.
circuitYesWhich circuit to use

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.44
    • 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"
+]
  2. Changed2 schema fields changedv0.2.43
    • changedInput schema / properties / circuit / enum
      Previous value: -[
-  "coinbase_kyc",
-  "coinbase_country",
-  "oidc_domain"
-]New value: +[
+  "coinbase_kyc",
+  "coinbase_country",
+  "oidc_domain",
+  "arc_eligibility"
+]
    • changedInput schema / properties / inputs / description
      Previous value: -"Full ProveInputs object from prepare_inputs. Accepts a JSON string or a structured object."New value: +"Use {} to discover the nonce, payment offers and optional TEE key without transmitting private witness inputs. Also accepts a JSON string or object from trusted local code; any supplied witness is sent to the selected prover and must stay out of model context, dApp/UI and logs."
  3. First observedv0.2.9

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses security-relevant behavior: that the tool does not sign payments or encrypt inputs, and that '{}' prevents transmission of private witness data. It also highlights the server-side nonce issuance and its necessity for subsequent steps.

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

Conciseness5/5

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

The description is concise yet information-dense, with critical points front-loaded: step indication, the recommendation to use '{}', and the nonce requirement. Every sentence earns its place, covering purpose, usage, and security implications without redundancy.

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?

Given the tool's moderate complexity (2 params, no output schema), the description provides comprehensive guidance on what the tool does, when to use it, how to use it safely, and what to do with the result (pass nonce to submit_proof). It also covers the alternative for paid/encrypted use, making it self-sufficient for an agent.

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

Parameters5/5

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

Even though schema coverage is 100%, the description adds crucial meaning: it explains that '{}' is sufficient for anonymous discovery, warns that providing witness data sends it to the prover and must be kept out of context/logs, and clarifies the circuit enum's purpose. This goes well beyond the schema's minimal descriptions.

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 clearly states it is 'Step 2 of the step-by-step flow: Request a challenge from the server' and specifies the resource and action. It distinguishes itself from siblings like submit_proof by explaining its role and the critical dependency on the returned nonce.

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 explicitly recommends passing '{}' to avoid transmitting private data, warns against using submit_proof for signing, and directs to generate_proof or the SDK for paid/encrypted flows. This provides clear when-to-use and when-not-to-use guidance with specific alternatives.

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