Tokenbooks - crypto and fiat accounting and payments

Split Portfolio Transaction

split_transactions

Destructive

Destructively move selected whole existing operation handles unchanged out of one accounting transaction into a new classified transaction; use this only when the needed economic legs already exist as operation handles. It cannot divide one transfer amount into new economic legs: repair sync normalization or use a supported persisted replacement lifecycle for a missing leg. Preview the grouping first, then track the queued requestId.

Input Schema

Name	Required	Description
`reason`	No	Optional immutable root reason. Nonempty bytes are preserved exactly; use ptx:<uuid> for transaction references.
`subType`	No	Optional operation sub-type
`operations`	Yes	Whole existing operation handles to move unchanged into a new transaction; do not use this to divide one normalized transfer amount into new economic legs
`portfolioRef`	Yes	Portfolio exact name or slug
`workspaceRef`	Yes	Workspace exact name or slug
`operationType`	Yes	Accounting operation type for the new transaction
`transactionId`	Yes	Source transaction to split operations out of

Output Schema

Name	Required	Description	Default
`error`	No
`status`	Yes
`success`	No
`requestId`	No
`transactionId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / operationType / enum

Previous value: -[
-  "DEPOSIT_FIAT",
-  "INCOME",
-  "REFUND",
-  "WITHDRAWAL_FIAT",
-  "EXPENSE",
-  "BUY",
-  "SELL",
-  "EXCHANGE",
-  "SWAP",
-  "MOVE",
-  "INTERCOMPANY_SEND",
-  "INTERCOMPANY_RECEIVE",
-  "STAKE",
-  "UNSTAKE",
-  "PROTOCOL_DEPOSIT",
-  "PROTOCOL_WITHDRAW",
-  "VAULT_DEPOSIT",
-  "VAULT_WITHDRAW",
-  "LP_IN",
-  "LP_OUT",
-  "LOAN_BORROW",
-  "LOAN_REPAY",
-  "LOAN_LIQUIDATION",
-  "LEND_GIVE",
-  "LEND_WITHDRAW",
-  "ADJUSTMENT",
-  "UNCATEGORIZED",
-  "SPAM"
-]New value: +[
+  "DEPOSIT_FIAT",
+  "INCOME",
+  "REFUND",
+  "REBATE",
+  "WITHDRAWAL_FIAT",
+  "EXPENSE",
+  "BUY",
+  "SELL",
+  "EXCHANGE",
+  "SWAP",
+  "MOVE",
+  "INTERCOMPANY_SEND",
+  "INTERCOMPANY_RECEIVE",
+  "STAKE",
+  "UNSTAKE",
+  "PROTOCOL_DEPOSIT",
+  "PROTOCOL_WITHDRAW",
+  "VAULT_DEPOSIT",
+  "VAULT_WITHDRAW",
+  "LP_IN",
+  "LP_OUT",
+  "LOAN_BORROW",
+  "LOAN_REPAY",
+  "LOAN_LIQUIDATION",
+  "LEND_GIVE",
+  "LEND_WITHDRAW",
+  "ADJUSTMENT",
+  "UNCATEGORIZED",
+  "SPAM"
+]

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "oneOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "requestId": {
+          "type": "string"
+        },
+        "status": {
+          "const": "queued",
+          "type": "string"
+        },
+        "transactionId": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "status",
+        "requestId",
+        "transactionId"
+      ],
+      "type": "object"
+    },
+    {
+      "additionalProperties": false,
+      "properties": {
+        "error": {
+          "additionalProperties": false,
+          "properties": {
+            "message": {
+              "type": "string"
+            },
+            "name": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "name",
+            "message"
+          ],
+          "type": "object"
+        },
+        "status": {
+          "const": "completed",
+          "type": "string"
+        },
+        "success": {
+          "type": "boolean"
+        },
+        "transactionId": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "status",
+        "success",
+        "transactionId"
+      ],
+      "type": "object"
+    }
+  ],
+  "properties": {
+    "error": {
+      "additionalProperties": false,
+      "properties": {
+        "message": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "name",
+        "message"
+      ],
+      "type": "object"
+    },
+    "requestId": {
+      "type": "string"
+    },
+    "status": {
+      "enum": [
+        "queued",
+        "completed"
+      ],
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    },
+    "transactionId": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "transactionId"
+  ],
+  "type": "object"
+}

Changed1 schema field changedSep 15, 2026

changedInput schema / properties / operations / description

Previous value: -"Operations to split into a new transaction"New value: +"Whole existing operation handles to move unchanged into a new transaction; do not use this to divide one normalized transfer amount into new economic legs"

First observedSep 14, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare destructive=true, idempotent=false, openWorld=true, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the operation is asynchronous and queued ('track the queued requestId'), handles are moved 'unchanged', and a preview should precede execution. It stops short of describing the failure/reversal semantics of the queued request.

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?

Three sentences, front-loaded with the core action before the constraints and the preview/tracking guidance. Dense and slightly clause-heavy, but every sentence carries routing or behavioral information.

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?

An output schema exists, so return values need not be explained, and the description still volunteers the queued requestId workflow. For a destructive, async mutation tool with full annotation coverage and 100% schema coverage, this is nearly complete; only the tracking mechanism's details are left to the sibling get_request_status.

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%, so the schema already documents all seven parameters including the nested operation handle fields. The description reinforces the semantics of 'operations' (whole existing handles, not new legs) but adds little syntax or format detail the schema does not already carry, so baseline 3 applies.

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 and resource: 'Destructively move selected whole existing operation handles unchanged out of one accounting transaction into a new classified transaction.' This lets an agent distinguish it from sibling merge_transactions and preview_transaction_classification without opening either schema.

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 bounds when to use it ('only when the needed economic legs already exist as operation handles'), states what it cannot do ('cannot divide one transfer amount into new economic legs'), and routes the agent to alternatives ('repair sync normalization or use a supported persisted replacement lifecycle'). It also names the prerequisite preview step.

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

All Tokenbooks - crypto and fiat accounting and payments 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?