Bitview

Validate address

validate_address

Read-onlyIdempotent

Validate a Bitcoin address and get information about its type and scriptPubKey. Returns isvalid: false with an error message for invalid addresses; a string that isn't 2 to 130 letters and digits answers 400.

Mempool.space docs

REST operation: GET /api/v1/validate-address/{address}.

Input Schema

Name	Required	Description	Default
`address`	Yes	Bitcoin address to validate: 2 to 130 letters and digits (a P2PK public key in hex is 130); anything else answers 400, as mempool.space does

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 30, 2026

changedInput schema / properties / address / description

Previous value: -"Bitcoin address to validate (can be any string)"New value: +"Bitcoin address to validate: 2 to 130 letters and digits (a P2PK public key in hex is 130);\nanything else answers 400, as mempool.space does"

changedInput schema / properties / address / examples

Previous value: -[
-  "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f",
-  "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa",
-  "not-a-valid-addr",
-  "bc1qinvalid"
-]New value: +[
+  "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f",
+  "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa",
+  "notavalidaddr",
+  "bc1qinvalid"
+]

removedOutput schema / $defs / AddrValidation

Removed value: -{
-  "properties": {
-    "address": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "error": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "error_locations": {
-      "items": {
-        "format": "uint",
-        "minimum": 0,
-        "type": "integer"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    },
-    "isscript": {
-      "type": [
-        "boolean",
-        "null"
-      ]
-    },
-    "isvalid": {
-      "type": "boolean"
-    },
-    "iswitness": {
-      "type": [
-        "boolean",
-        "null"
-      ]
-    },
-    "scriptPubKey": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "witness_program": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "witness_version": {
-      "format": "uint8",
-      "maximum": 255,
-      "minimum": 0,
-      "type": [
-        "integer",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "isvalid"
-  ],
-  "type": "object"
-}

addedOutput schema / $defs / Address
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / $defs / AddressValidation

Added value: +{
+  "properties": {
+    "address": {
+      "anyOf": [
+        {
+          "$ref": "#/$defs/Address"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "error": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "error_locations": {
+      "items": {
+        "minimum": 0,
+        "type": "integer"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "isscript": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "isvalid": {
+      "type": "boolean"
+    },
+    "iswitness": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "scriptPubKey": {
+      "anyOf": [
+        {
+          "$ref": "#/$defs/Hex"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "witness_program": {
+      "anyOf": [
+        {
+          "$ref": "#/$defs/Hex"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "witness_version": {
+      "maximum": 255,
+      "minimum": 0,
+      "type": [
+        "integer",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "isvalid"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / Hex

Added value: +{
+  "pattern": "^([0-9a-f]{2})*$",
+  "type": "string"
+}

changedOutput schema / $ref

Previous value: -"#/$defs/AddrValidation"New value: +"#/$defs/AddressValidation"

First observedOct 23, 2026

TDQS

A3.8/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 the description adds genuinely new behavior beyond them: invalid addresses return isvalid:false with an error message, and malformed input (not 2-130 alphanumerics) yields HTTP 400. That is exactly the failure-mode detail an agent needs before calling.

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 action and the two behavioral outcomes, with the docs link and REST path trailing as reference. Slight redundancy: the 2-130 alphanumeric rule restates the schema description verbatim, costing a clause.

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 one-parameter read-only check with full annotation coverage and an output schema, everything needed is present: what it does, what an invalid result looks like, and how bad input is handled. Return-value shape is correctly left to the output schema.

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 single parameter already documents the 2-130 length rule with four examples, so the description adds no syntax or format detail beyond it. Baseline 3 applies when the schema does the work.

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

Purpose4/5

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

States a specific verb and resource ("Validate a Bitcoin address") and adds concrete scope: returns type and scriptPubKey. That distinguishes it in kind from the get_address* siblings, which fetch data for an address rather than checking validity, though no sibling is 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the cheap pre-check to run before get_address or get_address_utxos, but the description never says so or sets conditions. No exclusions or explicit alternative are given.

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

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