A
licenseNot graded
qualityB
maintenanceEdge-deployed predictive decision engine and circuit-breaker orchestrator for AI agents. Features low-latency telemetry, automated failover routing, and Bitcoin Lightning micro-payments.
MIT
bitcoin-stratigraphy
Server Details
Enterprise L402 data vending engine delivering real-time thermodynamic Bitcoin telemetry, Groth16 ZK-SNARK verification, Nostr P2P mesh consensus, and agent context grounding to autonomous AI swarms.
Ownership verified
- Status
- Healthy
- Uptime
- 97.6% over 21 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.4/5.0
Scored across 15 tools
Disambiguation5/5
Each tool targets a distinct resource and action, and the descriptions explicitly draw boundaries between overlapping-sounding operations (e.g., proof.ground vs proof.notarize vs proof.verify). No two tools appear to do the same thing.
Naming Consistency5/5
All tool names follow a consistent namespace.operation snake_case pattern across mesh.*, payment.*, proof.*, and stratigraphy.* groups. Verbs are used predictably (get, list, submit, verify, etc.).
Tool Count4/5
15 tools is at the upper bound of the typical 3-15 range, but each tool covers a distinct capability. The mesh and payment tools are peripheral to the core stratigraphy purpose, which slightly widens the scope.
Completeness4/5
The surface covers discovery, retrieval, comparison, proof verification/anchoring, and payment/auth lifecycle. Minor gaps exist (no proof revocation, no mesh peer admin, no stratigraphy write), though these are stated as intentionally omitted or outside scope.
Available Tools
15 toolsmesh.broadcastBroadcast Telemetry Snapshot to MeshAInspect
PURPOSE & BOUNDARIES: Sign a stored daily telemetry snapshot selected by date and distribute it to pinned mesh peers for cross-validation; arbitrary payloads or inbound peer sync publication are not supported. USAGE GUIDELINES: Use this instead of mesh.get_status only when sending a snapshot for peer acknowledgment. BEHAVIOR & CONSEQUENCES: Side-effecting and costs 250 sats via HTTP L402 without valid credentials; missing records, invalid agent events, unavailable peers, or failed quorum return errors.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | UTC date selector for an existing telemetry record submitted for peer attestation, not a caller-supplied record object; for example, {"date":"2026-09-09"}. | |
| agentEvent | No | Optional NIP-01 kind 20079 signature over JSON.stringify({networkId,date}) for this exact date selector. The signer must have a trusted mesh attestation. Example: a complete signed event with a matching date. | |
| signalType | Yes | Enforces the broadcast event schema; must be telemetry_snapshot to trigger peer validation, not an arbitrary signal. Constraints: allowed values: telemetry_snapshot. Example: "telemetry_snapshot". |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| date | Yes | UTC date of the distributed telemetry record. Constraints: format: date. Example: "2026-09-09". |
| networkId | Yes | Mesh network identifier committed in peer attestations. Example: "bitcoin-stratigraphy-mainnet-v1". |
| merkleRoot | Yes | Merkle root of local and peer attestation event identifiers. Constraints: pattern: ^[0-9a-f]{64}$. Example: "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd". |
| signalType | Yes | Signal distributed to configured peers. Constraints: allowed values: telemetry_snapshot. Example: "telemetry_snapshot". |
| agentPubkey | No | Present only when an agent-signed session was verified and accepted by the peer mesh. Constraints: pattern: ^[0-9a-f]{64}$. Example: "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd". |
| snapshotDigest | Yes | SHA-256 digest of the canonical mesh-encoded signed snapshot. Constraints: pattern: ^[0-9a-f]{64}$. Example: "abababababababababababababababababababababababababababababababab". |
| quorumThreshold | Yes | Required total attestation count, including this node. Constraints: minimum: 1. Example: 2. |
| peerAttestations | Yes | Number of remote pinned peers whose signatures were verified; excludes this node. Constraints: minimum: 1. Example: 1. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, open-world, non-idempotent, non-destructive, but the description adds materially new behavior: an L402 payment cost of 250 sats when credentials are absent, and the concrete failure modes (missing records, invalid agent events, unavailable peers, failed quorum). This is enforcement/error semantics the agent cannot get from the annotations or schema.
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-loaded with purpose and organized under explicit PURPOSE / USAGE / BEHAVIOR labels, with no filler sentences. It is somewhat dense per line, but every clause carries scope, routing, or error information rather than restating the title.
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 side-effecting, costly, non-idempotent tool with nested objects and an output schema, the definition supplies the scope boundaries, the sibling routing, the payment precondition, and the error surface. Return values are covered by the output schema, so nothing an agent needs before invoking 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 meaning the schema cannot: it clarifies that payload is a date selector for an already-stored record rather than a caller-supplied payload object. It does not add format or validation detail beyond the schema, so it stops short of 5.
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 chain (sign + distribute) on a specific resource (a stored daily telemetry snapshot selected by date) and names the target (pinned mesh peers for cross-validation). It also rules out the two nearest misreadings — arbitrary payloads and inbound peer sync publication — so it is distinguishable from siblings without opening 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative (mesh.get_status) and the precise condition that selects this tool instead ('only when sending a snapshot for peer acknowledgment'). That is a when-to-use plus a when-not, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mesh.get_statusGet Mesh StatusARead-onlyIdempotentInspect
Inspect P2P peer counts, topology health, cross-validation rate, propagation latency, and quorum. Requires L402 authorization; use mesh.broadcast to distribute a snapshot. This tool does not administer peers or edit topology.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| nodePubkey | Yes | Lowercase hexadecimal Nostr public key identifying this mesh node. Example: "f72cc555ec2948fdc4b5b2c2778821499ea8ce2b8569b68675899e296d3ff253". |
| topologyHealth | Yes | Current consensus topology health classification. Constraints: allowed values: healthy, degraded, isolated. Example: "healthy". |
| activePeerCount | Yes | Number of recently validated nodes, including the local node. Constraints: minimum: 1. Example: 3. |
| quorumThreshold | Yes | Minimum unique node attestations required for consensus. Constraints: minimum: 1. Example: 2. |
| configuredPeerCount | Yes | Number of remotely configured trusted peers. Constraints: minimum: 0. Example: 2. |
| crossValidationSuccessRate | Yes | Lifetime ratio of successful peer cross-validation attempts. Constraints: minimum: 0; maximum: 1. Example: 0.98. |
| averagePropagationLatencyMs | Yes | Mean round-trip propagation latency for successful attestations. Constraints: minimum: 0. Example: 42.7. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, but the description adds the L402 authorization requirement and the scope boundary that it does not mutate peers or topology, which is real context beyond the structured fields. No detail on rate limits or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the metric list is front-loaded, followed by the auth/alternative/scope notes. No filler.
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?
An output schema exists so return values need not be described, and the description covers the auth prerequisite, the sibling routing, and the non-mutating boundary. Nothing needed to call 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?
Zero parameters, so the baseline is 4. The schema description already explains passing {} and that extra arguments are rejected; the description does not need to add parameter detail.
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?
Specific verb (Inspect) plus the exact resource and the enumerated metrics (peer counts, topology health, cross-validation rate, latency, quorum), which cleanly separates it from mesh.broadcast and the proof/stratigraphy siblings.
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?
Names an alternative (mesh.broadcast to distribute a snapshot) and states explicit exclusions ('does not administer peers or edit topology'), giving clear when-not guidance. The positive trigger for using this tool over alternatives is only implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payment.get_infoQuery MCP Prices or Verify Payment SettlementAInspect
Query MCP pricing parameters (action='query', the default) or verify authenticated settlement (action='settle' with a payment hash and either an L402 preimage or Base transaction hash). Use query for price discovery before calling paid tools; use settle to check payment status, not to issue an invoice. Macaroons and Lightning invoices are issued dynamically via HTTP 402 challenges with bounded expiration; operator-only admin operations are intentionally omitted.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | query (default) discovers prices; settle verifies authenticated payment. Constraints: allowed values: query, settle. Example: "query". | query |
| txHash | No | Base mainnet transaction hash, accepted only after facilitator settlement of PAYMENT-SIGNATURE. Constraints: pattern: ^0x[0-9a-fA-F]{64}$. Example: "0xabababababababababababababababababababababababababababababababab". | |
| preimage | No | L402 32-byte hex preimage; also send Authorization: L402 <server-issued macaroon>:<preimage>. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd". | |
| toolName | No | Optional case-sensitive canonical MCP tool identifier (e.g., 'stratigraphy.get_digest' or 'proof.verify'); supported legacy aliases are also accepted and resolve to canonical names. When provided, filters output to return pricing specifically for that single tool. When omitted, returns the full pricing map across all registered catalog tools. Must match an exact registered tool name or supported legacy alias. Constraints: minLength: 1. Example: "stratigraphy.get_digest". | |
| paymentHash | No | L402 SHA-256 invoice hash, or Base tx hash when using x402. Constraints: pattern: ^(0x)?[0-9a-fA-F]{64}$. Example: "abababababababababababababababababababababababababababababababab". | |
| paymentMacaroon | No | Original invoice macaroon, separate from this tool's paid access credential. Constraints: minLength: 1; maxLength: 8192. Example: "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ". |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| x402 | No | Base mainnet USDC x402 exact terms; present only when authenticated CDP settlement is configured. |
| verified | No | Whether the signed, server-bound payment was verified or settled. Example: true. |
| challenge | No | HTTP payment challenge and response fields. |
| perToolSats | No | Current advertised canonical tool prices in sats; optional toolName narrows this map. |
| settlementToken | No | Verified payment claims, not a bearer token or a grant of tool access. |
| activeAuthSchemes | No | Authentication schemes for paid MCP calls. Only stratigraphy.list and proof.list execute free. Example: ["L402"]. |
| standardInvoiceSats | No | Standard paid MCP execution price. Catalog and status lookups may cost less; free tools cost zero. Example: 250. |
| invoiceExpirySeconds | No | Default expiry for both the issued Lightning invoice and its path-bound macaroon. Constraints: minimum: 1. Example: 3600. |
| macaroonRequirements | No | A valid payment proof must match the bound invoice, provider, amount, path, expiry and request quota. proof.attenuate requires payment and a valid parent token. |
| acceptedPaymentMethods | No | Supported MCP payment method. Example: ["Lightning L402"]. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is partially covered. The description adds meaningful context beyond them: macaroons and Lightning invoices are issued dynamically via HTTP 402 challenges with bounded expiration, and admin operations are intentionally omitted. It does not fully state idempotency behavior of settle, so it stops short of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each earning its place: the first defines both modes, the second routes usage, the third covers the 402/auth mechanics. Front-loaded with the action semantics.
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?
Output schema exists so return values need not be described. The description covers both action branches, the required credential flow via HTTP headers, and the intentional omission of admin operations. Nothing an agent needs to call 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 semantic value by explaining the settle-mode parameter combination ('a payment hash and either an L402 preimage or Base transaction hash'), which the flat schema lists as separate fields without that relational context.
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 with a dual mode: query MCP pricing parameters or verify authenticated settlement. The action values and their distinct purposes are named explicitly, so an agent can tell this apart from siblings like proof.verify or mesh.get_status without opening 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use for each mode: 'Use query for price discovery before calling paid tools; use settle to check payment status, not to issue an invoice.' It also names an exclusion (admin operations omitted) and clarifies that this tool does not issue invoices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.attenuateAttenuate a MacaroonARead-onlyIdempotentInspect
Attenuate an authentic, unexpired L402 parent macaroon by appending restrictive caveats and optionally ttlSeconds. At least one restriction is required. Requires its own L402 authorization; the parent's payment proof remains required for child redemption. Delegation cannot widen authority or reset an inherited quota.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| caveats | Yes | List of restriction caveats to append (e.g. ['time_before = 2026-12-31', 'max_target = 870000', 'allowed_tools = stratigraphy.get,stratigraphy.get_digest']). Existing allowed_path and max_requests restrictions are also supported. Constraints: maxItems: 16. Example: ["time_before = 2026-12-31","max_target = 870000","allowed_tools = stratigraphy.get,stratigraphy.get_digest"]. | |
| macaroon | Yes | Required authentic, unexpired parent L402 macaroon (1-8192 characters); caveats and ttlSeconds can only narrow its scope. Constraints: minLength: 1; maxLength: 8192. Example: "base64url-parent-macaroon". | |
| ttlSeconds | No | Optional positive integer TTL of 1-2592000 seconds (e.g. 3600); appends an expiration caveat without extending the parent's expiry. Constraints: minimum: 1; maximum: 2592000. Example: 3600. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | Successful attenuation status. Example: "attenuated". |
| issuedAt | Yes | UTC issuance timestamp. Constraints: format: date-time. Example: "2026-09-27T21:00:00.000Z". |
| appliedCaveats | Yes | New canonical caveats appended to the parent; inherited caveats are preserved inside the token. Example: ["max_target=870000"]. |
| attenuatedMacaroon | Yes | Encoded child subscription macaroon. Treat as a bearer credential. Example: "base64url-child-macaroon". |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint, idempotentHint, destructiveHint=false), but the description adds context annotations cannot express: the operation requires its own L402 authorization, the parent's payment proof is still needed for child redemption, and delegation cannot widen authority or reset an inherited quota. That narrowing/authority semantics is genuinely useful behavioral disclosure.
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?
Four short sentences, front-loaded with the core action and followed by requirements and constraints. Only minor redundancy, since 'At least one restriction is required' restates the required caveats array from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the description covers the auth requirement, restriction minimum, and non-widening rule. It is essentially complete for a 3-param credential-derivation tool, with only the missing sibling routing as a gap.
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 coverage is 100% and the schema already documents caveat format, array limits, macaroon constraints, and TTL bounds. The description reinforces the narrowing semantics ('cannot widen authority or reset an inherited quota') but adds no format or syntax detail beyond the schema, so the baseline 3 applies.
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 ('attenuate') and resource ('L402 parent macaroon'), then defines the operation precisely as appending restrictive caveats plus optional TTL. This is clearly distinct from proof.verify, proof.ground, or proof.submit; an agent can place it without opening 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives real preconditions ('At least one restriction is required', 'Requires its own L402 authorization') which function as when-to-use guidance. However, it never contrasts with sibling tools (proof.verify, proof.ground) or says when attenuation is the wrong choice, so usage remains implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.get_by_hashGet Proof or Receipt by HashARead-onlyIdempotentInspect
Retrieve one retained proof payload, signed receipt, or lifecycle-only status using exactly one known hash (proof or receipt hash, CID, snapshot digest, or submission UUID) or jobId (submission UUID). Looks up bounded process-local records without re-running Groth16 proof verification; receipt provenance may be checked against the current dataset, and missing payloads cannot be reconstructed. Use proof.list to discover indexed proof hashes and proof.verify to cryptographically verify supplied proof inputs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| hash | No | Required when jobId is absent: proof/receipt 64-hex hash (optional 0x), decimal snapshot digest, IPFS CID, or UUID submission job ID; unknown identifiers return 404. Constraints: pattern: ^(?:(?:0x)?[0-9a-fA-F]{64}|Qm[1-9A-HJ-NP-Za-km-z]{44}|b[a-z2-7]{20,}|\d{1,77}|[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$. Example: "0xabababababababababababababababababababababababababababababababab". | |
| jobId | No | UUID returned by proof.submit (e.g. '123e4567-e89b-42d3-a456-426614174000'); use instead of hash, never together. Constraints: format: uuid. Example: "123e4567-e89b-42d3-a456-426614174000". |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| hash | Yes | Canonical proof or receipt hash. CID lookups return the matching receipt hash. Example: "0xabababababababababababababababababababababababababababababababab". |
| kind | Yes | Distinguishes ZK proofs, signed receipts, and lifecycle-only status. Constraints: allowed values: zk-proof, dataset-receipt, context-receipt, zk-proof-status. Example: "zk-proof". |
| jobId | No | Submission job identifier when an exact submitted proof payload is retained. Constraints: format: uuid. Example: "123e4567-e89b-42d3-a456-426614174000". |
| status | Yes | Current indexed lifecycle status. Constraints: allowed values: verified, cached, pending, invalid. Example: "verified". |
| otsProof | No | Base64 serialized .ots proof for the bound dataset root bytes when a calendar receipt is available. Constraints: format: byte. Example: "AQID". |
| otsStatus | No | Calendar-only or independently Bitcoin-verified status of the bound OTS receipt. Constraints: allowed values: pending_calendar, bitcoin_block_attested. Example: "pending_calendar". |
| timestamp | Yes | Original submission, verification, or receipt creation time. Constraints: format: date-time. Example: "2026-09-27T21:00:00.000Z". |
| meshQuorum | No | Whether current mesh quorum is met for lifecycle-only lookups. Example: false. |
| proofPayload | No | Exact retained proof input or signed receipt; do not infer missing snapshot data from a submitted proof. |
| attestationCount | No | NIP-78 attestation count for lifecycle-only lookups. Constraints: minimum: 0. Example: 0. |
| provenanceVerified | Yes | Whether this exact signed receipt binds the currently validated dataset strata chain; does not imply Bitcoin OTS confirmation. Example: false. |
| provenanceMerkleRoot | No | Merkle root bound in the signed receipt when the current dataset chain matches. Constraints: pattern: ^[0-9a-f]{64}$. Example: "abababababababababababababababababababababababababababababababab". |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive behavior on top: records are bounded and process-local, Groth16 verification is NOT re-run, receipt provenance may be re-checked against the current dataset, and missing payloads cannot be reconstructed. These constraints materially change how an agent should interpret a hit or a miss.
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?
Three sentences, front-loaded with the retrieval semantics and ending with the alternative-tool routing, with no filler. Sentences are densely packed with clauses, which costs a little readability but each clause carries real information.
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?
An output schema exists, so return structure need not be explained; the description covers lookup scope, error behavior (404 before payment), verification boundary, and sibling alternatives. Nothing needed to call this correctly is missing.
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% and the schema already enumerates the accepted identifier forms, the mutual exclusivity ('never together'), and the 404-on-unknown behavior. The description restates that the two identifiers are alternatives but adds no format, precedence, or edge-case detail the schema lacks, so baseline 3 applies.
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 (retrieve) and the exact resource set (retained proof payload, signed receipt, lifecycle-only status), keyed by one of two named identifier types. It also names the two siblings an agent might confuse it with (proof.list, proof.verify), so the tool is distinguishable without opening any schema.
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?
Explicitly routes the agent: use proof.list to discover indexed hashes, use proof.verify to cryptographically verify supplied proof inputs, and use this tool only for lookup by a known identifier. The 'exactly one of hash or jobId' condition is stated up front, so when-to-use and when-not-to-use are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.groundGround Agent Context in Bitcoin StateAInspect
PURPOSE & BOUNDARIES: Issue a signed Bitcoin-tip receipt for either agent context (contextHash plus agentId) or a dataset CID; this is an anchor, not a ZK or Bitcoin-confirmed OTS proof. USAGE GUIDELINES: Use proof.verify for proof verification without anchoring or proof.get_by_hash for existing receipts. BEHAVIOR & CONSEQUENCES: Creates a receipt and costs 250 sats via HTTP L402 without valid credentials; the two input modes are exclusive, invalid inputs fail, and tip/provider availability is required.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cid | No | Target IPFS CID or 32-byte hex dataset hash anchored directly to the live Bitcoin block height. Example: a 64-character lowercase hex digest. | |
| agentId | No | Unique agent instance identifier named in the signed attestation receipt; trimmed to 1-256 characters. Constraints: minLength: 1; maxLength: 256. Example: "research-agent-7". | |
| context | No | Optional JSON metadata object bound into the signed receipt tuple for additional execution context. Example: {"source":"dataset"}. | |
| metadata | No | Optional non-secret JSON key-value metadata bound to the signed receipt; serialized size must not exceed 16 KiB. Example: {"topic":"difficulty-adjustment"}. | |
| contextHash | No | 64-character hexadecimal SHA-256 digest binding the agent's prompt or execution state to the current block tip; normalized to lowercase. Constraints: minLength: 64; maxLength: 64; pattern: ^[0-9a-fA-F]{64}$. Example: "4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f". | |
| nostrEventId | No | Optional Nostr event ID linked into the signed receipt payload to bind off-chain publications to the block tip. Example: a 64-character lowercase hex event ID. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| receipt | Yes | Full signed context receipt or signed dataset receipt wrapper. Example: a signed Bitcoin-tip anchor. |
| otsProof | No | Base64 serialized .ots proof of the dataset root bytes, when a calendar receipt is available. Constraints: format: byte. Example: "AQID". |
| otsStatus | No | Calendar-only or independently Bitcoin-verified status of the OTS receipt. Constraints: allowed values: pending_calendar, bitcoin_block_attested. Example: "pending_calendar". |
| provenanceVerified | Yes | Whether this signed receipt binds the current verified dataset chain, not whether Bitcoin has attested its OTS proof. Example: true. |
| provenanceMerkleRoot | No | Dataset chain root signed in the receipt, when the referenced dataset still matches. Constraints: pattern: ^[0-9a-f]{64}$. Example: "abababababababababababababababababababababababababababababababab". |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, open-world, non-idempotent operation, and the description adds the operational consequences the annotations cannot: a cost of 250 sats via HTTP L402 when credentials are absent, mutual exclusivity of the two input modes, failure on invalid inputs, and a dependency on tip/provider availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three labeled sections front-load purpose, then routing, then consequences. Dense but every clause carries distinct information (cost, exclusivity, failure mode, availability) with no filler.
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 anchoring tool with six parameters, nested objects and a sibling family, the description covers cost, auth path, mode exclusivity and failure conditions. An output schema exists, so return values need no explanation here.
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 every parameter including cid, contextHash, agentId, metadata, context and nostrEventId is already documented in the schema, and the schema description itself states the two modes are exclusive. The description restates mode exclusivity and which optional field belongs to which mode, adding little beyond the structured data, so the baseline 3 applies.
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 ('issue a signed Bitcoin-tip receipt') and immediately scopes it with two input modes (contextHash+agentId or cid). It also draws a boundary ('this is an anchor, not a ZK or Bitcoin-confirmed OTS proof'), which lets an agent distinguish it from proof.submit or proof.verify without opening 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names two alternative siblings and the condition that selects each: proof.verify for verification without anchoring, proof.get_by_hash for existing receipts. The when-not-anchoring route is spelled out rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.listList Proof AttestationsARead-onlyIdempotentInspect
Freely discover, filter, and paginate recent zk-proof attestation lifecycle summaries. Use limit (1-100), offset (0-1000), and optional status (verified, cached, pending, invalid). Returns bounded summaries, not full proofs or receipts. Alias: proof.status. No invoice is created.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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
ParametersJSON 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}]. |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety bar is low. The description adds genuine value beyond that: it discloses the return granularity (bounded summaries, not full proofs/receipts), the 'freely' no-cost framing, and that no invoice/side effect occurs. It could still note rate limits or default ordering, so not a full 5.
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-loaded with the core action and return shape, and each clause is short. However, repeating the limit/offset ranges and status enum is redundant with the schema, and 'No invoice is created' is a somewhat cryptic trailing note that costs space without clear benefit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be enumerated, and the safety profile is carried by annotations. The description covers scope, pagination, filtering, and the summary-vs-full distinction, leaving only minor gaps (ordering, rate limits) for a low-complexity read tool.
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 the schema already documents limit, offset, and the status enum with ranges and examples. The description restates the same ranges and enum values without adding format or behavioral nuance, which matches the baseline-3 rule.
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 (list/filter/paginate) and resource (zk-proof attestation lifecycle summaries), and explicitly contrasts with the fuller siblings by noting it returns 'bounded summaries, not full proofs or receipts.' An agent can distinguish it from proof.get_by_hash and proof.verify without opening any 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 clear context ('freely discover, filter, and paginate recent ... summaries') and the summary-vs-full-proof distinction implicitly routes the agent to proof.get_by_hash when a complete proof is needed. It does not spell out an explicit when-not-to-use, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.notarizeNotarize a SHA256 Digest with OpenTimestampsAInspect
PURPOSE & BOUNDARIES: Create a detached OpenTimestamps .ots receipt for an agent-supplied SHA256 digest using public calendars. Do NOT use this as evidence of immediate Bitcoin confirmation or as a replacement for proof.verify. USAGE GUIDELINES: Submit exactly one 64-character hexadecimal hash; decode otsProofHex into binary to save the .ots file. BEHAVIOR & CONSEQUENCES: Submits a randomized commitment to public calendars, returns pending_calendar, and fails explicitly if calendars are unavailable. Costs 250 sats via L402; X-L402-Batch-Size: 100 purchases 100 tool-scoped calls for 25000 sats.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Exactly 64 hexadecimal characters representing the agent state or data SHA256 digest; no 0x prefix. Constraints: minLength: 64; maxLength: 64; pattern: ^[0-9a-fA-F]{64}$. Example: "abababababababababababababababababababababababababababababababab". |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| hash | Yes | The original SHA256 digest, normalized to lowercase. Constraints: pattern: ^[0-9a-f]{64}$. Example: "abababababababababababababababababababababababababababababababab". |
| otsStatus | Yes | Calendar receipt only; Bitcoin inclusion must be independently upgraded and verified later. Example: "pending_calendar". |
| otsProofHex | Yes | Hex-encoded detached .ots file. Decode as binary and upgrade or verify later with official OpenTimestamps tools. Constraints: minLength: 2; maxLength: 1048576; pattern: ^(?:[0-9a-f]{2})+$. Example: "004f70656e54696d657374616d70730000". |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-idempotent, open-world, non-destructive write behavior, and the description explains WHY: a randomized commitment is submitted to public calendars, results come back as pending_calendar, and it fails explicitly when calendars are unavailable. It also discloses cost (250 sats L402, X-L402-Batch-Size: 100 for 25000 sats), which is nowhere in structured fields.
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?
Content is dense and front-loaded into PURPOSE / USAGE / BEHAVIOR blocks, and essentially every sentence carries non-redundant information. The ALL-CAPS section labels and the pricing tail make it slightly heavier than it needs to be, but nothing is padding.
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?
An output schema exists, so return values need no explanation, yet the description still tells the agent what to do with otsProofHex and how the call can fail. Cost, batching, and failure modes are all covered, leaving no operational gap.
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% and the single hash parameter is fully documented in the schema, so the baseline is 3. The description's 'one 64-character hexadecimal hash' simply restates that; the extra value it adds (decode otsProofHex) concerns the return value, not the 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?
Names a precise verb+resource+mechanism: create a detached OpenTimestamps .ots receipt for an agent-supplied SHA256 digest via public calendars. It also draws an explicit boundary against proof.verify and against treating the receipt as Bitcoin confirmation, which separates it from the sibling verify tool.
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?
States exactly when NOT to use it ('not immediate Bitcoin confirmation', 'not a replacement for proof.verify') and the input contract ('submit exactly one 64-character hexadecimal hash'). This is explicit routing rather than implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.submitSubmit ZK ProofAInspect
PURPOSE & BOUNDARIES: Submit and register a new Groth16 zk-SNARK proof with its five public signals, then attempt a Nostr NIP-78 attestation; this changes proof registry state, but does not append a proof to a Merkle tree. USAGE GUIDELINES: Use proof.submit strictly for registering new attestations, and use proof.verify instead when validating an existing proof without state mutation. Use proof.get_by_hash for retained submissions or proof.ground for a Bitcoin-tip receipt. BEHAVIOR & CONSEQUENCES: Costs 250 sats via HTTP L402 without valid credentials; malformed inputs fail validation, invalid proofs are reported, and Nostr publication status may fail separately.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| proof | Yes | Groth16/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']. | |
| publicSignals | Yes | Five 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"]. | |
| snapshotDigest | No | Decimal 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| jobId | Yes | Server-generated proof submission job ID for status lookup. Constraints: format: uuid. Example: "123e4567-e89b-42d3-a456-426614174000". |
| status | Yes | Immediate Groth16 verification result for the submitted proof and public signals. Constraints: allowed values: verified, invalid. Example: "verified". |
| proofHash | Yes | 0x-prefixed lowercase hexadecimal SHA-256 digest of the canonical proof. Example: "0x1a2b3c4d5e6f789001234567890abcdef1234567890abcdef1234567890abcd". |
| submittedAt | Yes | ISO 8601 UTC date string format. Constraints: format: date-time. Example: "2026-09-19T06:20:00.000Z". |
| attestationStatus | Yes | Nostr NIP-78 publication result: broadcast_confirmed, broadcast_failed, not_configured, or not_broadcast_invalid_proof. Example: "broadcast_confirmed". |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety/state hints (readOnly=false, destructive=false, idempotent=false, openWorld=true). The description adds non-obvious behavior the annotations cannot express: a 250-sat HTTP L402 cost, validation failure modes, invalid-proof reporting, and that Nostr NIP-78 publication can fail independently of registry success.
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?
Labeled sections (PURPOSE & BOUNDARIES, USAGE GUIDELINES, BEHAVIOR & CONSEQUENCES) front-load the important content and every sentence carries information. It is dense but slightly over-packed into single long sentences.
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 mutating, paid, open-world tool with nested parameters and an output schema, the description covers state effects, cost, alternatives, and independent failure modes. Nothing an agent needs before calling is missing.
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 coverage is 100% and the nested proof/publicSignals shapes are documented in exhaustive detail in the schema. The description adds only the ordinal summary 'five public signals' and the separate Nostr attestation framing, which is a marginal gain over the structured fields.
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 and register a new Groth16 zk-SNARK proof') and explicitly bounds the operation ('does not append a proof to a Merkle tree'), which separates it from mesh.broadcast and other proof.* 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?
Explicitly routes the agent: use this for registering new attestations, use proof.verify for validation without mutation, proof.get_by_hash for retained submissions, and proof.ground for a Bitcoin-tip receipt. This is a model when/when-not/alternatives section.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.verifyVerify Groth16 or OpenTimestamps ProofAInspect
Execute cryptographic verification for supplied Groth16 telemetry or drift zk-SNARK proofs, or OpenTimestamps receipts. Returns proof validity; verification can update a bounded in-memory lifecycle index, and drift checks require a Bitcoin block provider. Use this tool to verify supplied proofs; use proof.submit to register new Groth16 proofs and proof.get_by_hash to retrieve retained proofs or signed receipts by a known identifier.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | True only for a digest-matching, Bitcoin-attested OTS record with a valid chain-header lookup. Example: true. |
| status | No | Whether the OTS record is Bitcoin-attested; calendar-only receipts are unverified. Constraints: allowed values: bitcoin_block_attested, unverified. Example: "bitcoin_block_attested". |
| verifiedAt | No | ISO 8601 UTC time when this verification finished. Constraints: format: date-time. Example: "2026-09-19T01:41:36.458Z". |
| blockHeight | No | Bitcoin attestation height, or null if not verified. Example: 920000. |
| bitcoinHeaderHash | No | Canonical Bitcoin block header hash at the attested height, or null if not verified. Example: "abababababababababababababababababababababababababababababababab". |
| computationTimeMs | No | Server-side proof verification duration in milliseconds. Constraints: minimum: 0. Example: 3.284. |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, and the description corroborates the write-ish behavior by disclosing that verification 'can update a bounded in-memory lifecycle index' — a concrete side effect beyond the annotation flags. It also flags the external dependency that 'drift checks require a Bitcoin block provider'. It stops short of describing failure modes or the verification response shape, but deploys well against the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: verification scope first, behavioral caveats and prerequisites second, sibling routing third. Front-loaded, no repetition of schema field names, and every clause carries information the structured fields do not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three mutually exclusive input shapes, an output schema, and rich annotations, the description supplies the mode overview, the side effect, the external dependency, and sibling disambiguation. Missing only a hint about what the returned validity result looks like or how the lifecycle index affects subsequent calls, but the output schema covers returns.
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?
The schema has 100% description coverage across all oneOf branches, so the structured fields already document each proof path. The description still adds routing value by calling out the Groth16 telemetry, drift, and OTS modes and the block-provider requirement for drift checks. With no top-level parameters, the baseline is high and the description neither harms nor substantially extends it.
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 ('Execute cryptographic verification') and enumerates the three supported artifact types: Groth16 telemetry proofs, drift zk-SNARK proofs, and OpenTimestamps receipts. It also names the sibling tools that do the adjacent jobs (proof.submit, proof.get_by_hash), so the agent can distinguish it without opening any schema.
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?
Explicitly says when to use this tool ('verify supplied proofs') and names two alternatives with the condition that selects each: proof.submit for registering new Groth16 proofs, proof.get_by_hash for retrieving retained proofs or signed receipts by known identifier. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stratigraphy.getGet Bitcoin StratigraphyARead-onlyIdempotentInspect
Retrieve indexed telemetry record bodies by indexed height or UTC ISO date, or query recent days and bounded date/height ranges. Returns full record fields by default; optional metrics project selected telemetry fields, and limit caps results at 1-100 (default 10). Read-only, HTTP rate-limited and L402-paid. Use date or blockHeight for single-entry deep inspection; use stratigraphy.get_range for compact contiguous multi-record spans, stratigraphy.get_digest for lightweight source-record fingerprints, stratigraphy.get_diff for point-in-time deltas, and stratigraphy.list to discover indexed bounds.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Select one indexed UTC day (YYYY-MM-DD, e.g. '2026-09-19'); cannot combine with days, blockHeight, or range bounds. Constraints: minLength: 1; format: date; pattern: ^\d{4}-\d{2}-\d{2}$. Example: "2026-09-19". | |
| days | No | Fetch the most recent 1-365 indexed daily records (e.g. 7), capped by limit; cannot combine with date, blockHeight, or range bounds. Constraints: minimum: 1; maximum: 365. Example: 7. | |
| limit | No | Cap records returned by the chosen selector at 1-100 (default 10); does not expand days or range bounds. Constraints: minimum: 1; maximum: 100. Example: 10. | |
| endDate | No | Inclusive upper UTC date bound (YYYY-MM-DD); pair with startDate for a bounded range or use alone for an open range, never with days, date, or blockHeight; must be >= startDate when paired. Constraints: minLength: 1; format: date; pattern: ^\d{4}-\d{2}-\d{2}$. Example: "2026-09-18". | |
| metrics | No | Unique telemetry metric keys to project into each selected record's quantitative_alpha; omit for all metrics, or choose one or more allowed names. Constraints: minItems: 1. Example: ["target_multiplier"]. | |
| endBlock | No | Inclusive upper indexed block-height bound (non-negative); pair with startBlock for a bounded range or use alone for an open range, never with days, date, or blockHeight; must be >= startBlock when paired. Constraints: minimum: 0. Example: 920000. | |
| startDate | No | Inclusive lower UTC date bound (YYYY-MM-DD); pair with endDate for a bounded range or use alone for an open range, never with days, date, or blockHeight. Constraints: minLength: 1; format: date; pattern: ^\d{4}-\d{2}-\d{2}$. Example: "2026-09-01". | |
| startBlock | No | Inclusive lower indexed block-height bound (non-negative); pair with endBlock for a bounded range or use alone for an open range, never with days, date, or blockHeight. Constraints: minimum: 0. Example: 910000. | |
| blockHeight | No | Select one indexed non-negative dataset height (e.g. 850000), not an arbitrary live chain lookup; cannot combine with days, date, or range bounds. Constraints: minimum: 0. Example: 850000. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| records | Yes | Validated telemetry records matching the requested range. Example: [{"day":422,"title":"Bitcoin Stratigraphy Day 422","video_id":"dQw4w9WgXcQ","transcript_summary":"Mining economics and thermodynamic support strengthened.","quantitative_alpha":{"target_multiplier":125.83,"difficulty_epoch_progress":"73.42%","thermodynamic_signal":"accumulation"}}]. |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds context annotations cannot carry: HTTP rate limiting, L402 payment requirement, the default full-record payload versus projected metrics, and the 1-100 (default 10) cap. It does not cover error behavior or pagination beyond the limit cap, so it falls short of a 5.
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?
Three sentences, front-loaded with the primary behavior, then the return/limit semantics, then the routing guidance. Dense but every clause carries information; only mild cost is the length of the sibling enumeration in the final sentence.
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 9-parameter, zero-required, multi-mode selector tool with an output schema present, the description covers selector exclusivity, defaults, projection behavior, auth/cost, and sibling routing. Return values need not be explained since an output schema exists, and nothing an agent needs to call 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?
With 100% schema coverage the baseline is 3, but the description adds effect-level meaning: metrics project selected telemetry fields rather than returning everything, limit caps but does not expand days or range bounds, and selector modes cannot be combined (matching the schema's mutual-exclusion constraints). This clarifies how parameters interact, not just what they are.
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 (retrieve/query) plus the resource (indexed telemetry record bodies) and enumerates the selector modes (indexed height, UTC ISO date, recent days, bounded ranges). It also explicitly frames itself against siblings, so an agent can distinguish it from stratigraphy.get_range/get_digest/get_diff without opening a schema.
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?
Gives explicit when-to-use guidance ('use `date` or `blockHeight` for single-entry deep inspection') and names four alternatives with the condition that selects each: get_range for compact contiguous spans, get_digest for lightweight fingerprints, get_diff for point-in-time deltas, list for discovering indexed bounds. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stratigraphy.get_diffCompare Stratigraphy StrataARead-onlyIdempotentInspect
Compute signed numerical deltas (indexed height, target multiplier, percentage change, and elapsed days calculated from toTarget minus fromTarget) between two indexed stratum heights or dates. Read-only, stateless operation subject to HTTP rate limiting and L402 payment; missing stratum entries yield JSON-RPC invalid-params errors. Requires valid fromTarget baseline; toTarget defaults to latest. Use this tool specifically to compare two point-in-time entries. Use stratigraphy.get for full stratum record lookups, stratigraphy.get_range for continuous compact multi-record spans, and stratigraphy.get_digest for indexed source-record fingerprints; stratigraphy data ingest is outside this comparison tool.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| toTarget | No | Optional comparison indexed height (e.g. '919856'), UTC ISO date (e.g. '2026-09-01'), or 'latest' (default); deltas are toTarget minus fromTarget. 'latest' is the latest dataset entry, not the live Bitcoin tip. Constraints: pattern: ^(?:latest|(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "latest". | latest |
| fromTarget | Yes | Required baseline indexed height (e.g. '850000') or UTC ISO date (e.g. '2026-01-01'); compared with toTarget to calculate signed deltas. Either chronological order is allowed; only indexed entries resolve. Constraints: pattern: ^(?:(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "919856". |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| to | Yes | One indexed daily stratum; the height is a deterministic dataset index, not a live Bitcoin block height. |
| from | Yes | One indexed daily stratum; the height is a deterministic dataset index, not a live Bitcoin block height. |
| delta | Yes | Signed change from the starting indexed entry to the ending entry. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds rate limiting, L402 payment requirement, statelessness, and the specific error behavior for missing stratum entries (JSON-RPC invalid-params). That is meaningful behavioral context beyond structured fields.
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 computation and its outputs, then constraints, then alternatives. Dense and mostly waste-free, though the 'Use this tool specifically to compare two point-in-time entries' sentence partially restates the opening.
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?
With an output schema present, return-value detail is not needed, and the description still covers defaults, ordering, error behavior, payment/rate constraints, and sibling routing. Nothing needed to call it correctly is missing.
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 the schema already documents both parameters, including the sign convention and the 'latest = latest dataset entry, not live chain tip' caveat. The description reinforces the toTarget-minus-fromTarget direction but adds little syntax or format detail the schema lacks; baseline 3 applies.
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 (compute signed deltas) plus the exact resource (two indexed stratum heights/dates) and even enumerates the returned quantities. It clearly distinguishes itself from sibling lookup tools by naming what kind of operation this is (point-in-time comparison).
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?
Explicitly routes the agent: 'Use this tool specifically to compare two point-in-time entries,' then names three alternatives (stratigraphy.get, get_range, get_digest) with the condition that selects each, and adds an exclusion (data ingest is out of scope). No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stratigraphy.get_digestGet Compressed Stratigraphy DigestARead-onlyIdempotentInspect
Fetch compact source-record fingerprints and metadata for an indexed stratum height, date, or bounded date range. Returns no full record telemetry or Bitcoin block-header hash; the fingerprint is not a verification receipt. Use this tool instead of stratigraphy.get when a compact fingerprint is enough; use stratigraphy.get_range for contiguous multi-record summaries and stratigraphy.list for catalog discovery.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Compression format: minimal returns [height,date,target_multiplier,record_hash]; kv returns {h,ts,tm,hash}; compact returns HEIGHT:...|DATE:...|TM:...|HASH:.... Record hashes are SHA-256 of stored entry fields, not Bitcoin block hashes; no per-record proof is available. Constraints: allowed values: compact, minimal, kv. Example: "compact". | compact |
| target | No | Indexed Bitcoin height (e.g. '920000'), ISO date, or inclusive ISO date range joined with '..'. Defaults to the latest available dataset entry, not the live Bitcoin tip. Constraints: pattern: ^(?:latest|(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2}(?:\.\.\d{4}-\d{2}-\d{2})?)$. Example: "latest". | latest |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | Selected compact string, minimal array or kv object; a date range returns an array of selected results. The hash is a SHA-256 record fingerprint, not a Bitcoin block hash or ZK proof. Example: "HEIGHT:920000|DATE:2026-09-09|TM:125.83|HASH:0123456789abcdef". |
| proofAvailable | Yes | False for indexed dataset source entries; no per-record ZK proof is stored in this dataset. Example: false. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds genuinely useful context beyond that: no full record telemetry or block-header hash is returned, and the fingerprint is explicitly not a verification receipt, which prevents an agent from over-trusting the output. Only pagination/limits are unaddressed, and an output schema exists to cover return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences: capability first, then the important negative constraints, then sibling routing. Nothing is redundant with the name or title, and the exclusions are placed after the purpose so the agent reads the core function first.
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 read-only, idempotent, two-parameter lookup with an output schema, the description covers purpose, routing, and the semantic caveat that the fingerprint is not a proof. Nothing an agent needs to call this 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% and the schema already documents the format enum in detail, so baseline is 3. The description adds a small amount beyond the schema by confirming that target accepts height, ISO date, or a '..' bounded range, mapping the abstract 'target' field to concrete intent.
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 (fetch) and resource (compact source-record fingerprints and metadata) scoped to an indexed stratum height, date, or bounded date range. The scope is precise enough that an agent can distinguish it from stratigraphy.get, get_range, and list without opening any schema.
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?
Explicitly names three alternatives and the condition selecting each: use stratigraphy.get when full data is needed, stratigraphy.get_range for contiguous multi-record summaries, stratigraphy.list for catalog discovery. This is textbook when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stratigraphy.get_rangeGet Stratigraphy RangeARead-onlyIdempotentInspect
Retrieve a contiguous span of compressed indexed stratum summaries across inclusive height or UTC date bounds. Read-only, HTTP rate-limited and L402-paid; startTarget is required, endTarget defaults to the latest indexed entry, and limit caps the returned batch at 1-100 records (default 50) without changing the requested bounds. Primary tool for compact multi-record spans; use stratigraphy.get for full telemetry record bodies, stratigraphy.get_digest for source-record fingerprints, and stratigraphy.get_diff for parameter deltas between two entries.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum compressed records returned from startTarget toward endTarget, 1-100 (default 50); smaller limits truncate the batch. Constraints: minimum: 1; maximum: 100. Example: 50. | |
| format | No | Compression of every returned record: compact (default), minimal, or kv; does not change selected bounds. Constraints: allowed values: compact, minimal, kv. Example: "compact". | compact |
| endTarget | No | Optional inclusive ending indexed height, UTC ISO date, or 'latest' (default: latest indexed entry, not live tip); must resolve no earlier than startTarget. Constraints: pattern: ^(?:latest|(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "latest". | latest |
| startTarget | Yes | Required inclusive starting indexed height (e.g. '850000') or UTC ISO date (e.g. '2026-01-01'); must resolve no later than endTarget. Constraints: pattern: ^(?:(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "919712". |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of records returned, at most limit. Constraints: minimum: 1; maximum: 100. Example: 2. |
| range | Yes | Requested bounds, including default latest if omitted. |
| format | Yes | Compression format of each record. Constraints: allowed values: compact, minimal, kv. Example: "compact". |
| records | Yes | Records in ascending indexed order; compact strings, minimal arrays, or terse key-value objects. Constraints: minItems: 1; maxItems: 100. Example: ["HEIGHT:919856|DATE:2026-09-08|TM:125.5|HASH:0123456789abcdef"]. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real operational context beyond them: HTTP rate-limiting, L402 payment requirement, that endTarget 'latest' means latest indexed entry rather than the live tip, and that limit truncates the batch without altering the requested bounds.
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?
Three well-ordered sentences: purpose, behavioral constraints, sibling routing. Front-loaded and essentially waste-free, though the middle clause is densely packed with several constraints in a row.
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?
With an output schema present, the description needn't explain return shape, and it fully covers selection semantics, defaults, cost/rate constraints, and alternative tools. Nothing an agent needs to call this 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 description coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: startTarget is required, endTarget defaults to the latest indexed entry (explicitly not the live tip), and limit caps at 1-100 default 50 without changing the requested span. The 'without changing the requested bounds' clarification is genuinely useful routing/behavioral detail.
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 (retrieve a contiguous span of compressed indexed stratum summaries) with explicit scope over inclusive height or UTC date bounds. It also names the sibling tools it is not (stratigraphy.get, get_digest, get_diff), letting an agent distinguish it without opening another schema.
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?
Explicitly routes: 'Primary tool for compact multi-record spans; use stratigraphy.get for full telemetry record bodies, stratigraphy.get_digest for source-record fingerprints, and stratigraphy.get_diff for parameter deltas.' Both the when-to-use and the alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stratigraphy.listList Stratigraphy CatalogARead-onlyIdempotentInspect
Discover indexed height and UTC date bounds, available metrics, and catalog metadata. Free, parameterless, read-only discovery entry point for selecting valid strata. Once bounds are known, use stratigraphy.get for full record bodies, stratigraphy.get_range for compact contiguous spans, or stratigraphy.get_digest for lightweight source-record fingerprints.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| dateBounds | Yes | Inclusive ISO date bounds of the available snapshots. |
| newestBlock | Yes | Highest block height in the deterministic daily snapshot index. Constraints: minimum: 0. Example: 920000. |
| oldestBlock | Yes | Lowest block height in the deterministic daily snapshot index. Constraints: minimum: 0. Example: 859376. |
| totalSnapshots | Yes | Total number of daily stratigraphy snapshots currently available. Constraints: minimum: 1. Example: 422. |
| availableMetrics | Yes | Telemetry metric paths available in each stratigraphy snapshot. Example: ["day","title","video_id","transcript_summary","quantitative_alpha.target_multiplier","quantitative_alpha.difficulty_epoch_progress","quantitative_alpha.thermodynamic_signal"]. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds genuinely new context: it is free to call and is a prerequisite discovery step for selecting records. It does not discuss pagination or catalog size, which is a minor gap given an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero waste: the first front-loads what is returned, the second front-loads the usage condition and then enumerates the alternatives. Nothing redundant with the title or annotations.
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 parameterless discovery tool with an output schema, an agent needs purpose, cost, safety, and downstream routing — all present. Return-value detail is correctly delegated to the output schema, so nothing required for a correct call 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?
Zero parameters, so the baseline is 4. The description reinforces the parameterless contract, matching the schema's 'Pass {} ... any parameter is rejected,' and adds no misleading argument hints.
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 — discovering indexed height/UTC date bounds, available metrics, and catalog metadata — and names it as the read-only discovery entry point for the stratigraphy family. An agent can immediately distinguish it from stratigraphy.get, get_range, and get_digest, which are all named explicitly.
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?
Gives explicit when-to-use ('before selecting valid strata'), the sequencing condition ('once bounds are known'), and routes to the correct alternative for each downstream need (full bodies, contiguous spans, fingerprints). No inference required to pick the right sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
payment.get_info8 fields changed- changed
Input schema / oneOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "action": { - "const": "query", - "default": "query", - "description": "Pricing query (default). Example: \"query\".", - "example": "query", - "examples": [ - "query" - ], - "type": "string" - }, - "toolName": { - "description": "Optional case-sensitive canonical MCP tool identifier (e.g., 'stratigraphy.get_digest' or 'proof.verify'); supported legacy aliases are also accepted and resolve to canonical names. When provided, filters output to return pricing specifically for that single tool. When omitted, returns the full pricing map across all registered catalog tools. Must match an exact registered tool name or supported legacy alias. Constraints: minLength: 1. Example: \"stratigraphy.get_digest\".", - "example": "stratigraphy.get_digest", - "examples": [ - "stratigraphy.get_digest" - ], - "minLength": 1, - "type": "string" - } - }, - "type": "object" - }, - { - "additionalProperties": false, - "description": "Payment identifier and one payment proof; the matching signed L402 or x402 credential must be supplied in HTTP headers.", - "examples": [ - { - "paymentHash": "abababababababababababababababababababababababababababababababab", - "preimage": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" - }, - { - "paymentHash": "0xabababababababababababababababababababababababababababababababab", - "txHash": "0xabababababababababababababababababababababababababababababababab" - } - ], - "oneOf": [ - { - "required": [ - "preimage" - ] - }, - { - "required": [ - "txHash" - ] - } - ], - "properties": { - "action": { - "const": "settle", - "description": "Verify or execute payment settlement. Example: \"settle\".", - "example": "settle", - "examples": [ - "settle" - ], - "type": "string" - }, - "paymentHash": { - "description": "L402 SHA-256 invoice hash, or Base tx hash when using x402. Constraints: pattern: ^(0x)?[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", - "example": "abababababababababababababababababababababababababababababababab", - "examples": [ - "abababababababababababababababababababababababababababababababab" - ], - "pattern": "^(0x)?[0-9a-fA-F]{64}$", - "type": "string" - }, - "preimage": { - "description": "L402 32-byte hex preimage; also send Authorization: L402 <server-issued macaroon>:<preimage>. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd\".", - "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", - "examples": [ - "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" - ], - "pattern": "^[0-9a-fA-F]{64}$", - "type": "string" - }, - "txHash": { - "description": "Base mainnet transaction hash, accepted only after facilitator settlement of PAYMENT-SIGNATURE. Constraints: pattern: ^0x[0-9a-fA-F]{64}$. Example: \"0xabababababababababababababababababababababababababababababababab\".", - "example": "0xabababababababababababababababababababababababababababababababab", - "examples": [ - "0xabababababababababababababababababababababababababababababababab" - ], - "pattern": "^0x[0-9a-fA-F]{64}$", - "type": "string" - } - }, - "required": [ - "action", - "paymentHash" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "action": { + "const": "query", + "default": "query", + "description": "Pricing query (default). Example: \"query\".", + "example": "query", + "examples": [ + "query" + ], + "type": "string" + }, + "toolName": { + "description": "Optional case-sensitive canonical MCP tool identifier (e.g., 'stratigraphy.get_digest' or 'proof.verify'); supported legacy aliases are also accepted and resolve to canonical names. When provided, filters output to return pricing specifically for that single tool. When omitted, returns the full pricing map across all registered catalog tools. Must match an exact registered tool name or supported legacy alias. Constraints: minLength: 1. Example: \"stratigraphy.get_digest\".", + "example": "stratigraphy.get_digest", + "examples": [ + "stratigraphy.get_digest" + ], + "minLength": 1, + "type": "string" + } + }, + "type": "object" + }, + { + "additionalProperties": false, + "description": "Payment identifier and one payment proof; the matching signed L402 or x402 credential must be supplied in HTTP headers.", + "examples": [ + { + "paymentHash": "abababababababababababababababababababababababababababababababab", + "preimage": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + }, + { + "paymentHash": "0xabababababababababababababababababababababababababababababababab", + "txHash": "0xabababababababababababababababababababababababababababababababab" + } + ], + "oneOf": [ + { + "required": [ + "preimage" + ] + }, + { + "required": [ + "txHash" + ] + } + ], + "properties": { + "action": { + "const": "settle", + "description": "Verify or execute payment settlement. Example: \"settle\".", + "example": "settle", + "examples": [ + "settle" + ], + "type": "string" + }, + "paymentHash": { + "description": "L402 SHA-256 invoice hash, or Base tx hash when using x402. Constraints: pattern: ^(0x)?[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "pattern": "^(0x)?[0-9a-fA-F]{64}$", + "type": "string" + }, + "paymentMacaroon": { + "description": "Original invoice macaroon, separate from this tool's paid access credential. Constraints: minLength: 1; maxLength: 8192. Example: \"eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ\".", + "example": "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ", + "examples": [ + "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ" + ], + "maxLength": 8192, + "minLength": 1, + "type": "string" + }, + "preimage": { + "description": "L402 32-byte hex preimage; also send Authorization: L402 <server-issued macaroon>:<preimage>. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd\".", + "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "examples": [ + "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + ], + "pattern": "^[0-9a-fA-F]{64}$", + "type": "string" + }, + "txHash": { + "description": "Base mainnet transaction hash, accepted only after facilitator settlement of PAYMENT-SIGNATURE. Constraints: pattern: ^0x[0-9a-fA-F]{64}$. Example: \"0xabababababababababababababababababababababababababababababababab\".", + "example": "0xabababababababababababababababababababababababababababababababab", + "examples": [ + "0xabababababababababababababababababababababababababababababababab" + ], + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" + } + }, + "required": [ + "action", + "paymentHash" + ], + "type": "object" + } +] - added
Input schema / properties / paymentMacaroonAdded value: +{ + "description": "Original invoice macaroon, separate from this tool's paid access credential. Constraints: minLength: 1; maxLength: 8192. Example: \"eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ\".", + "example": "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ", + "examples": [ + "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ" + ], + "maxLength": 8192, + "minLength": 1, + "type": "string" +} - changed
Output schema / properties / activeAuthSchemes / descriptionPrevious value: -"Authentication scheme for paid MCP calls; free discovery and payment.get_info require none. Example: [\"L402\"]."New value: +"Authentication schemes for paid MCP calls. Only stratigraphy.list and proof.list execute free. Example: [\"L402\"]." - changed
Output schema / properties / macaroonRequirements / descriptionPrevious value: -"A valid payment proof must match the bound invoice, provider, amount, path, expiry and single-use restriction. proof.attenuate is free but requires a valid parent token."New value: +"A valid payment proof must match the bound invoice, provider, amount, path, expiry and request quota. proof.attenuate requires payment and a valid parent token." - removed
Output schema / properties / macaroonRequirements / properties / maxRequests / constRemoved value: -1 - changed
Output schema / properties / macaroonRequirements / properties / maxRequests / descriptionPrevious value: -"Each issued paid-tool macaroon is single-use. Example: 1."New value: +"Default credentials allow one call; X-L402-Batch-Size: 100 buys a tool-scoped 100-call credential. Constraints: allowed values: 1, 100. Example: 1." - added
Output schema / properties / macaroonRequirements / properties / maxRequests / enumAdded value: +[ + 1, + 100 +] - changed
Output schema / properties / macaroonRequirements / properties / maxRequests / examplesPrevious value: -[ - 1 -]New value: +[ + 1, + 100 +]
- Added
proof.notarize
9 tool updates
- Added
payment.get_info - Removed
payment.info - Changed
proof.attenuate4 fields changed- changed
Input schema / examplesPrevious value: -[ - { - "caveats": [ - "allowed_tools = stratigraphy.get,stratigraphy.digest", - "max_target = 870000" - ], - "macaroon": "base64url-parent-macaroon", - "ttlSeconds": 3600 - } -]New value: +[ + { + "caveats": [ + "allowed_tools = stratigraphy.get,stratigraphy.get_digest", + "max_target = 870000" + ], + "macaroon": "base64url-parent-macaroon", + "ttlSeconds": 3600 + } +] - changed
Input schema / properties / caveats / descriptionPrevious value: -"List of restriction caveats to append (e.g. ['time_before = 2026-12-31', 'max_target = 870000', 'allowed_tools = stratigraphy.get,stratigraphy.digest']). Existing allowed_path and max_requests restrictions are also supported. Constraints: maxItems: 16. Example: [\"time_before = 2026-12-31\",\"max_target = 870000\",\"allowed_tools = stratigraphy.get,stratigraphy.digest\"]."New value: +"List of restriction caveats to append (e.g. ['time_before = 2026-12-31', 'max_target = 870000', 'allowed_tools = stratigraphy.get,stratigraphy.get_digest']). Existing allowed_path and max_requests restrictions are also supported. Constraints: maxItems: 16. Example: [\"time_before = 2026-12-31\",\"max_target = 870000\",\"allowed_tools = stratigraphy.get,stratigraphy.get_digest\"]." - changed
Input schema / properties / caveats / examplePrevious value: -[ - "time_before = 2026-12-31", - "max_target = 870000", - "allowed_tools = stratigraphy.get,stratigraphy.digest" -]New value: +[ + "time_before = 2026-12-31", + "max_target = 870000", + "allowed_tools = stratigraphy.get,stratigraphy.get_digest" +] - changed
Input schema / properties / caveats / examplesPrevious value: -[ - [ - "time_before = 2026-12-31", - "max_target = 870000", - "allowed_tools = stratigraphy.get,stratigraphy.digest" - ] -]New value: +[ + [ + "time_before = 2026-12-31", + "max_target = 870000", + "allowed_tools = stratigraphy.get,stratigraphy.get_digest" + ] +]
- Removed
stratigraphy.diff - Removed
stratigraphy.digest - Added
stratigraphy.get_diff - Added
stratigraphy.get_digest - Added
stratigraphy.get_range - Removed
stratigraphy.range
4 tool updates
- Changed
payment.info13 fields changed- changed
Input schema / descriptionPrevious value: -"Pass an optional canonical toolName to narrow the returned price map; omit it for all advertised prices. This free request does not issue an invoice."New value: +"Query pricing (default) or settle a matching authenticated Lightning or Base payment." - changed
Input schema / examplesPrevious value: -[ - {}, - { - "toolName": "stratigraphy.digest" - } -]New value: +[ + {}, + { + "action": "settle", + "paymentHash": "abababababababababababababababababababababababababababababababab", + "preimage": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + } +] - added
Input schema / oneOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "action": { + "const": "query", + "default": "query", + "description": "Pricing query (default). Example: \"query\".", + "example": "query", + "examples": [ + "query" + ], + "type": "string" + }, + "toolName": { + "description": "Optional case-sensitive canonical MCP tool identifier (e.g., 'stratigraphy.digest' or 'proof.verify'). When provided, filters output to return pricing specifically for that single tool. When omitted, returns the full pricing map across all registered catalog tools. Must match an exact registered tool name string. Constraints: minLength: 1. Example: \"stratigraphy.digest\".", + "example": "stratigraphy.digest", + "examples": [ + "stratigraphy.digest" + ], + "minLength": 1, + "type": "string" + } + }, + "type": "object" + }, + { + "additionalProperties": false, + "description": "Payment identifier and one payment proof; the matching signed L402 or x402 credential must be supplied in HTTP headers.", + "examples": [ + { + "paymentHash": "abababababababababababababababababababababababababababababababab", + "preimage": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + }, + { + "paymentHash": "0xabababababababababababababababababababababababababababababababab", + "txHash": "0xabababababababababababababababababababababababababababababababab" + } + ], + "oneOf": [ + { + "required": [ + "preimage" + ] + }, + { + "required": [ + "txHash" + ] + } + ], + "properties": { + "action": { + "const": "settle", + "description": "Verify or execute payment settlement. Example: \"settle\".", + "example": "settle", + "examples": [ + "settle" + ], + "type": "string" + }, + "paymentHash": { + "description": "L402 SHA-256 invoice hash, or Base tx hash when using x402. Constraints: pattern: ^(0x)?[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "pattern": "^(0x)?[0-9a-fA-F]{64}$", + "type": "string" + }, + "preimage": { + "description": "L402 32-byte hex preimage; also send Authorization: L402 <server-issued macaroon>:<preimage>. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd\".", + "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "examples": [ + "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + ], + "pattern": "^[0-9a-fA-F]{64}$", + "type": "string" + }, + "txHash": { + "description": "Base mainnet transaction hash, accepted only after facilitator settlement of PAYMENT-SIGNATURE. Constraints: pattern: ^0x[0-9a-fA-F]{64}$. Example: \"0xabababababababababababababababababababababababababababababababab\".", + "example": "0xabababababababababababababababababababababababababababababababab", + "examples": [ + "0xabababababababababababababababababababababababababababababababab" + ], + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" + } + }, + "required": [ + "action", + "paymentHash" + ], + "type": "object" + } +] - added
Input schema / properties / actionAdded value: +{ + "default": "query", + "description": "query (default) discovers prices; settle verifies authenticated payment. Constraints: allowed values: query, settle. Example: \"query\".", + "enum": [ + "query", + "settle" + ], + "example": "query", + "examples": [ + "query" + ], + "type": "string" +} - added
Input schema / properties / paymentHashAdded value: +{ + "description": "L402 SHA-256 invoice hash, or Base tx hash when using x402. Constraints: pattern: ^(0x)?[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "pattern": "^(0x)?[0-9a-fA-F]{64}$", + "type": "string" +} - added
Input schema / properties / preimageAdded value: +{ + "description": "L402 32-byte hex preimage; also send Authorization: L402 <server-issued macaroon>:<preimage>. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd\".", + "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "examples": [ + "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + ], + "pattern": "^[0-9a-fA-F]{64}$", + "type": "string" +} - added
Input schema / properties / txHashAdded value: +{ + "description": "Base mainnet transaction hash, accepted only after facilitator settlement of PAYMENT-SIGNATURE. Constraints: pattern: ^0x[0-9a-fA-F]{64}$. Example: \"0xabababababababababababababababababababababababababababababababab\".", + "example": "0xabababababababababababababababababababababababababababababababab", + "examples": [ + "0xabababababababababababababababababababababababababababababababab" + ], + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" +} - changed
Output schema / descriptionPrevious value: -"Configured MCP prices in sats (zero denotes a free tool), Lightning L402 rules, and optional Base USDC x402 terms. No live invoice is created by this tool."New value: +"Pricing details for query, or non-transferable payment verification claims for settle." - changed
Output schema / examplesPrevious value: -[ - { - "acceptedPaymentMethods": [ - "Lightning L402" - ], - "activeAuthSchemes": [ - "L402" - ], - "challenge": { - "fields": [ - "macaroon", - "invoice", - "payment_hash", - "amount_sats" - ], - "header": "WWW-Authenticate", - "httpStatus": 402 - }, - "invoiceExpirySeconds": 3600, - "macaroonRequirements": { - "authorizationHeader": "L402 <macaroon>:<preimage>", - "maxRequests": 1, - "scope": "exact MCP tool path" - }, - "perToolSats": { - "stratigraphy.digest": 250 - }, - "standardInvoiceSats": 250 - } -]New value: +[ + { + "acceptedPaymentMethods": [ + "Lightning L402" + ], + "activeAuthSchemes": [ + "L402" + ], + "challenge": { + "fields": [ + "macaroon", + "invoice", + "payment_hash", + "amount_sats" + ], + "header": "WWW-Authenticate", + "httpStatus": 402 + }, + "invoiceExpirySeconds": 3600, + "macaroonRequirements": { + "authorizationHeader": "L402 <macaroon>:<preimage>", + "maxRequests": 1, + "scope": "exact MCP tool path" + }, + "perToolSats": { + "stratigraphy.digest": 250 + }, + "standardInvoiceSats": 250 + }, + { + "settlementToken": { + "paymentHash": "abababababababababababababababababababababababababababababababab", + "scheme": "L402", + "scope": "/mcp/tools/stratigraphy.get", + "settledAt": "2026-09-28T12:00:00.000Z" + }, + "verified": true + } +] - added
Output schema / oneOfAdded value: +[ + { + "required": [ + "standardInvoiceSats", + "perToolSats", + "acceptedPaymentMethods", + "invoiceExpirySeconds", + "challenge", + "activeAuthSchemes", + "macaroonRequirements" + ] + }, + { + "required": [ + "verified", + "settlementToken" + ] + } +] - added
Output schema / properties / settlementTokenAdded value: +{ + "additionalProperties": false, + "description": "Verified payment claims, not a bearer token or a grant of tool access.", + "examples": [ + { + "paymentHash": "abababababababababababababababababababababababababababababababab", + "scheme": "L402", + "scope": "/mcp/tools/stratigraphy.get", + "settledAt": "2026-09-28T12:00:00.000Z" + } + ], + "properties": { + "paymentHash": { + "description": "Verified Lightning invoice hash or Base transaction hash. Example: \"abababababababababababababababababababababababababababababababab\".", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "type": "string" + }, + "scheme": { + "description": "Settlement rail. Constraints: allowed values: L402, x402. Example: \"L402\".", + "enum": [ + "L402", + "x402" + ], + "example": "L402", + "examples": [ + "L402" + ], + "type": "string" + }, + "scope": { + "description": "Original L402 tool path or x402 MCP resource path; this receipt cannot expand access. Example: \"/mcp/tools/stratigraphy.get\".", + "example": "/mcp/tools/stratigraphy.get", + "examples": [ + "/mcp/tools/stratigraphy.get" + ], + "type": "string" + }, + "settledAt": { + "description": "Settlement verification time as ISO 8601 UTC. Constraints: format: date-time. Example: \"2026-09-28T12:00:00.000Z\".", + "example": "2026-09-28T12:00:00.000Z", + "examples": [ + "2026-09-28T12:00:00.000Z" + ], + "format": "date-time", + "type": "string" + } + }, + "required": [ + "scheme", + "paymentHash", + "scope", + "settledAt" + ], + "type": [ + "object", + "null" + ] +} - added
Output schema / properties / verifiedAdded value: +{ + "description": "Whether the signed, server-bound payment was verified or settled. Example: true.", + "example": true, + "examples": [ + true + ], + "type": "boolean" +} - changed
Output schema / requiredPrevious value: -[ - "standardInvoiceSats", - "perToolSats", - "acceptedPaymentMethods", - "invoiceExpirySeconds", - "challenge", - "activeAuthSchemes", - "macaroonRequirements" -]New value: +[]
- Removed
payment.settle - Changed
proof.verify11 fields changed- changed
Input schema / descriptionPrevious value: -"Input arguments containing an encoded Groth16 proof, typed public inputs, a verification-key identifier, and telemetry data."New value: +"Select groth16 (default) or ots, supplying only fields for the selected verification path." - changed
Input schema / examplesPrevious value: -[ - { - "data": [ - { - "block": { - "height": 920000 - }, - "observed_at": "2026-09-19T00:00:00.000Z", - "thermodynamic": { - "target_multiplier": 125.83 - } - } - ], - "proof": "eyJwaV9hIjpbIjEyMyIsIjQ1NiIsIjEiXX0", - "publicInputs": { - "blockHeight": 920000, - "snapshotDigest": "1534979302823651498736582947365829473658294736582947365829473658294", - "thermodynamicHash": "782365829473658294736582947365829473658294736582947365829473658294", - "timestamp": 1789776000000, - "valuationSat": 12583 - }, - "verificationKeyId": "sha256:4c095e183ea45a9d" - }, - { - "blockHash": "abababababababababababababababababababababababababababababababab", - "circuit": "zk.drift.v1", - "compactTarget": 486604799, - "driftScore": 0.25, - "entropyThreshold": 0.75, - "isAligned": true, - "proof": { - "circuit": "zk.drift.v1", - "pi_a": [ - "1", - "2", - "1" - ], - "pi_b": [ - [ - "1", - "2" - ], - [ - "3", - "4" - ], - [ - "1", - "0" - ] - ], - "pi_c": [ - "1", - "2", - "1" - ], - "publicSignals": [ - "1", - "2" - ], - "verificationKeyId": "sha256:4c095e183ea45a9d" - }, - "sessionContextHash": "abababababababababababababababababababababababababababababababab", - "targetBlockHeight": 920000, - "thermodynamicEntropyBits": 0.5 - } -]New value: +[ + { + "data": [ + { + "block": { + "height": 920000 + }, + "observed_at": "2026-09-19T00:00:00.000Z", + "thermodynamic": { + "target_multiplier": 125.83 + } + } + ], + "proof": "eyJwaV9hIjpbIjEyMyIsIjQ1NiIsIjEiXX0", + "publicInputs": { + "blockHeight": 920000, + "snapshotDigest": "1534979302823651498736582947365829473658294736582947365829473658294", + "thermodynamicHash": "782365829473658294736582947365829473658294736582947365829473658294", + "timestamp": 1789776000000, + "valuationSat": 12583 + }, + "verificationKeyId": "sha256:4c095e183ea45a9d" + }, + { + "blockHash": "abababababababababababababababababababababababababababababababab", + "circuit": "zk.drift.v1", + "compactTarget": 486604799, + "driftScore": 0.25, + "entropyThreshold": 0.75, + "isAligned": true, + "proof": { + "circuit": "zk.drift.v1", + "pi_a": [ + "1", + "2", + "1" + ], + "pi_b": [ + [ + "1", + "2" + ], + [ + "3", + "4" + ], + [ + "1", + "0" + ] + ], + "pi_c": [ + "1", + "2", + "1" + ], + "publicSignals": [ + "1", + "2" + ], + "verificationKeyId": "sha256:4c095e183ea45a9d" + }, + "sessionContextHash": "abababababababababababababababababababababababababababababababab", + "targetBlockHeight": 920000, + "thermodynamicEntropyBits": 0.5 + }, + { + "otsProof": "AQID", + "proofType": "ots", + "targetHash": "abababababababababababababababababababababababababababababababab" + } +] - changed
Input schema / oneOfPrevious value: -[ - { - "additionalProperties": false, - "description": "Legacy telemetry-bound Groth16 proof verification input. Example: provide a proof, public inputs, verification key, and telemetry data.", - "examples": [ - { - "data": [ - { - "block": { - "height": 920000 - }, - "observed_at": "2026-09-19T00:00:00.000Z", - "thermodynamic": { - "target_multiplier": 125.83 - } - } - ], - "proof": "eyJwaV9hIjpbIjEyMyIsIjQ1NiIsIjEiXX0", - "publicInputs": { - "blockHeight": 920000, - "snapshotDigest": "1534979302823651498736582947365829473658294736582947365829473658294", - "thermodynamicHash": "782365829473658294736582947365829473658294736582947365829473658294", - "timestamp": 1789776000000, - "valuationSat": 12583 - }, - "verificationKeyId": "sha256:4c095e183ea45a9d" - } - ], - "properties": { - "data": { - "description": "Telemetry snapshot payload object or array of objects containing canonical state values. Example: [{\"block\":{\"height\":920000},\"observed_at\":\"2026-09-19T00:00:00.000Z\",\"thermodynamic\":{\"target_multiplier\":125.83}}].", - "example": [ - { - "block": { - "height": 920000 - }, - "observed_at": "2026-09-19T00:00:00.000Z", - "thermodynamic": { - "target_multiplier": 125.83 - } - } - ], - "examples": [ - [ - { - "block": { - "height": 920000 - }, - "observed_at": "2026-09-19T00:00:00.000Z", - "thermodynamic": { - "target_multiplier": 125.83 - } - } - ] - ], - "type": [ - "object", - "array" - ] - }, - "proof": { - "description": "Base64url-encoded Groth16/Poseidon BN254 proof string without padding. Constraints: minLength: 1. Example: \"eyJwaV9hIjpbIjEyMyIsIjQ1NiIsIjEiXX0\".", - "example": "eyJwaV9hIjpbIjEyMyIsIjQ1NiIsIjEiXX0", - "examples": [ - "eyJwaV9hIjpbIjEyMyIsIjQ1NiIsIjEiXX0" - ], - "minLength": 1, - "type": "string" - }, - "publicInputs": { - "additionalProperties": false, - "description": "Expected public constants committed by the proof; fields must match the corresponding telemetry payload in data: non-negative blockHeight, non-empty snapshotDigest and thermodynamicHash, non-negative Unix-millisecond timestamp, and non-negative valuationSat. Example: blockHeight 920000 and valuationSat 12583.", - "examples": [ - { - "blockHeight": 920000, - "snapshotDigest": "1534979302823651498736582947365829473658294736582947365829473658294", - "thermodynamicHash": "782365829473658294736582947365829473658294736582947365829473658294", - "timestamp": 1789776000000, - "valuationSat": 12583 - } - ], - "properties": { - "blockHeight": { - "description": "Bitcoin block height committed into the proof. Constraints: minimum: 0. Example: 920000.", - "example": 920000, - "examples": [ - 920000 - ], - "minimum": 0, - "type": "integer" - }, - "snapshotDigest": { - "description": "Poseidon field digest of the canonical snapshot payload. Constraints: minLength: 1. Example: \"1534979302823651498736582947365829473658294736582947365829473658294\".", - "example": "1534979302823651498736582947365829473658294736582947365829473658294", - "examples": [ - "1534979302823651498736582947365829473658294736582947365829473658294" - ], - "minLength": 1, - "type": "string" - }, - "thermodynamicHash": { - "description": "Poseidon field hash of the thermodynamic telemetry values. Constraints: minLength: 1. Example: \"782365829473658294736582947365829473658294736582947365829473658294\".", - "example": "782365829473658294736582947365829473658294736582947365829473658294", - "examples": [ - "782365829473658294736582947365829473658294736582947365829473658294" - ], - "minLength": 1, - "type": "string" - }, - "timestamp": { - "description": "Unix timestamp in milliseconds committed into the proof. Constraints: minimum: 0. Example: 1789776000000.", - "example": 1789776000000, - "examples": [ - 1789776000000 - ], - "minimum": 0, - "type": "integer" - }, - "valuationSat": { - "description": "Satoshi valuation committed into the proof. Constraints: minimum: 0. Example: 12583.", - "example": 12583, - "examples": [ - 12583 - ], - "minimum": 0, - "type": "integer" - } - }, - "required": [ - "blockHeight", - "snapshotDigest", - "thermodynamicHash", - "timestamp", - "valuationSat" - ], - "type": "object" - }, - "verificationKeyId": { - "description": "SHA-256 verification-key identifier string formatted with 'sha256:' prefix. Constraints: minLength: 1. Example: \"sha256:4c095e183ea45a9d\".", - "example": "sha256:4c095e183ea45a9d", - "examples": [ - "sha256:4c095e183ea45a9d" - ], - "minLength": 1, - "type": "string" - } - }, - "required": [ - "proof", - "publicInputs", - "verificationKeyId", - "data" - ], - "type": "object" - }, - { - "additionalProperties": false, - "description": "Native zk.drift.v1 proof verification input, optionally bound to the complete verifier response. Example: supply the circuit discriminator, session hash, target height, threshold, and proof.", - "examples": [ - { - "blockHash": "abababababababababababababababababababababababababababababababab", - "circuit": "zk.drift.v1", - "compactTarget": 486604799, - "driftScore": 0.25, - "entropyThreshold": 0.75, - "isAligned": true, - "proof": { - "circuit": "zk.drift.v1", - "pi_a": [ - "1", - "2", - "1" - ], - "pi_b": [ - [ - "1", - "2" - ], - [ - "3", - "4" - ], - [ - "1", - "0" - ] - ], - "pi_c": [ - "1", - "2", - "1" - ], - "publicSignals": [ - "1", - "2" - ], - "verificationKeyId": "sha256:4c095e183ea45a9d" - }, - "sessionContextHash": "abababababababababababababababababababababababababababababababab", - "targetBlockHeight": 920000, - "thermodynamicEntropyBits": 0.5 - } - ], - "properties": { - "blockHash": { - "description": "Bitcoin block hash bound to the complete verifier response. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", - "example": "abababababababababababababababababababababababababababababababab", - "examples": [ - "abababababababababababababababababababababababababababababababab" - ], - "pattern": "^[0-9a-fA-F]{64}$", - "type": "string" - }, - "circuit": { - "const": "zk.drift.v1", - "description": "Drift proof circuit discriminator. Example: \"zk.drift.v1\".", - "example": "zk.drift.v1", - "examples": [ - "zk.drift.v1" - ], - "type": "string" - }, - "compactTarget": { - "description": "Raw compact target bits bound to the complete verifier response. Constraints: minimum: 0; maximum: 4294967295. Example: 486604799.", - "example": 486604799, - "examples": [ - 486604799 - ], - "maximum": 4294967295, - "minimum": 0, - "type": "integer" - }, - "driftScore": { - "description": "Drift score bound to the complete verifier response. Example: 0.25.", - "example": 0.25, - "examples": [ - 0.25 - ], - "type": "number" - }, - "entropyThreshold": { - "description": "Maximum accepted thermodynamic entropy threshold. Constraints: minimum: 0; maximum: 1. Example: 0.75.", - "example": 0.75, - "examples": [ - 0.75 - ], - "maximum": 1, - "minimum": 0, - "type": "number" - }, - "isAligned": { - "description": "Alignment result bound to the complete verifier response. Example: true.", - "example": true, - "examples": [ - true - ], - "type": "boolean" - }, - "proof": { - "additionalProperties": false, - "description": "Groth16 proof points, public signals, and verification-key identifier for zk.drift.v1. Example: pi_a, pi_b, pi_c, and public signals.", - "examples": [ - { - "circuit": "zk.drift.v1", - "pi_a": [ - "1", - "2", - "1" - ], - "pi_b": [ - [ - "1", - "2" - ], - [ - "3", - "4" - ], - [ - "1", - "0" - ] - ], - "pi_c": [ - "1", - "2", - "1" - ], - "publicSignals": [ - "1", - "2" - ], - "verificationKeyId": "sha256:4c095e183ea45a9d" - } - ], - "properties": { - "circuit": { - "const": "zk.drift.v1", - "description": "Proof circuit discriminator. Example: \"zk.drift.v1\".", - "example": "zk.drift.v1", - "examples": [ - "zk.drift.v1" - ], - "type": "string" - }, - "pi_a": { - "description": "Three Groth16 pi_a field elements. Example: [\"1\", \"2\", \"1\"].", - "examples": [ - [ - "1", - "2", - "1" - ] - ], - "items": { - "description": "Groth16 pi_a field element. Constraints: minLength: 1. Example: \"1\".", - "example": "1", - "examples": [ - "1" - ], - "minLength": 1, - "type": "string" - }, - "maxItems": 3, - "minItems": 3, - "type": "array" - }, - "pi_b": { - "description": "Three pairs of Groth16 pi_b field elements. Example: [[\"1\", \"2\"], [\"3\", \"4\"], [\"1\", \"0\"]].", - "examples": [ - [ - [ - "1", - "2" - ], - [ - "3", - "4" - ], - [ - "1", - "0" - ] - ] - ], - "items": { - "description": "A pair of Groth16 pi_b field elements. Example: [\"1\", \"2\"].", - "examples": [ - [ - "1", - "2" - ] - ], - "items": { - "description": "Groth16 pi_b field element. Constraints: minLength: 1. Example: \"1\".", - "example": "1", - "examples": [ - "1" - ], - "minLength": 1, - "type": "string" - }, - "maxItems": 2, - "minItems": 2, - "type": "array" - }, - "maxItems": 3, - "minItems": 3, - "type": "array" - }, - "pi_c": { - "description": "Three Groth16 pi_c field elements. Example: [\"1\", \"2\", \"1\"].", - "examples": [ - [ - "1", - "2", - "1" - ] - ], - "items": { - "description": "Groth16 pi_c field element. Constraints: minLength: 1. Example: \"1\".", - "example": "1", - "examples": [ - "1" - ], - "minLength": 1, - "type": "string" - }, - "maxItems": 3, - "minItems": 3, - "type": "array" - }, - "publicSignals": { - "description": "Public field elements bound to the drift proof. Example: [\"1\", \"2\"].", - "examples": [ - [ - "1", - "2" - ] - ], - "items": { - "description": "Public signal field element. Constraints: minLength: 1. Example: \"1\".", - "example": "1", - "examples": [ - "1" - ], - "minLength": 1, - "type": "string" - }, - "minItems": 1, - "type": "array" - }, - "verificationKeyId": { - "description": "Identifier of the verification key to use. Constraints: minLength: 1. Example: \"sha256:4c095e183ea45a9d\".", - "example": "sha256:4c095e183ea45a9d", - "examples": [ - "sha256:4c095e183ea45a9d" - ], - "minLength": 1, - "type": "string" - } - }, - "required": [ - "circuit", - "pi_a", - "pi_b", - "pi_c", - "publicSignals", - "verificationKeyId" - ], - "type": "object" - }, - "sessionContextHash": { - "description": "Hash binding this proof to its agent session context. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", - "example": "abababababababababababababababababababababababababababababababab", - "examples": [ - "abababababababababababababababababababababababababababababababab" - ], - "pattern": "^[0-9a-fA-F]{64}$", - "type": "string" - }, - "targetBlockHeight": { - "description": "Bitcoin block height being evaluated. Constraints: minimum: 0; maximum: 4294967295. Example: 920000.", - "example": 920000, - "examples": [ - 920000 - ], - "maximum": 4294967295, - "minimum": 0, - "type": "integer" - }, - "thermodynamicEntropyBits": { - "description": "Thermodynamic entropy value bound to the complete verifier response. Constraints: minimum: 0. Example: 0.5.", - "example": 0.5, - "examples": [ - 0.5 - ], - "minimum": 0, - "type": "number" - } - }, - "required": [ - "circuit", - "sessionContextHash", - "targetBlockHeight", - "entropyThreshold", - "proof" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "description": "Legacy telemetry-bound Groth16 proof verification input. Example: provide a proof, public inputs, verification key, and telemetry data.", + "examples": [ + { + "data": [ + { + "block": { + "height": 920000 + }, + "observed_at": "2026-09-19T00:00:00.000Z", + "thermodynamic": { + "target_multiplier": 125.83 + } + } + ], + "proof": "eyJwaV9hIjpbIjEyMyIsIjQ1NiIsIjEiXX0", + "publicInputs": { + "blockHeight": 920000, + "snapshotDigest": "1534979302823651498736582947365829473658294736582947365829473658294", + "thermodynamicHash": "782365829473658294736582947365829473658294736582947365829473658294", + "timestamp": 1789776000000, + "valuationSat": 12583 + }, + "verificationKeyId": "sha256:4c095e183ea45a9d" + } + ], + "properties": { + "data": { + "description": "Telemetry snapshot payload object or array of objects containing canonical state values. Example: [{\"block\":{\"height\":920000},\"observed_at\":\"2026-09-19T00:00:00.000Z\",\"thermodynamic\":{\"target_multiplier\":125.83}}].", + "example": [ + { + "block": { + "height": 920000 + }, + "observed_at": "2026-09-19T00:00:00.000Z", + "thermodynamic": { + "target_multiplier": 125.83 + } + } + ], + "examples": [ + [ + { + "block": { + "height": 920000 + }, + "observed_at": "2026-09-19T00:00:00.000Z", + "thermodynamic": { + "target_multiplier": 125.83 + } + } + ] + ], + "type": [ + "object", + "array" + ] + }, + "proof": { + "description": "Base64url-encoded Groth16/Poseidon BN254 proof string without padding. Constraints: minLength: 1. Example: \"eyJwaV9hIjpbIjEyMyIsIjQ1NiIsIjEiXX0\".", + "example": "eyJwaV9hIjpbIjEyMyIsIjQ1NiIsIjEiXX0", + "examples": [ + "eyJwaV9hIjpbIjEyMyIsIjQ1NiIsIjEiXX0" + ], + "minLength": 1, + "type": "string" + }, + "proofType": { + "const": "groth16", + "default": "groth16", + "description": "Groth16 verification (default). Example: \"groth16\".", + "example": "groth16", + "examples": [ + "groth16" + ], + "type": "string" + }, + "publicInputs": { + "additionalProperties": false, + "description": "Expected public constants committed by the proof; fields must match the corresponding telemetry payload in data: non-negative blockHeight, non-empty snapshotDigest and thermodynamicHash, non-negative Unix-millisecond timestamp, and non-negative valuationSat. Example: blockHeight 920000 and valuationSat 12583.", + "examples": [ + { + "blockHeight": 920000, + "snapshotDigest": "1534979302823651498736582947365829473658294736582947365829473658294", + "thermodynamicHash": "782365829473658294736582947365829473658294736582947365829473658294", + "timestamp": 1789776000000, + "valuationSat": 12583 + } + ], + "properties": { + "blockHeight": { + "description": "Bitcoin block height committed into the proof. Constraints: minimum: 0. Example: 920000.", + "example": 920000, + "examples": [ + 920000 + ], + "minimum": 0, + "type": "integer" + }, + "snapshotDigest": { + "description": "Poseidon field digest of the canonical snapshot payload. Constraints: minLength: 1. Example: \"1534979302823651498736582947365829473658294736582947365829473658294\".", + "example": "1534979302823651498736582947365829473658294736582947365829473658294", + "examples": [ + "1534979302823651498736582947365829473658294736582947365829473658294" + ], + "minLength": 1, + "type": "string" + }, + "thermodynamicHash": { + "description": "Poseidon field hash of the thermodynamic telemetry values. Constraints: minLength: 1. Example: \"782365829473658294736582947365829473658294736582947365829473658294\".", + "example": "782365829473658294736582947365829473658294736582947365829473658294", + "examples": [ + "782365829473658294736582947365829473658294736582947365829473658294" + ], + "minLength": 1, + "type": "string" + }, + "timestamp": { + "description": "Unix timestamp in milliseconds committed into the proof. Constraints: minimum: 0. Example: 1789776000000.", + "example": 1789776000000, + "examples": [ + 1789776000000 + ], + "minimum": 0, + "type": "integer" + }, + "valuationSat": { + "description": "Satoshi valuation committed into the proof. Constraints: minimum: 0. Example: 12583.", + "example": 12583, + "examples": [ + 12583 + ], + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "blockHeight", + "snapshotDigest", + "thermodynamicHash", + "timestamp", + "valuationSat" + ], + "type": "object" + }, + "verificationKeyId": { + "description": "SHA-256 verification-key identifier string formatted with 'sha256:' prefix. Constraints: minLength: 1. Example: \"sha256:4c095e183ea45a9d\".", + "example": "sha256:4c095e183ea45a9d", + "examples": [ + "sha256:4c095e183ea45a9d" + ], + "minLength": 1, + "type": "string" + } + }, + "required": [ + "proof", + "publicInputs", + "verificationKeyId", + "data" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "Native zk.drift.v1 proof verification input, optionally bound to the complete verifier response. Example: supply the circuit discriminator, session hash, target height, threshold, and proof.", + "examples": [ + { + "blockHash": "abababababababababababababababababababababababababababababababab", + "circuit": "zk.drift.v1", + "compactTarget": 486604799, + "driftScore": 0.25, + "entropyThreshold": 0.75, + "isAligned": true, + "proof": { + "circuit": "zk.drift.v1", + "pi_a": [ + "1", + "2", + "1" + ], + "pi_b": [ + [ + "1", + "2" + ], + [ + "3", + "4" + ], + [ + "1", + "0" + ] + ], + "pi_c": [ + "1", + "2", + "1" + ], + "publicSignals": [ + "1", + "2" + ], + "verificationKeyId": "sha256:4c095e183ea45a9d" + }, + "sessionContextHash": "abababababababababababababababababababababababababababababababab", + "targetBlockHeight": 920000, + "thermodynamicEntropyBits": 0.5 + } + ], + "properties": { + "blockHash": { + "description": "Bitcoin block hash bound to the complete verifier response. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "pattern": "^[0-9a-fA-F]{64}$", + "type": "string" + }, + "circuit": { + "const": "zk.drift.v1", + "description": "Drift proof circuit discriminator. Example: \"zk.drift.v1\".", + "example": "zk.drift.v1", + "examples": [ + "zk.drift.v1" + ], + "type": "string" + }, + "compactTarget": { + "description": "Raw compact target bits bound to the complete verifier response. Constraints: minimum: 0; maximum: 4294967295. Example: 486604799.", + "example": 486604799, + "examples": [ + 486604799 + ], + "maximum": 4294967295, + "minimum": 0, + "type": "integer" + }, + "driftScore": { + "description": "Drift score bound to the complete verifier response. Example: 0.25.", + "example": 0.25, + "examples": [ + 0.25 + ], + "type": "number" + }, + "entropyThreshold": { + "description": "Maximum accepted thermodynamic entropy threshold. Constraints: minimum: 0; maximum: 1. Example: 0.75.", + "example": 0.75, + "examples": [ + 0.75 + ], + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "isAligned": { + "description": "Alignment result bound to the complete verifier response. Example: true.", + "example": true, + "examples": [ + true + ], + "type": "boolean" + }, + "proof": { + "additionalProperties": false, + "description": "Groth16 proof points, public signals, and verification-key identifier for zk.drift.v1. Example: pi_a, pi_b, pi_c, and public signals.", + "examples": [ + { + "circuit": "zk.drift.v1", + "pi_a": [ + "1", + "2", + "1" + ], + "pi_b": [ + [ + "1", + "2" + ], + [ + "3", + "4" + ], + [ + "1", + "0" + ] + ], + "pi_c": [ + "1", + "2", + "1" + ], + "publicSignals": [ + "1", + "2" + ], + "verificationKeyId": "sha256:4c095e183ea45a9d" + } + ], + "properties": { + "circuit": { + "const": "zk.drift.v1", + "description": "Proof circuit discriminator. Example: \"zk.drift.v1\".", + "example": "zk.drift.v1", + "examples": [ + "zk.drift.v1" + ], + "type": "string" + }, + "pi_a": { + "description": "Three Groth16 pi_a field elements. Example: [\"1\", \"2\", \"1\"].", + "examples": [ + [ + "1", + "2", + "1" + ] + ], + "items": { + "description": "Groth16 pi_a field element. Constraints: minLength: 1. Example: \"1\".", + "example": "1", + "examples": [ + "1" + ], + "minLength": 1, + "type": "string" + }, + "maxItems": 3, + "minItems": 3, + "type": "array" + }, + "pi_b": { + "description": "Three pairs of Groth16 pi_b field elements. Example: [[\"1\", \"2\"], [\"3\", \"4\"], [\"1\", \"0\"]].", + "examples": [ + [ + [ + "1", + "2" + ], + [ + "3", + "4" + ], + [ + "1", + "0" + ] + ] + ], + "items": { + "description": "A pair of Groth16 pi_b field elements. Example: [\"1\", \"2\"].", + "examples": [ + [ + "1", + "2" + ] + ], + "items": { + "description": "Groth16 pi_b field element. Constraints: minLength: 1. Example: \"1\".", + "example": "1", + "examples": [ + "1" + ], + "minLength": 1, + "type": "string" + }, + "maxItems": 2, + "minItems": 2, + "type": "array" + }, + "maxItems": 3, + "minItems": 3, + "type": "array" + }, + "pi_c": { + "description": "Three Groth16 pi_c field elements. Example: [\"1\", \"2\", \"1\"].", + "examples": [ + [ + "1", + "2", + "1" + ] + ], + "items": { + "description": "Groth16 pi_c field element. Constraints: minLength: 1. Example: \"1\".", + "example": "1", + "examples": [ + "1" + ], + "minLength": 1, + "type": "string" + }, + "maxItems": 3, + "minItems": 3, + "type": "array" + }, + "publicSignals": { + "description": "Public field elements bound to the drift proof. Example: [\"1\", \"2\"].", + "examples": [ + [ + "1", + "2" + ] + ], + "items": { + "description": "Public signal field element. Constraints: minLength: 1. Example: \"1\".", + "example": "1", + "examples": [ + "1" + ], + "minLength": 1, + "type": "string" + }, + "minItems": 1, + "type": "array" + }, + "verificationKeyId": { + "description": "Identifier of the verification key to use. Constraints: minLength: 1. Example: \"sha256:4c095e183ea45a9d\".", + "example": "sha256:4c095e183ea45a9d", + "examples": [ + "sha256:4c095e183ea45a9d" + ], + "minLength": 1, + "type": "string" + } + }, + "required": [ + "circuit", + "pi_a", + "pi_b", + "pi_c", + "publicSignals", + "verificationKeyId" + ], + "type": "object" + }, + "proofType": { + "const": "groth16", + "default": "groth16", + "description": "Groth16 verification (default). Example: \"groth16\".", + "example": "groth16", + "examples": [ + "groth16" + ], + "type": "string" + }, + "sessionContextHash": { + "description": "Hash binding this proof to its agent session context. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "pattern": "^[0-9a-fA-F]{64}$", + "type": "string" + }, + "targetBlockHeight": { + "description": "Bitcoin block height being evaluated. Constraints: minimum: 0; maximum: 4294967295. Example: 920000.", + "example": 920000, + "examples": [ + 920000 + ], + "maximum": 4294967295, + "minimum": 0, + "type": "integer" + }, + "thermodynamicEntropyBits": { + "description": "Thermodynamic entropy value bound to the complete verifier response. Constraints: minimum: 0. Example: 0.5.", + "example": 0.5, + "examples": [ + 0.5 + ], + "minimum": 0, + "type": "number" + } + }, + "required": [ + "circuit", + "sessionContextHash", + "targetBlockHeight", + "entropyThreshold", + "proof" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "OTS mode requires proofType ots, a complete receipt, and its SHA-256 file digest.", + "examples": [ + { + "otsProof": "AQID", + "targetHash": "abababababababababababababababababababababababababababababababab" + } + ], + "properties": { + "otsProof": { + "description": "Canonical base64 or even-length hex serialized .ots receipt (maximum 512 KiB decoded). Constraints: minLength: 1; maxLength: 1048576. Example: \"AQID\".", + "example": "AQID", + "examples": [ + "AQID" + ], + "maxLength": 1048576, + "minLength": 1, + "type": "string" + }, + "proofType": { + "const": "ots", + "description": "OpenTimestamps Bitcoin verification. Example: \"ots\".", + "example": "ots", + "examples": [ + "ots" + ], + "type": "string" + }, + "targetHash": { + "description": "64-character SHA-256 digest recorded by the receipt; not a Bitcoin header hash. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "pattern": "^[0-9a-fA-F]{64}$", + "type": "string" + } + }, + "required": [ + "proofType", + "otsProof", + "targetHash" + ], + "type": "object" + } +] - changed
Output schema / descriptionPrevious value: -"Cryptographic proof verification result."New value: +"Groth16 verification timing or OTS Bitcoin attestation result, depending on proofType." - changed
Output schema / examplesPrevious value: -[ - { - "computationTimeMs": 3.284, - "valid": true, - "verifiedAt": "2026-09-19T01:41:36.458Z" - } -]New value: +[ + { + "computationTimeMs": 3.284, + "valid": true, + "verifiedAt": "2026-09-19T01:41:36.458Z" + }, + { + "bitcoinHeaderHash": "abababababababababababababababababababababababababababababababab", + "blockHeight": 920000, + "status": "bitcoin_block_attested", + "valid": true + } +] - added
Output schema / oneOfAdded value: +[ + { + "required": [ + "verifiedAt", + "computationTimeMs" + ] + }, + { + "required": [ + "status", + "blockHeight", + "bitcoinHeaderHash" + ] + } +] - added
Output schema / properties / bitcoinHeaderHashAdded value: +{ + "description": "Canonical Bitcoin block header hash at the attested height, or null if not verified. Example: \"abababababababababababababababababababababababababababababababab\".", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / blockHeightAdded value: +{ + "description": "Bitcoin attestation height, or null if not verified. Example: 920000.", + "example": 920000, + "examples": [ + 920000 + ], + "type": [ + "integer", + "null" + ] +} - added
Output schema / properties / statusAdded value: +{ + "description": "Whether the OTS record is Bitcoin-attested; calendar-only receipts are unverified. Constraints: allowed values: bitcoin_block_attested, unverified. Example: \"bitcoin_block_attested\".", + "enum": [ + "bitcoin_block_attested", + "unverified" + ], + "example": "bitcoin_block_attested", + "examples": [ + "bitcoin_block_attested" + ], + "type": "string" +} - changed
Output schema / properties / valid / descriptionPrevious value: -"Whether the proof is valid and bound to the snapshot. Example: true."New value: +"True only for a digest-matching, Bitcoin-attested OTS record with a valid chain-header lookup. Example: true." - changed
Output schema / requiredPrevious value: -[ - "valid", - "verifiedAt", - "computationTimeMs" -]New value: +[ + "valid" +]
- Removed
proof.verify_ots
2 tool updates
- Added
payment.settle - Added
proof.verify_ots
1 tool update
- Changed
payment.info2 fields changed- changed
Output schema / descriptionPrevious value: -"Configured MCP prices in sats (zero denotes a free tool) and fixed-fee Lightning L402 challenge rules. No live invoice is created by this tool."New value: +"Configured MCP prices in sats (zero denotes a free tool), Lightning L402 rules, and optional Base USDC x402 terms. No live invoice is created by this tool." - added
Output schema / properties / x402Added value: +{ + "additionalProperties": false, + "description": "Base mainnet USDC x402 exact terms; present only when authenticated CDP settlement is configured.", + "examples": [ + { + "amount": "1000", + "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", + "network": "eip155:8453", + "payTo": "0x7a4183ce5b9989833bb33133dcbb8efd6a84e775", + "scheme": "exact" + } + ], + "properties": { + "amount": { + "description": "Atomic USDC units per paid call. Example: \"1000\".", + "example": "1000", + "examples": [ + "1000" + ], + "type": "string" + }, + "asset": { + "description": "USDC token contract. Example: \"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\".", + "example": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", + "examples": [ + "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913" + ], + "type": "string" + }, + "network": { + "description": "x402 CAIP-2 network. Example: \"eip155:8453\".", + "example": "eip155:8453", + "examples": [ + "eip155:8453" + ], + "type": "string" + }, + "payTo": { + "description": "Payment recipient. Example: \"0x7a4183ce5b9989833bb33133dcbb8efd6a84e775\".", + "example": "0x7a4183ce5b9989833bb33133dcbb8efd6a84e775", + "examples": [ + "0x7a4183ce5b9989833bb33133dcbb8efd6a84e775" + ], + "type": "string" + }, + "scheme": { + "description": "x402 scheme. Example: \"exact\".", + "example": "exact", + "examples": [ + "exact" + ], + "type": "string" + } + }, + "required": [ + "network", + "scheme", + "asset", + "amount", + "payTo" + ], + "type": "object" +}
1 tool update
- Changed
payment.info1 field changed- changed
Input schema / properties / toolName / descriptionPrevious value: -"Optional nonempty canonical MCP tool name (e.g. 'stratigraphy.digest'); narrows perToolSats, while omission returns all tool prices. Unknown names fail validation. Constraints: minLength: 1. Example: \"stratigraphy.digest\"."New value: +"Optional case-sensitive canonical MCP tool identifier (e.g., 'stratigraphy.digest' or 'proof.verify'). When provided, filters output to return pricing specifically for that single tool. When omitted, returns the full pricing map across all registered catalog tools. Must match an exact registered tool name string. Constraints: minLength: 1. Example: \"stratigraphy.digest\"."
11 tool updates
- Changed
mesh.broadcast1 field changed- changed
Input schema / properties / payload / properties / date / descriptionPrevious value: -"UTC calendar date of the existing record to distribute, formatted YYYY-MM-DD. Constraints: format: date; pattern: ^\\d{4}-\\d{2}-\\d{2}$. Example: \"2026-09-09\"."New value: +"Required UTC date of an existing indexed record (YYYY-MM-DD, e.g. '2026-09-09'); selects the stored snapshot signed for peer validation, not a caller-supplied payload. Constraints: format: date; pattern: ^\\d{4}-\\d{2}-\\d{2}$. Example: \"2026-09-09\"."
- Changed
mesh.get_status1 field changed- changed
Input schema / descriptionPrevious value: -"No input parameters required."New value: +"Pass {} for current peer health and quorum; extra arguments are rejected and inbound subscription state is not tracked."
- Changed
payment.info2 fields changed- changed
Input schema / descriptionPrevious value: -"Optional canonical MCP tool name; omit to see pricing for every advertised tool. This information request does not issue an invoice."New value: +"Pass an optional canonical toolName to narrow the returned price map; omit it for all advertised prices. This free request does not issue an invoice." - changed
Input schema / properties / toolName / descriptionPrevious value: -"Specific MCP tool name to query pricing and caveats for (e.g., 'stratigraphy.digest'). Returns general tier pricing if omitted. Constraints: minLength: 1. Example: \"stratigraphy.digest\"."New value: +"Optional nonempty canonical MCP tool name (e.g. 'stratigraphy.digest'); narrows perToolSats, while omission returns all tool prices. Unknown names fail validation. Constraints: minLength: 1. Example: \"stratigraphy.digest\"."
- Changed
proof.attenuate3 fields changed- changed
Input schema / descriptionPrevious value: -"Derive a narrower child of an authentic, unexpired subscription macaroon; this delegation call does not issue a payment invoice."New value: +"Provide an authentic parent macaroon, an array of restrictions, and optional TTL; child caveats intersect with inherited constraints and no payment invoice is issued." - changed
Input schema / properties / macaroon / descriptionPrevious value: -"Base L402 Macaroon string to attenuate. Constraints: minLength: 1; maxLength: 8192. Example: \"base64url-parent-macaroon\"."New value: +"Required authentic, unexpired parent L402 macaroon (1-8192 characters); caveats and ttlSeconds can only narrow its scope. Constraints: minLength: 1; maxLength: 8192. Example: \"base64url-parent-macaroon\"." - changed
Input schema / properties / ttlSeconds / descriptionPrevious value: -"Optional time-to-live in seconds to automatically append an expiration caveat. Must be a positive integer of at most 30 days. Constraints: minimum: 1; maximum: 2592000. Example: 3600."New value: +"Optional positive integer TTL of 1-2592000 seconds (e.g. 3600); appends an expiration caveat without extending the parent's expiry. Constraints: minimum: 1; maximum: 2592000. Example: 3600."
- Changed
proof.get_by_hash3 fields changed- changed
Input schema / descriptionPrevious value: -"Look up a proof hash, signed receipt hash or CID, decimal snapshot digest, or proof submission job ID. Unknown identifiers return HTTP 404 before payment."New value: +"Supply exactly one of hash or jobId to retrieve an exact retained proof/receipt or lifecycle state. Unknown identifiers return HTTP 404 before payment." - changed
Input schema / properties / hash / descriptionPrevious value: -"Cryptographic hash, snapshot digest, IPFS CID, or submission job ID to query. Constraints: pattern: ^(?:(?:0x)?[0-9a-fA-F]{64}|Qm[1-9A-HJ-NP-Za-km-z]{44}|b[a-z2-7]{20,}|\\d{1,77}|[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$. Example: \"0xabababababababababababababababababababababababababababababababab\"."New value: +"Required when jobId is absent: proof/receipt 64-hex hash (optional 0x), decimal snapshot digest, IPFS CID, or UUID submission job ID; unknown identifiers return 404. Constraints: pattern: ^(?:(?:0x)?[0-9a-fA-F]{64}|Qm[1-9A-HJ-NP-Za-km-z]{44}|b[a-z2-7]{20,}|\\d{1,77}|[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$. Example: \"0xabababababababababababababababababababababababababababababababab\"." - changed
Input schema / properties / jobId / descriptionPrevious value: -"UUID returned by proof.submit; use instead of hash. Constraints: format: uuid. Example: \"123e4567-e89b-42d3-a456-426614174000\"."New value: +"UUID returned by proof.submit (e.g. '123e4567-e89b-42d3-a456-426614174000'); use instead of hash, never together. Constraints: format: uuid. Example: \"123e4567-e89b-42d3-a456-426614174000\"."
- Changed
proof.ground1 field changed- changed
Input schema / descriptionPrevious value: -"Provide contextHash and agentId to ground live agent context, or cid to anchor a dataset; the modes are exclusive."New value: +"Provide contextHash and agentId together for live agent context, or cid for a dataset anchor; these two modes are exclusive. Optional metadata applies to context mode; optional nostrEventId and context apply to dataset mode."
- Changed
proof.list1 field changed- changed
Input schema / descriptionPrevious value: -"Input options for listing and discovering historical zk-SNARK proof attestations."New value: +"Filter bounded proof attestations by lifecycle status, then paginate newest-first with limit and offset; omit all fields for the first default page."
- Changed
stratigraphy.diff3 fields changed- changed
Input schema / descriptionPrevious value: -"Select two indexed daily strata by height or ISO date; latest refers to the latest indexed entry, not the live chain tip."New value: +"Compare a required baseline indexed height or UTC date with an optional endpoint; either order is valid and produces signed deltas. latest refers to the latest indexed entry, not the live chain tip." - changed
Input schema / properties / fromTarget / descriptionPrevious value: -"Starting block height or ISO date string (e.g. '850000' or '2026-01-01'). Only indexed dataset heights are supported. Constraints: pattern: ^(?:(?:0|[1-9]\\d*)|\\d{4}-\\d{2}-\\d{2})$. Example: \"919856\"."New value: +"Required baseline indexed height (e.g. '850000') or UTC ISO date (e.g. '2026-01-01'); compared with toTarget to calculate signed deltas. Either chronological order is allowed; only indexed entries resolve. Constraints: pattern: ^(?:(?:0|[1-9]\\d*)|\\d{4}-\\d{2}-\\d{2})$. Example: \"919856\"." - changed
Input schema / properties / toTarget / descriptionPrevious value: -"Ending block height or ISO date string. 'latest' means the latest indexed entry, not the live Bitcoin tip. Constraints: pattern: ^(?:latest|(?:0|[1-9]\\d*)|\\d{4}-\\d{2}-\\d{2})$. Example: \"latest\"."New value: +"Optional comparison indexed height (e.g. '919856'), UTC ISO date (e.g. '2026-09-01'), or 'latest' (default); deltas are toTarget minus fromTarget. 'latest' is the latest dataset entry, not the live Bitcoin tip. Constraints: pattern: ^(?:latest|(?:0|[1-9]\\d*)|\\d{4}-\\d{2}-\\d{2})$. Example: \"latest\"."
- Changed
stratigraphy.get6 fields changed- changed
Input schema / descriptionPrevious value: -"Stratigraphy telemetry query parameters."New value: +"Choose recent days, one date/indexed height, or an inclusive date/height range; selector modes cannot be combined. Limit and metrics refine the selected records." - changed
Input schema / properties / blockHeight / descriptionPrevious value: -"Indexed Bitcoin block height selecting one telemetry record (non-negative integer). Constraints: minimum: 0. Example: 850000."New value: +"Select one indexed non-negative dataset height (e.g. 850000), not an arbitrary live chain lookup; cannot combine with days, date, or range bounds. Constraints: minimum: 0. Example: 850000." - changed
Input schema / properties / date / descriptionPrevious value: -"Calendar date selecting one telemetry day, formatted as YYYY-MM-DD in UTC. Constraints: minLength: 1; format: date; pattern: ^\\d{4}-\\d{2}-\\d{2}$. Example: \"2026-09-19\"."New value: +"Select one indexed UTC day (YYYY-MM-DD, e.g. '2026-09-19'); cannot combine with days, blockHeight, or range bounds. Constraints: minLength: 1; format: date; pattern: ^\\d{4}-\\d{2}-\\d{2}$. Example: \"2026-09-19\"." - changed
Input schema / properties / days / descriptionPrevious value: -"Count of recent days of telemetry to fetch (integer, 1-365). Constraints: minimum: 1; maximum: 365. Example: 7."New value: +"Fetch the most recent 1-365 indexed daily records (e.g. 7), capped by limit; cannot combine with date, blockHeight, or range bounds. Constraints: minimum: 1; maximum: 365. Example: 7." - changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of records to return (integer, 1-100). Constraints: minimum: 1; maximum: 100. Example: 10."New value: +"Cap records returned by the chosen selector at 1-100 (default 10); does not expand days or range bounds. Constraints: minimum: 1; maximum: 100. Example: 10." - changed
Input schema / properties / metrics / descriptionPrevious value: -"Array of specific telemetry metric key strings to project into returned records. Constraints: minItems: 1. Example: [\"target_multiplier\"]."New value: +"Unique telemetry metric keys to project into each selected record's quantitative_alpha; omit for all metrics, or choose one or more allowed names. Constraints: minItems: 1. Example: [\"target_multiplier\"]."
- Changed
stratigraphy.list1 field changed- changed
Input schema / descriptionPrevious value: -"No input parameters required."New value: +"Pass {} to discover catalog bounds before selecting records; any parameter is rejected."
- Changed
stratigraphy.range4 fields changed- changed
Input schema / properties / endTarget / descriptionPrevious value: -"Ending block height or ISO date string. Constraints: pattern: ^(?:latest|(?:0|[1-9]\\d*)|\\d{4}-\\d{2}-\\d{2})$. Example: \"latest\"."New value: +"Optional inclusive ending indexed height, UTC ISO date, or 'latest' (default: latest indexed entry, not live tip); must resolve no earlier than startTarget. Constraints: pattern: ^(?:latest|(?:0|[1-9]\\d*)|\\d{4}-\\d{2}-\\d{2})$. Example: \"latest\"." - changed
Input schema / properties / format / descriptionPrevious value: -"Payload compression format applied to each item in the batch. Constraints: allowed values: compact, minimal, kv. Example: \"compact\"."New value: +"Compression of every returned record: compact (default), minimal, or kv; does not change selected bounds. Constraints: allowed values: compact, minimal, kv. Example: \"compact\"." - changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of strata entries to return in the batch. Constraints: minimum: 1; maximum: 100. Example: 50."New value: +"Maximum compressed records returned from startTarget toward endTarget, 1-100 (default 50); smaller limits truncate the batch. Constraints: minimum: 1; maximum: 100. Example: 50." - changed
Input schema / properties / startTarget / descriptionPrevious value: -"Starting block height or ISO date string (e.g. '850000' or '2026-01-01'). Constraints: pattern: ^(?:(?:0|[1-9]\\d*)|\\d{4}-\\d{2}-\\d{2})$. Example: \"919712\"."New value: +"Required inclusive starting indexed height (e.g. '850000') or UTC ISO date (e.g. '2026-01-01'); must resolve no later than endTarget. Constraints: pattern: ^(?:(?:0|[1-9]\\d*)|\\d{4}-\\d{2}-\\d{2})$. Example: \"919712\"."
Publisher details
- Operator
- Bitcoin Stratigraphy by Charles R. Strogish · Publisher source
- Operator website
- https://bitcoin-stratigraphy-dashboard.replit.app/
- Vendor relationship
- Not applicable
- Documentation
- Not applicable
- Restrictions
- Not applicable
Related MCP Connectors
Agent registry with Nostr identity, reputation, escrow, observability, and Lightning payments.
AI brand/token visibility, prediction-market odds & cheap x402 data feeds for AI agents.
Pay-per-call crypto data for AI agents. Live metrics, peg monitor, claim verification via x402.
Live cached Solana decisions and delta feeds purchasable by AI agents through x402.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceBitcoin data for AI agents. Pay-per-query via x402 micropayments. No API keys. No subscriptions. No tokens.MIT
btcmatic-mcp-serverofficial
AlicenseAqualityCmaintenanceMCP server that gives autonomous agents pay-per-call Bitcoin context (self-custody radar, fee percentiles, price change windows, condition frequencies) paid in sats over Lightning via L402 invoices, with no account or API key required.7MIT- AlicenseNot gradedqualityBmaintenanceTrust-aware Nostr MCP server. 236 tools for identity, social, DMs, trust scoring, AI-to-AI dispatch, Lightning payments, privacy proofs, and encrypted vaults. NIP-46 bunker auth; keys never leave the signing device.701 npm1MIT
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.