Cryptotaxedge MCP Server

Classify a batch of blockchain transactions (up to 100) using CryptoTaxEdge's classification engine. Built for accounting platforms integrating CryptoTaxEdge as their classification layer. Returns per-transaction: category (the open vocabulary the engine emits, for example swap, transfer, staking, reward, airdrop, income_receipt, fee_payment, borrow, repay, collateral_supply, collateral_withdraw, liquidity_add, liquidity_remove, wrap, unwrap, liquid_staking_mint, bridge_transfer, nft_mint, spam, unclassified; the full set with house treatments is at https://cryptotaxedge.com/standard/#categories and grows additively, so branch exhaustive logic on treatment, never on category), treatment (closed enum: disposal, income, non_taxable, expense, needs_review; needs_review means no treatment is asserted), tax_category (the engine's stored treatment value, kept for existing hosts), taxable, confidence score, needs_review, ledger_action, protocol, description (plain-English reasoning, also returned as explanation for existing clients), assets (sent, received, gas) and a reliability envelope with an explicit route-to-review flag. Complex multi-step transactions (flash loans, batch NFT sales, bridges, DCA programs) additionally return a per-leg breakdown and a preparer-ready memo with IRS citations. EVM + Solana. Pass engagement_id / firm_id to apply firm-specific classification policy when configured.

Classify a single blockchain transaction using CryptoTaxEdge's multi-source consensus engine, the same engine and serve semantics as the public REST /v1/classify endpoint. Returns the /v1 contract fields: category (the open vocabulary the engine emits, for example swap, transfer, staking, reward, airdrop, income_receipt, fee_payment, borrow, repay, collateral_supply, collateral_withdraw, liquidity_add, liquidity_remove, wrap, unwrap, liquid_staking_mint, bridge_transfer, nft_mint, spam, unclassified; the full set with house treatments is at https://cryptotaxedge.com/standard/#categories and grows additively, so branch exhaustive logic on treatment, never on category), treatment (closed enum: disposal, income, non_taxable, expense, needs_review; needs_review means no treatment is asserted and taxable is null), taxable, confidence, needs_review, ledger_action, protocol, description (plain-English reasoning, also returned as explanation for existing clients) and, on hash lookups, assets (sent, received, gas). Works for EVM chains and Solana. Provide tx_hash (chain optional, auto-detected), or contract_address + function_selector + chain for a rule-library tuple lookup.

Look up a smart contract in CryptoTaxEdge's registry. Returns protocol metadata, contract type, verified ABI availability, label, and category hints. Use before deciding whether to classify a tx.

Map classified blockchain transactions into journal-entry-ready ledger lines against a chart of accounts. For each transaction (up to 100): debit account, credit account, optional gain/loss plug account, memo (protocol + reasoning), confidence, and a route-to-review flag, plus category roll-ups with the governing US tax authority (IRC §1001, §61, Rev. Rul. 2019-24, Rev. Rul. 2023-14, etc.). Pass your own chart_of_accounts (array of {name, type}) and the tool maps to YOUR account names; omit it for a standard crypto-treasury chart. Suggested, non-binding entries: the ledger platform owns amounts, cost basis, and posting.

Verify a batch of caller-assigned transaction labels (up to 100) against CryptoTaxEdge's deterministic classification basis: rules, the verified cache and the answer guards, with no model call. Returns per row a verdict (agree, disagree, unverifiable), the engine's cte_category, cte_treatment and cte_taxable when known, confidence (a routing signal, not an accuracy claim), evidence (the checks run: label mapping, basis, legs vs on-chain transfers, label vs token flows, protocol registry, taxability, calibration), a suggested_fill and a machine-readable dispute (dispute_id, failed check, evidence, how to contest, review_sla_hours) on disagree, and a reason with fill_available on unverifiable. A row with no deterministic basis is unverifiable and free; pass fill=true on that row to run the classification engine on it (that row is then a fill). Labels are read in the Standard vocabulary (https://cryptotaxedge.com/standard/#categories), the served ledger-action labels, and the Koinly and CoinTracker export vocabularies; an unmapped label is unverifiable (label_unmapped), never best-effort matched. Verify does not decide tax treatment beyond the published Standard and does not file.