Skip to main content
Glama

bitcoin-stratigraphy

Verify Stratigraphy ZK Proof

proof.verify
Read-onlyIdempotent

PURPOSE: Verifies a base64url-encoded Groth16/Poseidon BN254 proof against typed public claims and a telemetry snapshot. USAGE: Use to validate a proof against snapshot data. Do NOT use to submit proof coordinates for optional Nostr publication; use proof.submit instead. PARAMETERS: proof is a non-empty base64url proof string; publicInputs is an object with non-negative integer blockHeight, non-empty string snapshotDigest, non-empty string thermodynamicHash, non-negative integer timestamp, and non-negative integer valuationSat; verificationKeyId is a non-empty string; data is a telemetry object or an array of telemetry objects. BEHAVIOR: Checks the snapshot digest, semantic claims, verification-key identifier, and Groth16 proof in memory, and updates bounded process-memory verification and lifecycle indexes without durable database storage. Rate limit: 60 req/min per IP shared across /mcp. RETURNS: Object containing valid, verifiedAt, and computationTimeMs; proof, snapshot, semantic, or key mismatches produce valid false. ERRORS: -32602 (Invalid Parameters) for malformed or missing input properties; HTTP 429 (Rate Limit) when the shared limit is exceeded. No 402 payment required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesTelemetry snapshot payload object or array of objects containing canonical state values.
proofYesBase64url-encoded Groth16/Poseidon BN254 proof string without padding.eyJwaV9hIjpbIjEyMyIsIjQ1NiIsIjEiXX0
publicInputsYesObject containing five typed public statement inputs committed by the proof.
verificationKeyIdYesSHA-256 verification-key identifier string formatted with 'sha256:' prefix.sha256:4c095e183ea45a9d

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoHuman-readable verification error message when verification cannot validate the proof. Example: 'Verification key identifier does not match the proof.'.Verification key identifier does not match the proof.
validYesWhether the proof is valid and bound to the snapshot.
verifiedAtYesISO 8601 UTC date string format.2026-09-19T01:41:36.458Z
computationTimeMsYesServer-side proof verification duration in milliseconds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Although annotations already declare readOnlyHint and idempotentHint, the description adds valuable behavioral context: it checks snapshot digest, semantic claims, verification-key ID, and Groth16 proof in memory; updates only bounded process-memory indexes without durable database storage; and shares a 60 req/min per-IP rate limit across /mcp. This goes well beyond the annotations.

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?

The description is well-structured with clear PURPOSE/USAGE/BEHAVIOR/RETURNS/ERRORS sections and is front-loaded with the most important information. The PARAMETERS section is slightly redundant given the rich schema, but overall the organization helps an agent parse the definition quickly.

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?

The description is complete for a tool of this complexity: it covers behavior, side effects, return value shape, failure semantics, error codes, rate limits, and even explicitly states no 402 payment is required. Combined with the output schema and annotations, nothing essential is missing for correct invocation.

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?

The input schema already describes every parameter in detail (100% coverage), so the baseline is 3. The PARAMETERS section summarizes the schema but does not add meaningfully new semantics beyond what the schema provides, such as types, minimums, or minLength constraints.

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 states a specific verb and resource: it 'Verifies a base64url-encoded Groth16/Poseidon BN254 proof against typed public claims and a telemetry snapshot.' This is far more specific than the title and clearly distinguishes the tool's core function from related proof tools.

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?

The description gives explicit usage direction: 'Use to validate a proof against snapshot data' and an explicit exclusion with an alternative: 'Do NOT use to submit proof coordinates for optional Nostr publication; use proof.submit instead.' This fully resolves when to choose this tool over its closest sibling.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources