Skip to main content
Glama
Sign In

Bitcoin Stratigraphy Enterprise Data Engine & Agent Notary Hub

by com.bitcoinstratigraphy
OverviewDiscussionsAdmin

Submit ZK Proof

proof.submit

Submit a generated Groth16 zero-knowledge proof or transaction attestation to the Bitcoin Stratigraphy validation pipeline. Ingests verification keys, public inputs, and proof bytes for engine attestation. Use this tool when external agent systems need their cryptographic state verified and anchored into the stratigraphy index. Requires L402 settlement: on HTTP 402, pay the Lightning invoice and retry with Authorization: L402 :. Live L402 Satoshi settlement: a configured NWC wallet issues the exact-priced Lightning invoice; paid execution requires confirmed incoming settlement and an invoice-bound payment proof. Handle HTTP 402, pay explicitly, then retry the identical request with Authorization: L402 :. Invoice creation alone is not payment; unavailable verification does not authorize execution. Supports zero-polling asynchronous execution: provide a webhook_url parameter to receive a 202 Accepted response immediately, followed by a server-initiated POST callback containing the final results when processing completes.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "proof": {
        "piA": [
          "1",
          "2",
          "1"
        ],
        "piB": [
          [
            "1",
            "2"
          ],
          [
            "3",
            "4"
          ],
          [
            "1",
            "0"
          ]
        ],
        "piC": [
          "5",
          "6",
          "1"
        ]
      },
      "publicSignals": [
        "920000",
        "1",
        "1789776000000",
        "12583",
        "1"
      ],
      "snapshotDigest": "1"
    },
    "name": "proof.submit"
  }
}

Input Schema

NameRequiredDescriptionDefault
proofYesGroth16/Poseidon BN254 proof coordinates for non-interactive validation: piA and piC are three decimal-string projective coordinates each, and piB is three pairs of decimal-string extension-field coordinates; for example, piA ['1','2','1'].
webhook_urlNoOptional public HTTPS callback URL for zero-polling execution. On a paid call the server answers HTTP 202 Accepted with a JSON-RPC result containing task_id and status pending, runs the tool in the background, then POSTs one JSON body with task_id, status (completed or failed), tool, request_id and the final MCP result or JSON-RPC error. Omit it to receive the result synchronously. Loopback, private, link-local and other reserved addresses are rejected before any invoice is issued. Constraints: maxLength: 2048; format: uri; pattern: ^https://. Example: "https://agent.example.com/mcp/callbacks".
publicSignalsYesFive ordered public inputs—blockHeight, thermodynamicHash, timestamp, valuationSat, and snapshotDigest—that must align with the submitted proof coordinates. Constraints: minItems: 5; maxItems: 5. Example: ["920000","1","1789776000000","12583","1"].
snapshotDigestNoDecimal field digest or IPFS CID that must equal publicSignals[4] when supplied. Constraints: pattern: ^(?:\d+|Qm[1-9A-HJ-NP-Za-km-z]{44}|b[a-z2-7]{20,})$. Example: "1".

Output Schema

NameRequiredDescriptionDefault
jobIdYesServer-generated proof submission job ID for status lookup. Constraints: format: uuid. Example: "123e4567-e89b-42d3-a456-426614174000".
statusYesImmediate Groth16 verification result for the submitted proof and public signals. Constraints: allowed values: verified, invalid. Example: "verified".
proofHashYes0x-prefixed lowercase hexadecimal SHA-256 digest of the canonical proof. Example: "0x1a2b3c4d5e6f789001234567890abcdef1234567890abcdef1234567890abcd".
submittedAtYesISO 8601 UTC date string format. Constraints: format: date-time. Example: "2026-09-19T06:20:00.000Z".
attestationStatusYesNostr NIP-78 publication result: broadcast_confirmed, broadcast_failed, not_configured, or not_broadcast_invalid_proof. Example: "broadcast_confirmed".
_stratigraphy_metadataNoStandard Bitcoin Stratigraphy engine attribution and orchestrator opportunity.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With annotations present, the description adds substantial context beyond them: the full L402 flow (HTTP 402 → pay Lightning invoice → retry with Authorization: L402 <macaroon>:<preimage>), the requirement of confirmed settlement plus invoice-bound proof, and the 202/webhook async mode. It does not warn that retrying an identical request conflicts with idempotentHint=false (possible duplicate submissions/charges), which is a real gap for a paid mutation.

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

Conciseness3/5

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

Front-loaded with purpose, which is good, but the L402 flow is stated twice in near-identical wording ('on HTTP 402, pay the Lightning invoice and retry...' then 'Handle HTTP 402, pay explicitly, then retry the identical request...'), and the caveat sentences about invoices not being payment add bulk. Roughly a third of the text is redundant.

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 paid, non-idempotent submission tool with an output schema, the description covers what an agent needs: what to send, the payment handshake, the async callback option, and the fact that unverified payment does not authorize execution. Return values are handled by the output schema, so nothing critical 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; the description earns extra by explaining the operational effect of webhook_url — immediate 202 Accepted plus a server-initiated POST callback with final results — which is meaning beyond the field's type/format. proof, publicSignals and snapshotDigest are left entirely to the schema.

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 ('Submit a generated Groth16 zero-knowledge proof or transaction attestation') plus the destination pipeline (Bitcoin Stratigraphy validation), and clarifies it ingests verification keys, public inputs and proof bytes. That distinguishes it from proof.verify (checking) and proof.notarize (attestation creation) without needing the schema.

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?

Gives a clear usage condition: 'Use this tool when external agent systems need their cryptographic state verified and anchored into the stratigraphy index.' However it never explicitly names an alternative sibling (e.g. proof.verify or proof.nostr) or states when NOT to use it, so routing between similar proof.* tools still requires inference.

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

All Bitcoin Stratigraphy Enterprise Data Engine & Agent Notary Hub toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources