cryptotaxedge

Server Details

US tax classification for on-chain transactions: category, treatment, confidence, review flags.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 75.7% over 38 days
Last Tested: 2026-09-24 01:37
Transport: Streamable HTTP · MCP 2025-03-26
URL

TDQS

A4.2/5.0

Scored 2026-09-02 22:25 across 4 tools

Disambiguation4/5

Classify_batch and classify_transaction share the same core classification purpose, but their single-vs-batch distinction is clearly described and predictable. lookup_contract and map_to_chart_of_accounts each address a distinct stage in the workflow, so overall ambiguity is low.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: classify_batch, classify_transaction, lookup_contract, map_to_chart_of_accounts. The verbs are clear and the naming style is uniform across the set.

Tool Count5/5

Four tools is well-scoped for a focused crypto tax classification and ledger-mapping server. Each tool covers a meaningful part of the workflow without unnecessary redundancy or bloat.

Completeness4/5

The set covers classification (single and batch), contract lookup, and chart-of-accounts mapping, which forms a coherent pipeline. Minor gaps remain, such as no tool for managing classification policies or listing supported categories, but these are workable through documentation and external configuration.

Available Tools

4 tools

classify_batchClassify transaction batchA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`firm_id`	No	(Optional) host-side firm identifier. When firm classification policy is configured, applies that firm's confidence thresholds + CoA overrides.
`transactions`	Yes	Array of transactions to classify (max 100 per call).
`engagement_id`	No	(Optional) host-side engagement identifier. Reserved for firm-policy + engagement-record correlation. No effect today; forward-compatible.

Output Schema

ParametersJSON Schema

Name	Required	Description
`results`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

The description goes far beyond the annotations by detailing the output contract, the open-ended category vocabulary, the closed treatment enum with needs_review semantics, and the warning to branch on treatment rather than category. It also discloses complex multi-step transaction handling, supported chains, and the route-to-review flag, all without contradicting the readOnly/openWorld/idempotent annotations.

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 long but front-loaded and information-dense. The category enumeration and warning are verbose but operationally important for correct use of the open-world output. It earns its length, though it could be slightly tightened.

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 tool with real complexity, the description covers the output fields, treatment semantics, open-vocabulary behavior, multi-leg transaction handling, chain support, and firm policy parameters. There is no significant missing information that would prevent an agent from invoking it correctly.

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?

The input schema already covers all parameters with 100% description coverage, so the baseline applies. The description adds some context around firm_id/engagement_id and the 100-transaction limit, but does not substantially re-explain individual parameters beyond 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 states a specific operation ('classify a batch of blockchain transactions'), the resource (CryptoTaxEdge classification engine), and the batch scope (up to 100). The explicit 'batch' framing distinguishes it from the sibling classify_transaction even without naming it directly.

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?

The description clearly frames when this tool is appropriate: batched classification for accounting platforms, with guidance on passing firm_id/engagement_id to apply firm-specific policy. It lacks explicit exclusion language like 'for single transactions use classify_transaction instead,' but the context is otherwise clear.

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

classify_transactionClassify one transactionA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`chain`	No	Chain slug (e.g. "ethereum", "polygon", "bsc", "arbitrum", "base", "optimism", "avalanche", "solana"). Optional for tx_hash lookups; the engine auto-detects the chain. REQUIRED for contract_address lookups.
`tx_hash`	No	Transaction hash (0x-prefixed 66-char for EVM, base-58 for Solana). Either tx_hash OR contract_address is required.
`contract_address`	No	(Optional) 0x-prefixed contract address the transaction called. With function_selector + chain, performs a rule-library tuple lookup.
`function_selector`	No	(Optional) 0x-prefixed 4-byte function selector (first 4 bytes of tx input data).

Output Schema

ParametersJSON Schema

Name	Required	Description
`assets`	No	Net asset movements, same shape as REST /v1: sent and received legs plus the gas leg (null when not attributable). Present when the engine response carries them.
`taxable`	No	null when needs_review
`category`	Yes	Canonical category. Open vocabulary that only grows additively; tolerate unfamiliar values and branch exhaustive logic on treatment instead. Full set with house treatments: https://cryptotaxedge.com/standard/#categories
`protocol`	No
`treatment`	Yes	Closed five-value tax treatment enum, safe to switch on exhaustively. needs_review means no treatment is asserted.
`confidence`	Yes
`description`	No	Plain-English reasoning for the verdict, same field as REST /v1.
`explanation`	No	Deprecated alias of description, kept for existing clients.
`needs_review`	Yes
`ledger_action`	No	Suggested ledger label for posting, same field as REST /v1.

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, and open-world behavior. The description adds substantive context: multi-source consensus engine, open category vocabulary that grows additively, instruction to branch on treatment rather than category, and needs_review semantics with null taxable.

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?

