Skip to main content
Glama

California Bitcoin

by org.californiabitcoin
OverviewDiscussionsAdmin

Batch Bitcoin Research

batch_bitcoin_research
Read-onlyIdempotent

PAID 0.50 USD via MPP. Process up to 20 distinct Bitcoin claims, questions, or evidence requests in one deterministic research package while preserving per-item verdict and evidence-quality semantics. Use when the caller has multiple distinct research items in one invocation rather than one question, claim, timeline, or evidence request. Use for multiple distinct research items. Do not wrap a single item merely to use the batch product.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYesOne to twenty Bitcoin research items to process in the batch.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / description
      Added value: +"Input for Batch Bitcoin Research. Use the documented fields exactly; unknown fields are rejected."
    • addedInput schema / examples
      Added value: +[
+  {
+    "items": [
+      "RBF can reverse confirmed transactions.",
+      "BIP324 encrypts Bitcoin peer traffic."
+    ]
+  }
+]
    • addedInput schema / properties / items / examples
      Added value: +[
+  [
+    "RBF can reverse confirmed transactions.",
+    "BIP324 encrypts Bitcoin peer traffic."
+  ]
+]
  2. Changed1 schema field changed
    • 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."
  3. Changed3 schema fields changed
    • addedInput schema / properties / items / description
      Added value: +"One to twenty Bitcoin research items to process in the batch."
    • changedInput schema / properties / items / items / oneOf
      Previous value: -[
-  {
-    "maxLength": 2000,
-    "minLength": 1,
-    "type": "string"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "text": {
-        "maxLength": 2000,
-        "minLength": 1,
-        "type": "string"
-      },
-      "type": {
-        "default": "question",
-        "enum": [
-          "question",
-          "claim",
-          "evidence"
-        ],
-        "type": "string"
-      }
-    },
-    "required": [
-      "text"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "description": "Bitcoin question, claim, or evidence request as plain text.",
+    "maxLength": 2000,
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "text": {
+        "description": "Bitcoin question, claim, or evidence request text.",
+        "maxLength": 2000,
+        "minLength": 1,
+        "type": "string"
+      },
+      "type": {
+        "default": "question",
+        "description": "Research item type: question, factual claim, or evidence request.",
+        "enum": [
+          "question",
+          "claim",
+          "evidence"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "text"
+    ],
+    "type": "object"
+  }
+]
    • 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"
+}
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: 'deterministic research package' and 'preserving per-item verdict and evidence-quality semantics' clarify the behavior for a batch operation, and the cost disclosure ('PAID 0.50 USD via MPP') is a unique transparency addition. No contradictions with annotations.

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?

The description is three sentences, each earning its place: cost, purpose, usage guidance, and a negative constraint. It is front-loaded with the most critical detail (paid, batch limit) and avoids redundancy. Extremely tight and efficient.

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?

The description covers purpose, usage, and key behavioral traits, and an output schema exists to handle return-value details. It omits specifics about partial failures or invalid item handling, but given the annotations and output schema, an agent has enough context to call the tool correctly. Slightly incomplete around edge-case behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes the 'items' parameter with 100% coverage, including types, constraints, and examples. The description does not add new parameter-level semantics beyond what the schema provides; it only restates that items can be claims/questions/evidence requests. Given schema coverage, a baseline of 3 is appropriate.

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

Purpose5/5

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

The description states a specific verb ('Process'), resource ('up to 20 distinct Bitcoin claims, questions, or evidence requests'), and outcome ('preserving per-item verdict and evidence-quality semantics'). It clearly distinguishes this batch tool from single-item siblings by emphasizing 'multiple distinct research items in one invocation' and explicitly warns against wrapping a single item, which separates it from answer_bitcoin_question or verify_bitcoin_claim.

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?

Explicit guidance is given: 'Use when the caller has multiple distinct research items in one invocation rather than one question, claim, timeline, or evidence request.' It also provides a negative constraint: 'Do not wrap a single item merely to use the batch product.' This directly tells an agent when to select this tool over alternatives without ambiguity.

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

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources