Tokenbooks - crypto and fiat accounting and payments

List Portfolio Transactions

list_portfolio_transactions

Read-onlyIdempotent

Find accounting transactions—called Portfolio Transactions in Tokenbooks—for review or reconciliation; filter by status, type, errors, spam, wallet, or asset, include compact source transactions when needed, then open one for detailed evidence. Including source transactions limits each page to 10 records.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`sort`	No	Timestamp sort. Prefix with - for descending order.	-timestamp
`limit`	No	Maximum Portfolio Transactions to return, maximum 100.
`isSpam`	No	Filter to transactions whose transfers involve spam (true) or non-spam (false) tokens
`search`	No	Free-text search over memo, tx hash and transaction ID
`status`	No	Filter by transaction status array, e.g. ["POSTED"]
`toDate`	No	Optional ISO timestamp upper bound
`txHash`	No	Filter by exact on-chain transaction hash
`address`	No	Match transfers by from/to address (case-insensitive)
`chainId`	No	Public wallet chain ID.
`hasLots`	No	When true, only transactions that produced cost-basis lots; when false, only those without lots
`include`	No	Include grouped contributing raw source transactions without provider details
`subType`	No	Filter by operation sub-type (any of, case-insensitive)
`chainIds`	No	Optional chain ID filters
`fromDate`	No	Optional ISO timestamp lower bound
`hasError`	No	When true, only transactions with a processing error; when false, only error-free transactions
`maxValue`	No	Maximum transfer fiat quote value (inclusive), as a decimal string
`minValue`	No	Minimum transfer fiat quote value (inclusive), as a decimal string
`assetRefs`	No	Filter by asset symbol (any of, case-insensitive)
`errorType`	No	Filter by error/warning code array, e.g. ["FmvNotAvailable"]
`pageToken`	No	Opaque token returned by the previous list response.
`counterparty`	No	Filter by counterparty name (any of, case-insensitive)
`portfolioRef`	Yes
`workspaceRef`	Yes
`operationType`	No	Filter by accounting operation type array, e.g. ["UNCATEGORIZED"]
`walletAddress`	No	Public wallet address on the selected chain.
`defiPositionKey`	No	Filter by protocol-defined DeFi position key
`hasJournalEntry`	No	When true, only transactions with a non-empty journal entry; when false, only those without one
`defiPositionWalletAddress`	No	Filter by DeFi position wallet address
`defiPositionWalletChainId`	No	Filter by DeFi position wallet chain ID
`responsibilityCenterTypeKeys`	No	Filter to transactions whose journal lines carry a responsibility-center assignment under any of these type keys (e.g. primary, goal; from list_responsibility_centers)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`pagination`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 14, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a non-obvious behavioral fact beyond those annotations: including source transactions limits each page to 10 records. This is exactly the kind of contextual disclosure that helps an agent anticipate response shape.

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 sentences with no filler: purpose, filter categories, and the page-limit caveat are front-loaded and each sentence earns its place. The structure makes the key behavioral exception immediately visible.

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?

Given 30 parameters, a rich output schema, and annotations that clearly mark the operation as read-only/idempotent, the description is sufficiently complete for correct tool selection and basic invocation. It could explicitly mention pagination or pageToken, but those are already documented in the schema, so nothing critical is missing.

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 description coverage is high at 93%, so the schema carries most parameter meaning. The description still adds value by grouping filters conceptually (status, type, errors, spam, wallet, asset) and by clarifying that 'include source transactions' yields compact raw source data and imposes the 10-record page cap. This is meaningful enrichment over the schema.

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 names a specific verb and resource ('Find accounting transactions') and clarifies the domain term 'Portfolio Transactions in Tokenbooks,' which distinguishes it from raw-transaction listing siblings. It also signals the detailed-evidence sibling by saying 'then open one for detailed evidence,' so an agent can disambiguate without opening schemas.

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?

It states the intended use cases ('for review or reconciliation') and gives conditional guidance ('include compact source transactions when needed'). It does not explicitly name alternatives or exclusions, but the review/reconciliation framing and 'open one' instruction provide clear context for when this tool is appropriate.

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?