Front-loaded with the core purpose and efficient overall. The long category enumeration is justified because it supports the important open-world warning, though the description is dense and slightly rambling near the end.

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?

Given the output schema exists and annotations cover safety, the description adequately covers input modes, open-world semantics, treatment enum behavior, and chain requirements. Nothing essential for selecting or correctly invoking this tool is missing.

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%, and the schema already documents chain auto-detection, the required chain for contract_address, and the rule-library tuple lookup. The description synthesizes these into lookup modes but adds no new parameter facts beyond 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?

States a specific verb and resource: 'Classify a single blockchain transaction'. The word 'single' differentiates it from classify_batch, and the contract-address rule-library lookup mode distinguishes it from lookup_contract.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear invocation modes: tx_hash with optional chain, or contract_address + function_selector + chain for a rule-library lookup. However, it never explicitly names sibling tools or states when to prefer classify_batch or lookup_contract over this tool.

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

lookup_contractLook up contract metadataA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`chain`	Yes	Chain slug (e.g. "ethereum", "polygon", "arbitrum"). EVM only.
`address`	Yes	Contract address (0x-prefixed 42-char for EVM).

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	No
`chain`	No
`category`	No
`protocol`	No

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds contextual behavior by positioning this as a pre-classification lookup, but it does not add deeper details like error behavior, availability guarantees, or chain constraints beyond what the schema states.

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?

