Skip to main content
Glama

request_challenge

Requests a server challenge to obtain a nonce, live payment offers, and an optional TEE key without sending private witness inputs; pass the nonce to submit_proof to complete proof submission.

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

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.49
    • 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"
      +]
  2. Changed1 schema field changedv0.2.46
    • 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"
      +]
  3. 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"
      +]
  4. 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."
  5. First observedv0.2.9

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose the key behavioral traits: empty inputs avoid transmitting witness data, the returned nonce must be threaded into submit_proof or this tool is a no-op, and no signing/encryption happens here. It omits auth requirements, whether the challenge expires, and any rate limits.

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-loaded with the flow position and the main call pattern, and each sentence carries operational weight. It does partially restate the schema's inputs:{} guidance, which is minor redundancy in an otherwise tight description.

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 and no annotations, the description still names what comes back (nonce, payment offers, optional TEE key) and how it feeds the next step. Enough to call it correctly and chain it without guessing.

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 coverage is 100%, so the baseline is 3. The description reinforces the discovery-mode use of inputs:{} but adds nothing about how to choose among the five circuit enum values, leaving the circuit parameter as opaque as the schema already does.

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?

States a specific verb and resource ('Request a challenge from the server') and pins its role as step 2 of a named multi-step flow. An agent can place it relative to submit_proof and generate_proof without opening 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?

Gives explicit call conditions ('Pass inputs: {} to discover the live payment offers, nonce and optional TEE key') and explicit exclusions ('use generate_proof or the SDK for paid/encrypted orchestration'; submit_proof doesn't sign or encrypt). It also warns that skipping the nonce hand-off causes the server to just re-issue another challenge.

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