Bitview

Address confirmed transactions

get_address_confirmed_txs

Read-onlyIdempotent

Get the newest confirmed transactions for an address, up to max_txs (25 by default and at most). For pagination, request GET /api/address/{address}/txs/chain/{after_txid} with the last returned txid.

Mempool.space docs

REST operation: GET /api/address/{address}/txs/chain.

Input Schema

Name	Required	Description	Default
`address`	Yes
`max_txs`	No	Transactions to return, at most 25 (the default); larger values return 25.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed33 schema fields changedOct 30, 2026

removedInput schema / $defs / Addr

Removed value: -{
-  "description": "Bitcoin address string",
-  "examples": [
-    "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f",
-    "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa",
-    "bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq"
-  ],
-  "type": "string"
-}

addedInput schema / $defs / Address

Added value: +{
+  "description": "Bitcoin address, or the hex public key of a P2PK output.",
+  "examples": [
+    "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f",
+    "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa",
+    "bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq"
+  ],
+  "type": "string"
+}

changedInput schema / properties / address / $ref

Previous value: -"#/$defs/Addr"New value: +"#/$defs/Address"

addedInput schema / properties / max_txs

Added value: +{
+  "description": "Transactions to return, at most 25 (the default); larger values return 25.",
+  "minimum": 0,
+  "type": "integer"
+}

removedOutput schema / $defs / Addr

Removed value: -{
-  "type": "string"
-}

addedOutput schema / $defs / Address
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / $defs / BlockHash / pattern
```
Added value: +"^[0-9a-f]{64}$"
```
removedOutput schema / $defs / Height / format
```
Removed value: -"uint32"
```

addedOutput schema / $defs / Hex

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

removedOutput schema / $defs / RawLockTime / format
```
Removed value: -"uint32"
```
removedOutput schema / $defs / Sats / format
```
Removed value: -"uint64"
```
removedOutput schema / $defs / SigOps / format
```
Removed value: -"uint32"
```
removedOutput schema / $defs / Timestamp / format
```
Removed value: -"uint32"
```
removedOutput schema / $defs / Transaction / properties / size / format
```
Removed value: -"uint"
```
addedOutput schema / $defs / Transaction / properties / status / $ref
```
Added value: +"#/$defs/TxStatus"
```
removedOutput schema / $defs / Transaction / properties / status / allOf
```
Removed value: -[
-  {
-    "$ref": "#/$defs/TxStatus"
-  }
-]
```
addedOutput schema / $defs / TxIn / properties / scriptsig / allOf
```
Added value: +[
+  {
+    "$ref": "#/$defs/Hex"
+  }
+]
```
removedOutput schema / $defs / TxIn / properties / scriptsig / type
```
Removed value: -"string"
```
removedOutput schema / $defs / TxIn / properties / sequence / format
```
Removed value: -"uint32"
```
removedOutput schema / $defs / TxIn / properties / witness / allOf
```
Removed value: -[
-  {
-    "$ref": "#/$defs/Witness"
-  }
-]
```
addedOutput schema / $defs / TxIn / properties / witness / items
```
Added value: +{
+  "$ref": "#/$defs/Hex"
+}
```
addedOutput schema / $defs / TxIn / properties / witness / type
```
Added value: +"array"
```
removedOutput schema / $defs / TxIndex / format
```
Removed value: -"uint32"
```
addedOutput schema / $defs / TxOut / properties / scriptpubkey / allOf
```
Added value: +[
+  {
+    "$ref": "#/$defs/Hex"
+  }
+]
```
removedOutput schema / $defs / TxOut / properties / scriptpubkey / type
```
Removed value: -"string"
```

changedOutput schema / $defs / TxOut / properties / scriptpubkey_address / allOf

Previous value: -[
-  {
-    "$ref": "#/$defs/Addr"
-  }
-]New value: +[
+  {
+    "$ref": "#/$defs/Address"
+  }
+]

removedOutput schema / $defs / TxVersionRaw / format
```
Removed value: -"int32"
```
addedOutput schema / $defs / TxVersionRaw / minimum
```
Added value: +0
```
addedOutput schema / $defs / Txid / pattern
```
Added value: +"^[0-9a-f]{64}$"
```
removedOutput schema / $defs / Vout / format
```
Removed value: -"uint16"
```
removedOutput schema / $defs / Vout / maximum
```
Removed value: -65535
```
removedOutput schema / $defs / Weight / format
```
Removed value: -"uint32"
```

removedOutput schema / $defs / Witness

Removed value: -{
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

First observedOct 23, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's added value is the 25-item cap, the default, and the silent truncation behavior for larger values ('larger values return 25'). That truncation detail is genuinely useful and non-obvious. It omits ordering/return shape, but 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.

Conciseness4/5

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

Front-loaded with the core purpose and cap; the pagination hint follows efficiently. The trailing 'REST operation: GET /api/address/{address}/txs/chain' line largely duplicates the docs link and the endpoint named in the pagination sentence, making it the one low-value element.

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 and a small two-parameter surface, the description covers purpose, cap/default, truncation, and pagination path — everything needed to invoke it correctly. The only remaining gap (how it differs from get_address_confirmed_txs_after) is a routing concern rather than a completeness one.

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 50%, and the description reinforces the one ambiguous parameter by restating the 25 default/maximum and the truncation rule, which matches the schema's note. The `address` param is fully described in the schema (with examples and P2PK hex-key support), so no further compensation is needed.

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 with a scoping qualifier: 'newest confirmed transactions for an address', with the cap and default spelled out. It does not, however, distinguish itself from siblings like get_address_txs (which may include unconfirmed) or get_address_confirmed_txs_after, so an agent must infer which of the three address-tx tools to pick.

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 context is implied by 'newest confirmed' and the pagination note gives a concrete next step. But that next step is a raw REST URL rather than the sibling tool get_address_confirmed_txs_after, which appears to exist precisely for that case — the description never mentions it or when to prefer it.

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.