Moltline TaxLots

Parse Transactions

parse_transactions

Read-onlyIdempotent

Normalise an exchange CSV export into the canonical ledger rows. FREE.

Supports the Coinbase transaction-history export (Transaction Type / Asset / Quantity Transacted columns), the Kraken ledgers export (txid / refid / type / asset / amount / fee) and a generic CSV with the canonical columns ts, type, asset, qty, fiat_value, fee_qty, fee_asset, fee_fiat, counter_asset, counter_qty, account, id. Typical input {"csv_text": "...", "source_hint": "coinbase"} returns {"rows": [...], "detected": "coinbase", "unrecognised": [...], "warnings": [...]}. Rows it cannot read are returned under unrecognised with the reason, never dropped silently. In every row qty is the whole amount that entered or left the account; when a fee was paid in the same asset, fee_qty is the part of qty that was the fee. Use before ledger_lint and build_lots. Not for other exchanges: convert those to the generic columns first. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "csv_text must be the CSV file contents"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Input Schema

TableJSON Schema

Name	Required	Description
`account`	No	account label to stamp on every row (defaults to the source name).
`csv_text`	Yes	the CSV file contents (up to 2 MB).
`source_hint`	No	coinbase, kraken or generic; empty to detect from the header.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Even though annotations already declare read-only and idempotent behavior, the description adds substantial behavioral detail: unrecognized rows are never silently dropped, invalid input returns an error object rather than a protocol error, and the meaning of qty versus fee_qty is explained. No contradiction with annotations 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?

The description is well structured and front-loaded with the core purpose. It is longer than average but nearly every sentence adds operational value. Minor redundancy like 'FREE' and restating idempotence costs it a perfect score.

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 parsing tool with this complexity, the description is complete: it covers supported formats, canonical columns, output shape, error behavior, unrecognized row handling, fee semantics, and recommended ordering relative to sibling tools. The agent has everything needed to invoke it correctly.

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 100%, so the baseline is 3. The description adds extra value by explaining what the source_hint values imply (Coinbase and Kraken column layouts) and showing a typical input/output shape. This goes beyond the schema without being strictly necessary.

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 opens with a specific verb and resource: 'Normalise an exchange CSV export into the canonical ledger rows.' It clearly defines what the tool does, names the supported export formats, and distinguishes its scope from other exchanges.

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?

Explicit usage guidance is provided: 'Use before ledger_lint and build_lots' and 'Not for other exchanges: convert those to the generic columns first.' This tells the agent when to use the tool and when not to, which is exactly what this dimension requires.

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

All Moltline TaxLots tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each of the eight tools targets a distinct stage or analysis: import normalization, ledger validation, transfer pairing, lot building, Form 8949 formatting, broker-form reconciliation, wash-sale checking, and LP math. No two tools could be reasonably confused for one another.

Naming Consistency3/5

Names are all lowercase snake_case and readable, but they mix verb_object forms like parse_transactions, match_transfers, and build_lots with noun-first compound forms like ledger_lint, lp_position_math, and wash_window_check. The convention is not uniform enough to be 'mostly consistent,' though it is still predictable from the domain.

Tool Count5/5

Eight tools is a well-scoped size for a crypto tax-lot workflow; each tool covers a necessary step without redundant helpers. The count feels neither thin nor bloated.

Completeness5/5

The toolset covers the full pipeline from transaction import through linting, transfer matching, lot building, tax form row generation, 1099-DA reconciliation, and wash-sale review. The standalone LP math tool addresses a relevant adjacent need, and there are no obvious dead ends.

Resources

Need Help?