Skip to main content
Glama

x402_verify_zk_or_bitvec

Formally verify ZK circuit witness uniqueness for soundness or detect BitVector integer cast truncation with Z3 proofs.

Instructions

Paid tool (30000 Base USDC atomic): Formal Z3 verification of ZK circuit witness uniqueness (soundness) or BitVector integer cast truncation.

Input Schema

NameRequiredDescriptionDefault
exprNoExpression for bitvec check (e.g. 'a + b')
modeNo
output_varNo
witness_varsNo
paymentHeaderNox402 Base64 or JSON payment authorization string (if not in _meta.x402Payment)
preconditionsNo
public_inputsNo
var_bitwidthsNoDictionary of variable bitwidths (e.g. {'a': 8, 'b': 8})
target_bitwidthNo
constraints_exprsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.6/5.0
Behavior2/5

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

Annotations are absent, so the description carries the full burden. It does disclose the paid nature and exact price (30000 Base USDC atomic), which is valuable, but says nothing about what a verification result looks like, what happens when verification fails, how payment is rejected, or runtime/duration expectations. No output schema exists to fill that gap.

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?

A single dense sentence with the price front-loaded and no filler, though the heavy parentheticals compress the two modes into something harder to parse than a short bulleted structure would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with 30% schema coverage, nested objects, no annotations, and no output schema, one sentence cannot be sufficient. An agent has no way to know which parameters are required per mode, what the return value contains, or what payment failure looks like.

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

Parameters2/5

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

Schema coverage is only 30% across 10 parameters. The description hints that witness_vars/public_inputs/preconditions/constraints_exprs belong to zk mode and expr/var_bitwidths/target_bitwidth belong to bitvec mode, but never states this mapping, and leaves output_var and paymentHeader wholly unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Formal Z3 verification') and names the two distinct capabilities (ZK circuit witness uniqueness/soundness vs BitVector integer cast truncation), which lets an agent tell it apart from the rounding/differential siblings. Lacks an explicit cross-reference to siblings, so not a 5.

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

Usage Guidelines2/5

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

No guidance on when to pick this tool over x402_verify_vault_rounding or x402_verify_differential_spec, nor any guidance on how to choose between the two modes. The mode enum exists in the schema but the description never says which parameter set belongs to which mode.

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