Two sentences, no filler, and structured to front-load the core lookup action and result contents. The usage guidance is a separate short sentence that earns its place.

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 simple read-only lookup with full schema coverage, annotations covering safety, an output schema, and clear usage context, nothing essential is missing. An agent has enough to invoke it correctly and understand its role relative to classification tools.

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%, with both 'chain' and 'address' already documented including format and EVM-only scope. The description adds no new parameter-level meaning, so the baseline score of 3 is appropriate.

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 clearly states a specific action ('Look up a smart contract'), a specific resource ('CryptoTaxEdge's registry'), and the kind of data returned. It also differentiates the tool from the classification and accounting siblings by framing this as a prerequisite metadata lookup.

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?

The description explicitly says to use it before deciding whether to classify a transaction, giving clear contextual guidance. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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

map_to_chart_of_accountsMap to chart of accountsA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`transactions`	Yes	Transactions to classify + map (max 100 per call).
`chart_of_accounts`	No	Optional: your chart of accounts as [{name, type}]. Account names are pattern-matched per role (digital assets, income, fees, realized G/L, collateral, LP positions, loan payable). Omit for the standard chart.

Output Schema

ParametersJSON Schema

Name	Required	Description
`account`	No
`mapping_basis`	No

TDQS

A4.4/5.0

Behavior4/5

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

The annotations declare readOnlyHint=true and idempotentHint=true, and the description reinforces this by stating the entries are 'suggested, non-binding' and that the ledger platform owns amounts, cost basis, and posting. This adds meaningful behavioral context beyond the annotations, such as the non-posting nature of the tool and the route-to-review flag behavior.

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 dense but well-structured: purpose first, then output details, then parameter guidance, then a caveat. The legal citations add specificity but are somewhat verbose; still, they are relevant for a tax-oriented tool. No filler or repetition.

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?

Given the output schema, annotations, and 100% schema coverage, the description covers all essential operational aspects: input constraints, optional custom chart behavior, non-binding output, and the governing tax authority context. There is no obvious missing information an agent would need to invoke the tool 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 description coverage is 100%, so the baseline is 3. The description adds value by explaining that chart_of_accounts is pattern-matched per role, that custom account names are used when provided, and that omitting it yields a standard crypto-treasury chart. It also clarifies the 100-transaction cap contextually in the description of the output.

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 ('Map') and resource ('classified blockchain transactions' into 'journal-entry-ready ledger lines against a chart of accounts'). It clearly distinguishes itself from sibling tools like classify_batch/classify_transaction by operating on already-classified transactions and producing mapping output rather than classification.

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?

The description implies the tool is for post-classification mapping and clarifies when to pass a custom chart_of_accounts vs. omit it for the standard chart. It does not explicitly name sibling alternatives or say 'use this instead of classify_*', but the context is clear enough for an agent to select it appropriately.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesSep 2, 2026

Changedclassify_batch8 fields changed

changedInput schema / properties / transactions / items / properties / chain / description

Previous value: -"Chain slug (e.g. \"ethereum\", \"polygon\", \"bsc\", \"arbitrum\", \"base\", \"optimism\", \"avalanche\", \"solana\"). Optional; CTE auto-detects if omitted."New value: +"Chain slug (e.g. \"ethereum\", \"polygon\", \"bsc\", \"arbitrum\", \"base\", \"optimism\", \"avalanche\", \"solana\"). Optional; CryptoTaxEdge auto-detects the chain if omitted."

addedOutput schema / properties / results / items / properties / assets

Added value: +{
+  "description": "Net asset movements, same shape as REST /v1: sent and received legs plus the gas leg (null when not attributable). Present when the engine response carries them.",
+  "properties": {
+    "gas": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "received": {
+      "type": "array"
+    },
+    "sent": {
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

changedOutput schema / properties / results / items / properties / category / description

Previous value: -"Canonical category (closed enum, see https://cryptotaxedge.com/taxonomy)"New value: +"Canonical category. Open vocabulary that only grows additively; tolerate unfamiliar values and branch exhaustive logic on treatment instead. Full set with house treatments: https://cryptotaxedge.com/standard/#categories"

addedOutput schema / properties / results / items / properties / description

Added value: +{
+  "description": "Plain-English reasoning for the verdict, same field as REST /v1.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / explanation / description
```
Added value: +"Deprecated alias of description, kept for existing clients."
```
changedOutput schema / properties / results / items / properties / explanation / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```

addedOutput schema / properties / results / items / properties / ledger_action

Added value: +{
+  "description": "Suggested ledger label for posting, same field as REST /v1.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / treatment / description

Added value: +"Closed five-value tax treatment enum, safe to switch on exhaustively. needs_review means no treatment is asserted."

Changedclassify_transaction7 fields changed

addedOutput schema / properties / assets

Added value: +{
+  "description": "Net asset movements, same shape as REST /v1: sent and received legs plus the gas leg (null when not attributable). Present when the engine response carries them.",
+  "properties": {
+    "gas": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "received": {
+      "type": "array"
+    },
+    "sent": {
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

changedOutput schema / properties / category / description

Previous value: -"Canonical category (closed enum, see https://cryptotaxedge.com/taxonomy)"New value: +"Canonical category. Open vocabulary that only grows additively; tolerate unfamiliar values and branch exhaustive logic on treatment instead. Full set with house treatments: https://cryptotaxedge.com/standard/#categories"

addedOutput schema / properties / description

Added value: +{
+  "description": "Plain-English reasoning for the verdict, same field as REST /v1.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / explanation / description

Added value: +"Deprecated alias of description, kept for existing clients."

changedOutput schema / properties / explanation / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

addedOutput schema / properties / ledger_action

Added value: +{
+  "description": "Suggested ledger label for posting, same field as REST /v1.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / treatment / description

Added value: +"Closed five-value tax treatment enum, safe to switch on exhaustively. needs_review means no treatment is asserted."

4 tool updatesSep 2, 2026
- First observedclassify_batch
- First observedclassify_transaction
- First observedlookup_contract
- First observedmap_to_chart_of_accounts

Related MCP Connectors

Eagle Virtual USDT & USDC Blacklist Tracker A
com.eaglevirtual
USDT & USDC blacklist, freeze and seizure records for any wallet. Dated, cited, no risk scores.
Blockchain Cryptocurrency Finance
61
taxsort-mcp B
io.github.lonniev
TaxSort — Tollbooth-monetized MCP server for personal tax transaction classification
Finance AI & Machine Learning
872
Moltline TaxLots A
com.moltlinestudio
Crypto cost-basis lots (FIFO/LIFO/HIFO/specific-ID), Form 8949 rows, 1099-DA diff. 5 of 8 free.
Cryptocurrency Finance Legal & Compliance
81
Arc & Ledger Tax Reference A
com.arcandledger
Read-only US tax reference for notices, deadlines, filing screens, and clearly labeled estimates.
Finance Legal & Compliance
131

Related MCP Servers

CryptoTaxEdge
Cryptocurrency Blockchain Finance
sturs49
A
license
A
quality
B
maintenance
US tax classification for on-chain transactions: tx hash in → canonical category, tax treatment, confidence, and review flags out. 80+ chains.
Updated 21 days ago (2026-09-02 15:20 UTC)
4
MIT
Hive Tax Observer
Cryptocurrency Finance Blockchain
srotzin
A
license
Not graded
quality
C
maintenance
Classifies on-chain crypto transactions into sale, swap, income, or transfer for observational tax-event tracking, surfacing cost-basis-relevant inputs.
Updated 5 months ago (2026-05-01 22:56 UTC)
MIT
TunaPay TX Classifier
Finance Cryptocurrency Blockchain
metaversemm
F
license
Not graded
quality
D
maintenance
Classifies Solana on-chain transactions into tax categories (e.g., swap, stake, NFT) and exports CSV reports compatible with TurboTax and CoinTracker.
Updated 7 months ago (2026-03-03 13:55 UTC)
-
ClearMarket
Finance Research & Data Open Data
JDSource
A
license
Not graded
quality
B
maintenance
Reference data layer for prediction markets: resolution-clarity grades (A/B/C), named resolution sources with provenance, cross-venue linking, and per-contract eligibility screens across Kalshi and Polymarket. Open,read-only, no key required.
Updated 13 hours ago (2026-09-23 13:19 UTC)
3
MIT

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?