Crypto cost-basis lots (FIFO/LIFO/HIFO/specific-ID), Form 8949 rows, 1099-DA diff. 5 of 8 free.
Scored across 8 tools
Each tool maps to a clearly distinct stage or calculation in the crypto tax-lot workflow: parsing, linting, transfer matching, lot building, Form 8949 layout, 1099-DA reconciliation, wash-sale checking, and LP math. Although several tools consume similar ledger or disposal data, their descriptions make the boundaries unambiguous.
All names use readable snake_case, but the naming convention is mixed: some are verb-first (build_lots, match_transfers, parse_transactions, reconcile_1099da) while others are noun-first or noun-phrase style (ledger_lint, form_8949_rows, lp_position_math, wash_window_check). The set remains understandable, but it lacks a single predictable pattern.
Eight tools is well-scoped for a crypto tax-lot engine, covering import, validation, transfer matching, lot building, form drafting, reconciliation, wash-sale review, and LP math. No tool appears redundant or gratuitous.
The surface covers the core workflow from CSV import through lot calculation, Form 8949 drafting, and 1099-DA reconciliation, with supporting checks for transfers, wash sales, and LP positions. Minor gaps remain around direct manual ledger adjustment and first-class support for exchanges beyond Coinbase/Kraken, though the generic CSV path provides a workaround.
Build the lot inventory per account and every disposal with basis, gain and holding period. PREMIUM (license).
Methods: fifo (the default rule when no specific identification is made, Treas. Reg. 1.1012-1(j)), lifo, hifo, or specific_id via a row's specific_lots {lot_id: qty}. Typical input {"ledger": , "method": "hifo", "transfers": } returns {"disposals": [{"row": "cb9", "asset": "BTC", "qty": "0.5", "proceeds": "31000.00", "basis": "20000.00", "gain": "11000.00", "term": "long", ...}], "open_lots": [...], "summary": {"short_term": {...}, "long_term": {...}}}. Fees: a cash purchase's fee joins basis; a sale's or exchange's fee reduces the amount realized (1.1001-7); a network fee paid in the transferred asset is a disposal of those units (transfer_fee_policy dispose) unless you choose ignore. Transfers between your own accounts move lots with their basis and acquisition date. Use once ledger_lint reports no errors. Not tax advice: it applies the stated rules to your rows and shows its work. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "method must be fifo, lifo, hifo or specific_id"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| ledger | Yes | canonical rows. | |
| method | No | fifo, lifo, hifo or specific_id (rows without specific_lots fall back to fifo). | fifo |
| tax_year | No | when set, only disposals in that calendar year are returned (the inventory still runs from the start). | |
| transfers | No | pairs from match_transfers ({"out": id, "in": id, ...}); empty to auto-match with the defaults. | |
| on_missing_lots | No | error (default), or zero_basis for lenient mode - disposals beyond the lots held get zero basis and unmatched transfer_out rows simply leave the inventory, each flagged. | error |
| transfer_fee_policy | No | dispose (default) or ignore for network fees paid in the transferred asset. | dispose |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial context on top: PREMIUM licensing, fee treatment rules for purchases, sales, and network fees, transfer basis carry-over, and the crucial fact that it never raises a protocol error but returns an {"error":...} object, making retry-after-fix safe. That is exactly the behavioral detail annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose in the first sentence, then layers methods, worked example, fee rules, and error contract in a logical order. It is dense and long, and the inline JSON example plus the fee discussion could be tightened, but nearly every sentence carries decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and 100% param coverage, the description still supplies workflow prerequisites, a concrete response shape, and error semantics. Nothing an agent needs to invoke it correctly, or to interpret a failure, is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real semantics: the Treasury Regulation basis for fifo as default, the specific_lots {lot_id: qty} shape for specific_id, and the meaning of transfer_fee_policy dispose vs ignore. It does not elaborate on tax_year or on_missing_lots beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Build) and resource (lot inventory) plus the outputs it produces: disposals with basis, gain, and holding period. It is clearly distinct from siblings like ledger_lint (validation), match_transfers (pairing), and form_8949_rows (reporting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the precondition 'Use once ledger_lint reports no errors', which tells the agent where this sits in the workflow, and explains when to choose specific_id over the automatic methods. It stops short of naming when NOT to use it or which sibling consumes its output (e.g. form_8949_rows).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lay the disposals out as Form 8949 rows with box categories and totals. PREMIUM (license).
Typical input {"disposals": , "tax_year": 2026, "default_reporting": "proceeds_only"} returns {"part_i": {"B": [rows]}, "part_ii": {"E": [rows]}, "totals": {...}}. Columns follow the form: description (a), date acquired (b), date sold (c), proceeds (d), cost or other basis (e), code (f), adjustment (g), gain or loss (h). Box: A/D when the broker reported proceeds and basis, B/E when proceeds only, C/F when no broker form - set per row in reporting {row_id: value} or for all rows with default_reporting. Use to draft the schedule from computed disposals. Not a filing: check the current form instructions. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "disposals must be a non-empty list from build_lots"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| tax_year | Yes | the calendar year of the disposals to include. | |
| disposals | Yes | rows from build_lots. | |
| reporting | No | per-row override: proceeds_and_basis, proceeds_only or none. | |
| whole_dollars | No | round each row to whole dollars as the form permits. | |
| default_reporting | No | proceeds_and_basis, proceeds_only or none (default). | none |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, while the description adds useful context: premium licensing, not a filing, and a non-protocol error object with safe retry after correction. The main behavioral profile is well covered, though it does not discuss auth or rate concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then gives an example, column mapping, box rules, and error behavior. It is longer than a minimal definition but appropriately structured for a complex tax-form tool; the length is mostly earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description still provides a return-shape example and explains the error object. For a five-parameter tool with nested objects and tax-form-specific box logic, it supplies enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining box mapping (A/D, B/E, C/F) and the Form 8949 column sequence. It also clarifies how reporting and default_reporting affect per-row classification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: laying disposals out as Form 8949 rows with box categories and totals. It also distinguishes the tool's role by tying its input to build_lots and computed disposals, so an agent can tell it is downstream of lot-building rather than a substitute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly says to use the tool to draft the schedule from computed disposals and names build_lots as the source of input. It does not spell out when not to use it or contrast it with other sibling tools, but the intended usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the problems that break a lot build: missing values, duplicates, negative balances. FREE.
Typical input {"ledger": } returns {"issues": [{"severity": "error", "row": "cb12", "issue": "sell of 0.5 BTC exceeds balance 0.2 in account coinbase"}], "balances": {"coinbase": {"BTC": "0.2"}}, "counts": {...}}. Balances are running quantities per account and asset in time order, ignoring transfers' fiat values. Use after parse_transactions and before build_lots. Not a tax check: it checks the ledger's arithmetic consistency only. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| ledger | Yes | canonical rows (ts, type, asset, qty, fiat_value, fees, account...). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, so the bar is lower, and the description still adds real value: it discloses that invalid input never raises a protocol error but returns an {"error": ...} object, and that retry after correction is safe. It also explains balance semantics (running quantities per account and asset in time order, transfers' fiat values ignored), which is behavior no annotation conveys. Not a 5 only because error key coverage is summarized rather than enumerated exhaustively, though the example carries most of it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and the FREE marker, then input/output shape, then ordering, then failure semantics — a sensible priority order with no filler sentences. The full example output is slightly long given an output schema exists, but it earns most of its space by illustrating issue and balance structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter validator with rich annotations and an output schema, nothing an agent needs is missing: it knows the input source, pipeline position, what the balances mean, and how errors surface. Return values are illustrated only as far as needed, since the output schema carries the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and the schema covers it at 100%, so the baseline is already a 3. The description goes beyond the schema by sourcing the rows ('<rows from parse_transactions>'), telling the agent where the input comes from, and showing a concrete input example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Find the problems that break a lot build: missing values, duplicates, negative balances' — and immediately delimits scope against siblings ('Not a tax check'). An agent can distinguish this from build_lots, match_transfers, or wash_window_check without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit ordering in the pipeline ('Use after parse_transactions and before build_lots') and an explicit exclusion ('Not a tax check: it checks the ledger's arithmetic consistency only'). Both when-to-use and when-not-to-use are present, with the predecessor named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Impermanent loss, hold-vs-pool value and basis split for a two-asset constant-product pool. FREE.
Typical input {"deposit": {"asset_a": "ETH", "qty_a": "1", "price_a": "2000", "asset_b": "USDC", "qty_b": "2000", "price_b": "1"}, "current_prices": {"ETH": "3000", "USDC": "1"}} returns {"il_pct": "-2.02", "hold_value": "5000.00", "pool_value": "4898.98", "deposit_value": "4000.00", "basis_split": {...}}. The pool value assumes x*y=k with no fees; add fees_earned_fiat to see the net. The basis split is the deposit's fiat value at deposit, allocated by each side's share, which is the arithmetic a lot engine needs if the LP position is treated as one asset. Use for DeFi position reviews. Not a determination of whether the deposit is a taxable exchange. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "deposit and current_prices must be objects"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| deposit | Yes | asset_a, qty_a, price_a, asset_b, qty_b, price_b at the time of deposit. | |
| current_prices | Yes | {asset: price} for both assets now. | |
| fees_earned_fiat | No | fees accrued to the position, in fiat. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations it discloses the valuation model (x*y=k, no fees by default, fees_earned_fiat for net), the error contract (never raises, returns an {"error": ...} object), and retry safety. The read-only/idempotent sentence repeats the annotations rather than adding to them, which keeps this from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the opening sentence, followed by a minimal worked example, then assumptions, then error semantics. The example JSON is verbose but carries real structural information the schema lacks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Nested input shape, valuation assumptions, fee handling, and the non-raising error contract are all covered, which is what an agent needs for a 3-parameter nested tool. The inline return-value example is partly redundant given an output schema exists, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline would be 3, but the embedded example concretely shows the nested key names and value formats inside deposit and current_prices that the schema only gestures at with additionalProperties. It also explains what fees_earned_fiat does to the result, which is more than the schema's one-line description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names the three computations (impermanent loss, hold-vs-pool value, basis split) and the domain (two-asset constant-product pool), which is far more specific than the name 'lp_position_math' alone. It does not explicitly distinguish itself from siblings like build_lots or ledger_lint, but the computational scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use for DeFi position reviews' gives a clear usage context, and 'Not a determination of whether the deposit is a taxable exchange' is an explicit exclusion. It stops short of naming an alternative tool or stating the conditions that would route an agent elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pair withdrawals with the deposits that received them between your own accounts. FREE.
Typical input {"ledger": , "window_minutes": 1440} returns {"pairs": [{"out": "kr91", "in": "cb14", "asset": "BTC", "from": "kraken", "to": "coinbase", "network_fee": "0.0001", "minutes": 42.0}], "unmatched": {"transfer_out": [...], "transfer_in": [...]}}. A pair needs the same asset, a different account, the deposit inside the window after the withdrawal, and a quantity within tolerance_pct of the amount sent net of the fee. Use before build_lots so basis and holding period move with the coins instead of being treated as a sale. Not for transfers to third parties: those stay unmatched and should be typed gift_out or sell. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| ledger | Yes | canonical rows. | |
| tolerance_pct | No | allowed quantity difference in percent after the fee (default 1). | |
| window_minutes | No | how long after the withdrawal the deposit may land (default one day). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description goes further: it specifies the matching predicate (same asset, different account, deposit inside window, quantity within tolerance_pct of amount net of fee) and a full error contract — no protocol errors, an {"error": ...} object, and retry safety after correction. That is meaningful context an agent cannot get from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then a worked example, matching criteria, intended ordering, exclusions, and error behavior — a sensible progression. It is dense and borderline long (the inline example is verbose), but no sentence is wasted and the 'FREE' note is the only soft addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter matching tool with an output schema, the description supplies everything else an agent needs: input shape, match semantics, sequencing relative to build_lots, out-of-scope cases, and error/retry behavior. Return-shape explanation is technically redundant with the output schema but harmless.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description earns extra credit by explaining what the parameters mean operationally: tolerance is compared against the amount sent net of fee, and the window is measured after the withdrawal. The example input concretizes ledger and window_minutes usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Pair withdrawals with the deposits that received them between your own accounts' — and immediately bounds scope to transfers among the user's own accounts. Sibling differentiation is explicit via build_lots and the exclusion of third-party transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit ordering instruction ('Use before build_lots so basis and holding period move with the coins instead of being treated as a sale') and an explicit exclusion ('Not for transfers to third parties: those stay unmatched and should be typed gift_out or sell'). There is nothing left to infer about when to reach for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds substantive behavior: unrecognised rows are returned with reasons rather than dropped, row/fee semantics are explained, and invalid input returns an error object instead of raising a protocol error, with safe retry after correction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is front-loaded and mostly earns its space by covering supported formats, usage order, row semantics, and error behavior. It is somewhat long, and parts such as the return shape overlap with the output schema, but the structure remains clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a parsing tool with three parameters and an output schema, the description covers supported inputs, error handling, row normalization semantics, and sequencing with sibling tools. An agent has enough information to invoke it correctly without needing to infer missing behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented in the schema. The description adds typical input/output examples and clarifies source_hint values, but it does not add much parameter semantics beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: 'Normalise an exchange CSV export into the canonical ledger rows.' It names the supported exchange formats and explicitly positions the tool before ledger_lint and build_lots, which distinguishes it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use the tool ('Use before ledger_lint and build_lots') and when not to use it ('Not for other exchanges: convert those to the generic columns first'). The supported inputs and source_hint examples make the selection criteria concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diff the broker's 1099-DA lines against the computed disposals. PREMIUM (license).
Typical input {"disposals": , "form_rows": [{"asset": "BTC", "date_sold": "2026-03-04", "qty": "0.5", "proceeds": "31000", "basis": "", "account": "coinbase"}]} returns {"matched": [...], "broker_missing_basis": [...], "basis_mismatch": [...], "proceeds_mismatch": [...], "unmatched_form_rows": [...], "unmatched_disposals": [...]}. A line matches a disposal on the same account (when given), asset and sale date with quantity and proceeds inside the tolerances; several lots sold in one order are summed first. Use when the form arrives and the basis column is blank for coins that came from your own wallet. Not a substitute for the broker's statement. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "disposals must be a non-empty list from build_lots"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| disposals | Yes | rows from build_lots. | |
| form_rows | Yes | 1099-DA lines: asset, date_sold, qty, proceeds, basis (may be blank), account (optional), id (optional). | |
| money_tolerance | No | allowed proceeds/basis difference in fiat units (default 1.00). | |
| qty_tolerance_pct | No | allowed quantity difference in percent (default 0.5). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description explains matching logic, tolerance behavior, summing of multiple lots in one order, output categories, premium licensing, and a non-raising error contract with retry safety. This adds substantial behavioral context for a read-only reconciliation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then efficiently covers premium status, example input, matching rules, usage guidance, errors, and retry safety. Despite its length, every section contributes to correct invocation of a complex reconciliation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema, output schema, and annotations, the description is complete enough for an agent to call the tool correctly. It covers the expected input shape, matching behavior, return categories, error handling, and safe retry after correction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 still adds meaningful semantics by showing a typical input example, clarifying that basis may be blank, and explaining how account, asset, sale date, quantity, and proceeds are used in matching.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Diff the broker's 1099-DA lines against the computed disposals.' It clearly identifies the reconciliation purpose and names build_lots as the source of disposals, but it does not explicitly contrast itself with relevant siblings such as form_8949_rows or match_transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete usage condition: 'Use when the form arrives and the basis column is blank for coins that came from your own wallet.' It also adds a clear exclusion, 'Not a substitute for the broker's statement,' though it does not name a specific alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flag loss disposals with a repurchase of the same asset inside the window. FREE.
Typical input {"disposals": , "acquisitions": [{"asset": "ETH", "ts": "2026-02-10T10:00:00Z", "qty": "2"}]} returns {"flags": [{"row": "cb7", "asset": "ETH", "loss": "-410.00", "repurchases": [...]}], "rule_status": "..."}. The 30-day window before and after the sale is the one IRC 1091 uses for stock or securities; as checked on the verification date that statute had not been extended to digital assets that are not securities, so the output is a heads-up for planning, not an adjustment. Use when reviewing loss harvesting. Not a determination that any rule applies. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "disposals and acquisitions must be lists"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| disposals | Yes | rows from build_lots (uses asset, disposed_at, gain, row). | |
| window_days | No | days before and after the loss disposal to scan (default 30). | |
| acquisitions | Yes | purchases/income rows with asset, ts, qty (ledger rows work as-is). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: it states that the tool is free, explains the IRC 1091 window rationale, warns that the statute was not extended to non-security digital assets, and discloses that invalid input returns an error object rather than a protocol error. It also confirms read-only/idempotent retry safety, which reinforces rather than contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then gives a compact example, legal context, usage note, error behavior, and retry safety. The content is dense but every section adds decision-relevant information for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for this tool: annotations cover safety, the schema covers all parameters, and an output schema exists. The description additionally supplies legal caveats, error behavior, input provenance, and retry guidance, leaving no major gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 useful meaning by showing a typical input shape, linking disposals to build_lots rows, and illustrating the output flags, which goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: flags loss disposals with same-asset repurchases inside a window. The scope and relation to build_lots are clear, but it does not explicitly differentiate itself from sibling tools such as match_transfers or reconcile_1099da.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Says to use it when reviewing loss harvesting and clarifies that the output is a planning heads-up, not a legal determination or adjustment. It gives clear context but does not name alternative tools or explicit when-not-to-use conditions beyond the legal caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
build_lotsform_8949_rowsledger_lintlp_position_mathmatch_transfersparse_transactionsreconcile_1099dawash_window_checkCrypto and securities tax data: summaries, positions, lots, transactions; prepare wallet imports.
Equity comp tax/trade optimizer: ISO/AMT exercise, NSO, RSU, QSBS, concentration, hedging. 50-state.
Review crypto transactions, cost basis, gains, income and tax reports in your Awaken Tax account.
Kryptos crypto portfolio, transaction, tax and accounting tools and reconciliation.
Add one secure layer between your agents and this server.
