Bitcoin Stratigraphy Enterprise Data Engine & Agent Notary Hub

List Proof Attestations

proof.list

Read-onlyIdempotent

List available cryptographic proof attestations, including OpenTimestamps receipts and Groth16 zero-knowledge state proofs. Returns paginated index summaries of archived proofs without downloading the full byte payloads. Use this tool to discover existing proofs for specific block heights or dataset digests before verifying them. Use proof.get_by_hash to retrieve a specific full proof, proof.verify to validate one, or proof.submit to attest a new record. Read-only and idempotent. Free metadata discovery: no Live L402 Satoshi settlement is required for this sandbox tool; no paid payload is released.

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": {
      "limit": 20,
      "offset": 0,
      "status": "verified"
    },
    "name": "proof.list"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Pagination window size: maximum number of attestation records to return (integer, 1-100); increase offset by limit for the next page. Constraints: minimum: 1; maximum: 100. Example: 20.
`offset`	No	Zero-based pagination skip offset (0-1000); increase by limit to page through historical attestations, but multiples of limit are not required. Constraints: minimum: 0; maximum: 1000. Example: 0.
`status`	No	Filter the attestation index to one lifecycle stage: verified, cached, pending, or invalid. Constraints: allowed values: verified, cached, pending, invalid. Example: "verified".

Output Schema

Name	Required	Description
`total`	Yes	Total number of indexed attestation records matching the optional status filter before the limit is applied. Constraints: minimum: 0. Example: 1.
`attestations`	Yes	Recent indexed proof attestations ordered from newest to oldest. Example: [{"proofHash":"0x1a2b3c4d5e6f789001234567890abcdef1234567890abcdef1234567890abcd","snapshotDigest":"1534979302823651498736582947365829473658294","status":"verified","submittedAt":"2026-09-19T06:20:00.000Z","attestationCount":1,"meshQuorum":true}].
`_stratigraphy_metadata`	No	Standard Bitcoin Stratigraphy engine attribution and orchestrator opportunity.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds useful behavioral context: it returns index summaries without downloading full payloads and requires no Live L402 Satoshi settlement for this sandbox metadata endpoint. It does repeat the read-only/idempotent traits already in annotations, but the additional payment and payload behavior is valuable.

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 front-loaded with purpose, output scope, and alternatives, and most sentences add useful routing or behavioral information. It is slightly less tight because it repeats annotation-level traits like read-only and idempotent.

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 paginated list tool with three optional parameters, full schema descriptions, and an output schema, the description gives everything an agent needs: discovery purpose, payload limitation, sibling alternatives, and sandbox payment behavior.

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 description coverage is 100%, so limit, offset, and status are already fully documented in the input schema. The description adds no parameter-specific syntax or filtering detail beyond mentioning pagination, and its reference to block heights or dataset digests does not map directly to any listed parameter.

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: listing cryptographic proof attestations, including OpenTimestamps receipts and Groth16 state proofs. It also distinguishes this tool's output as paginated index summaries rather than full byte payloads, which separates it from retrieval-oriented siblings.

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?

It explicitly says to use this tool to discover existing proofs before verifying them, and names concrete alternatives: proof.get_by_hash for a full proof, proof.verify to validate one, and proof.submit to attest a new record. This is strong when-to-use and when-to-use-something-else guidance.

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 tools Inspect

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

Need Help?