Skip to main content
Glama
Sign In
zkproofport-ai

zkproofport-ai

by zkproofport
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

verify_proof

Verifies a ZK proof on-chain against the pinned verifier contract and issuer anchors, rejecting mismatched addresses and returning valid status or an error.

Instructions

Step 4 (optional): Verify a ZK proof on-chain against ZKProofport's own pinned verifier contract for the circuit and chain. Pass the full generate_proof result object directly. The result's verifierAddress is only compared with the pinned one: a different address is refused, never called. Issuer anchors are checked too (OIDC provider key against Google/Microsoft's published keys; Coinbase/GIWA signer-list root). Returns { valid: true } if the proof is valid, otherwise { valid: false, error }.

Input Schema

NameRequiredDescriptionDefault
resultYesFull result object from generate_proof — pass it directly without extracting fields
min_scoreNohuman_passport: the threshold you asked for, in points. The proof's threshold must equal it; omit it and the threshold is not compared.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.49
    • addedInput schema / properties / min_score
      Added value: +{
+  "description": "human_passport: the threshold you asked for, in points. The proof's threshold must equal it; omit it and the threshold is not compared.",
+  "type": "number"
+}
  2. Changed4 schema fields changedv0.2.47
    • changedInput schema / properties / result / properties / verification / properties / chainId / description
      Previous value: -"Chain ID (e.g. 8453 for Base, 84532 for Base Sepolia)"New value: +"Chain the result names; selects the pinned verifier for the circuit on that chain"
    • changedInput schema / properties / result / properties / verification / properties / rpcUrl / description
      Previous value: -"RPC URL for the chain"New value: +"Ignored: verification uses its own public RPC for the chain, never one a result names"
    • changedInput schema / properties / result / properties / verification / properties / verifierAddress / description
      Previous value: -"Verifier contract address"New value: +"Verifier address the result names; compared with the pinned verifier, refused if different"
    • changedInput schema / properties / result / properties / verification / required
      Previous value: -[
-  "verifierAddress",
-  "chainId",
-  "rpcUrl"
-]New value: +[
+  "verifierAddress",
+  "chainId"
+]
  3. First observedv0.2.9

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations present the description carries the full burden and does so well: it discloses that verifierAddress is only compared against the pinned one and a mismatch is refused, never called; that the rpcUrl in the result is ignored in favor of its own public RPC; and that issuer anchors (OIDC keys, Coinbase/GIWA signer-list root) are checked. It also states the return shape with both success and failure branches.

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 step number, action, and target, then packs the security caveats and return contract into a tight block. Every sentence carries information, though the caveat cluster is dense enough to read as a run-on.

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 nested-object verification tool with no output schema, the description covers input handling, the security model around verifier and issuer pinning, and the return contract in both success and failure cases. Nothing an agent needs to invoke it correctly is missing.

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 meaning beyond the schema: it insists the whole result object be passed without extracting fields, and explains min_score's equality requirement (omit and no comparison happens).

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+resource ('Verify a ZK proof on-chain against ZKProofport's own pinned verifier contract') and adds the exact scope (circuit and chain). It is clearly distinguished from the sibling generate_proof by positioning itself as the downstream verification step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Labels itself 'Step 4 (optional)' and tells the agent to pass the full generate_proof result object directly, which routes correctly between it and its predecessor. It does not spell out explicit exclusions such as when verification can be skipped, but the workflow context is unambiguous.

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