Skip to main content
Glama

Bitview

by io.github.bitcoinresearchkit
OverviewDiscussionsAdmin

Address hash-prefix matches

get_address_hash_prefix_matches
Read-onlyIdempotent

Find addresses by address type and by the first 1-16 hex nibbles of RapidHash v3 over the raw address payload bytes. Intended for privacy-preserving client-side wallet discovery without sending raw addresses or xpubs. Fetch metadata with GET /api/address/{address}.

REST operation: GET /api/address/hash-prefix/{address_type}/{prefix}.

Input Schema

NameRequiredDescriptionDefault
prefixYesFirst 1–16 hexadecimal nibbles of the RapidHash v3 hash over the raw address payload bytes.
address_typeYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changed
    • addedInput schema / $defs / AddressOutputType
      Added value: +{
+  "description": "The output type of an address: any output type but `p2ms`, `op_return`, `empty_script` and `unknown_script`.",
+  "enum": [
+    "p2pk65",
+    "p2pk33",
+    "p2pkh",
+    "p2sh",
+    "p2wpkh",
+    "p2wsh",
+    "p2tr",
+    "p2a"
+  ],
+  "type": "string"
+}
    • removedInput schema / $defs / OutputType
      Removed value: -{
-  "description": "Type (P2PKH, P2WPKH, P2SH, P2TR, etc.)",
-  "enum": [
-    "p2pk65",
-    "p2pk33",
-    "p2pkh",
-    "p2ms",
-    "p2sh",
-    "opreturn",
-    "p2wpkh",
-    "p2wsh",
-    "p2tr",
-    "p2a",
-    "empty",
-    "unknown"
-  ],
-  "type": "string"
-}
    • removedInput schema / properties / addr_type
      Removed value: -{
-  "$ref": "#/$defs/OutputType"
-}
    • addedInput schema / properties / address_type
      Added value: +{
+  "$ref": "#/$defs/AddressOutputType"
+}
    • addedInput schema / properties / prefix / pattern
      Added value: +"^[0-9a-f]{1,16}$"
    • changedInput schema / required
      Previous value: -[
-  "addr_type",
-  "prefix"
-]New value: +[
+  "address_type",
+  "prefix"
+]
    • removedOutput schema / $defs / Addr
      Removed value: -{
-  "type": "string"
-}
    • removedOutput schema / $defs / AddrHashPrefixMatches
      Removed value: -{
-  "properties": {
-    "addr_type": {
-      "$ref": "#/$defs/OutputType"
-    },
-    "addresses": {
-      "items": {
-        "$ref": "#/$defs/Addr"
-      },
-      "type": "array"
-    },
-    "prefix": {
-      "type": "string"
-    },
-    "truncated": {
-      "type": "boolean"
-    }
-  },
-  "required": [
-    "addr_type",
-    "prefix",
-    "truncated",
-    "addresses"
-  ],
-  "type": "object"
-}
    • addedOutput schema / $defs / Address
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / $defs / AddressHashPrefixMatches
      Added value: +{
+  "properties": {
+    "address_type": {
+      "$ref": "#/$defs/AddressOutputType"
+    },
+    "addresses": {
+      "items": {
+        "$ref": "#/$defs/Address"
+      },
+      "type": "array"
+    },
+    "prefix": {
+      "pattern": "^[0-9a-f]{1,16}$",
+      "type": "string"
+    },
+    "truncated": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "address_type",
+    "prefix",
+    "truncated",
+    "addresses"
+  ],
+  "type": "object"
+}
    • addedOutput schema / $defs / AddressOutputType
      Added value: +{
+  "enum": [
+    "p2pk65",
+    "p2pk33",
+    "p2pkh",
+    "p2sh",
+    "p2wpkh",
+    "p2wsh",
+    "p2tr",
+    "p2a"
+  ],
+  "type": "string"
+}
    • removedOutput schema / $defs / OutputType
      Removed value: -{
-  "enum": [
-    "p2pk65",
-    "p2pk33",
-    "p2pkh",
-    "p2ms",
-    "p2sh",
-    "opreturn",
-    "p2wpkh",
-    "p2wsh",
-    "p2tr",
-    "p2a",
-    "empty",
-    "unknown"
-  ],
-  "type": "string"
-}
    • changedOutput schema / $ref
      Previous value: -"#/$defs/AddrHashPrefixMatches"New value: +"#/$defs/AddressHashPrefixMatches"
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered; the description adds the non-obvious privacy rationale and the exact matching/hashing semantics. It omits practical behavior such as whether short prefixes return bounded result sets or how many matches a 1-nibble prefix can yield.

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 short sentences, front-loaded with the matching rule, then the privacy intent, then the follow-up endpoint and REST path. Nothing is padding.

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?

Output shape is covered by the output schema and safety by annotations, so the description only needed to explain matching semantics, intent, and the next call, which it does. The missing piece is expected result cardinality for very short prefixes.

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 50%, and the description restates the prefix definition already in the schema rather than adding syntax or constraints. The address_type semantics live in the AddressOutputType enum and its description, so the description adds little beyond 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 (find) plus the exact resource and matching rule: address type plus the first 1-16 hex nibbles of RapidHash v3 over the raw payload. This is unmistakably different from sibling get_address, which the description also names for follow-up metadata.

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 usage context (privacy-preserving client-side wallet discovery, avoiding transmission of raw addresses or xpubs) and routes the agent to `GET /api/address/{address}` for metadata. It stops short of an explicit when-not-to-use or a direct comparison against get_address for plain lookup, so it is 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.

All Bitview 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