California Bitcoin

Check Bitcoin Evidence Checkpoint

check_bitcoin_evidence_checkpoint

Read-onlyIdempotent

FREE. FREE, no account and no payment. Compare a previously returned retained-evidence checkpoint with the current maintained dossier content identity before deciding whether to rerun or repurchase covered historical research. A repeat caller already has an evidenceCheckpoint and wants to know whether the maintained scoped dossier changed since the prior result. Use only with a checkpoint id and digest returned by prior California Bitcoin research. It does not rerun research or authorize payment.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`checkpointId`	Yes	Checkpoint identifier returned by a prior California Bitcoin research result.
`expectedDigest`	Yes	Expected SHA-256 content digest returned with the checkpoint, including the sha256: prefix.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 15, 2026

addedInput schema / description

Added value: +"Input for Check Bitcoin Evidence Checkpoint. Use the documented fields exactly; unknown fields are rejected."

addedInput schema / examples

Added value: +[
+  {
+    "checkpointId": "primary-source-dossier:satoshi-anonymity",
+    "expectedDigest": "sha256:0000000000000000000000000000000000000000000000000000000000000000"
+  }
+]

addedInput schema / properties / checkpointId / examples

Added value: +[
+  "primary-source-dossier:satoshi-anonymity"
+]

addedInput schema / properties / expectedDigest / examples

Added value: +[
+  "sha256:0000000000000000000000000000000000000000000000000000000000000000"
+]

Changed1 schema field changedSep 14, 2026

changedOutput schema / description

Previous value: -"Structured California Bitcoin result with operation-specific research, evidence, provenance, coverage, trust, and next-step fields."New value: +"Structured California Bitcoin result with operation-specific research, evidence, provenance, coverage, freshness, trust, and next-step fields."

Changed3 schema fields changedSep 13, 2026

addedInput schema / properties / checkpointId / description

Added value: +"Checkpoint identifier returned by a prior California Bitcoin research result."

addedInput schema / properties / expectedDigest / description

Added value: +"Expected SHA-256 content digest returned with the checkpoint, including the sha256: prefix."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Structured California Bitcoin result with operation-specific research, evidence, provenance, coverage, trust, and next-step fields.",
+  "type": "object"
+}

AddedSep 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable non-schema context: the tool is free, requires no account or payment, and does not rerun research or authorize payment. These behavioral traits go beyond the structured annotations and are valuable to an agent deciding whether to invoke the tool.

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

Conciseness4/5

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

The description is mostly efficient and front-loads key operational facts, but it opens with a redundant 'FREE. FREE, no account and no payment' phrasing. The core purpose follows quickly, and the imperative 'Use only with...' is direct. Minor redundancy prevents a perfect score.

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 two-parameter, read-only, idempotent check tool with an output schema, the description adequately covers purpose, prerequisites, exclusions, and the source of valid parameter values. There is no significant missing context that would prevent an agent from calling the tool correctly.

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 both checkpointId and expectedDigest have their own descriptions and format constraints. The tool description reinforces that both values must come from prior research results, but it adds little beyond what the schema already documents.

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

Purpose5/5

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

The description states a precise operation: compare a previously returned evidence checkpoint against the current dossier digest before deciding whether to rerun or repurchase research. It clearly distinguishes itself from the sibling research and verification tools by stating what it does not do (does not rerun research or authorize payment).

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 states when it should be used: a repeat caller with a checkpoint and digest from prior California Bitcoin research wants to know whether the dossier changed. It also gives exclusions, saying it does not rerun research or authorize payment, and says to use it only with checkpoint id/digest from prior results.

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

All California Bitcoin tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?