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 by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 88.3% over 79 days
Last Tested: 2026-11-04 03:37
Transport: Streamable HTTP · MCP 2025-03-26
URL
ChatGPT: –
Claude: –

TDQS

A4.3/5.0

Scored 2026-10-24 04:40 across 4 tools

Disambiguation5/5

classify_transaction and classify_batch differ clearly by cardinality, lookup_contract is a distinct pre-classification registry lookup, and map_to_chart_of_accounts is a distinct downstream accounting step. No two tools appear to do the same thing.

Naming Consistency5/5

All tool names use snake_case with verb-led constructions such as classify_*, lookup_*, and map_to_*. The longer map_to_chart_of_accounts is still predictable and readable.

Tool Count5/5

Four tools is lean but well matched to a focused classification-and-mapping service. Single versus batch classification is deliberate, and lookup and mapping are necessary adjuncts rather than filler.

Completeness4/5

The set covers the main pipeline: contract lookup, single and batch classification, and ledger mapping with batch support up to 100. Minor gaps such as retrieval of prior classifications or status/history exist but are not central to the stated purpose.

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.

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

Name	Required	Description
`results`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the read-only, idempotent annotations, the description discloses substantial behavior: per-transaction return fields, a reliability envelope with route-to-review, extra per-leg breakdowns and preparer memos for complex transactions, EVM+Solana support, and firm-policy application. Nothing here 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the single dense paragraph then enumerates many categories and return details that are largely repeated by the output schema. The information is relevant, but the description is longer and less structured than ideal.

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 complex batch-classification tool, the description covers chain support, return shape, reliability signaling, complex-transaction handling, and firm policy. With the output schema also present, an agent has enough context to invoke 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?

Schema coverage is 100%, so all parameters are documented structurally. The description adds useful context for firm_id policy application, but its statement that engagement_id can be passed to apply firm-specific policy is misleading because the schema says engagement_id has no effect today.

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 verb and resource: classify a batch of blockchain transactions, up to 100, using CryptoTaxEdge's engine. The batch scope and 100-item limit distinguish it clearly from the singular classify_transaction sibling without needing to name it.

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 gives clear context by saying it is built for accounting platforms integrating CryptoTaxEdge as their classification layer, and the batch limit implies when to use it over a single-transaction tool. It does not explicitly name alternatives or state when not to use it.

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.

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

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.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine context beyond them: consensus-engine semantics, REST-equivalent behavior, EVM/Solana coverage, auto-detection, and the meaning of needs_review (no treatment asserted, taxable null). It stops short of covering error/not-found behavior or latency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is one sprawling sentence that enumerates ~20 category values and lists every returned contract field even though an output schema already exists. The branching advice ("branch on treatment, never on category") earns its place; the enumeration and field list largely do not.

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?

With full annotations and an output schema present, the description supplies everything still needed to invoke it correctly: both input paths, chain support, auto-detection, and the semantic meaning of the treatment/needs_review enums. No material gap remains for correct selection or invocation.

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%, so all four parameters are already documented, including the tx_hash-or-contract_address requirement and chain being required for contract lookups. The description restates those rules and adds only the framing of the tuple as a "rule-library lookup," which is marginal added meaning 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 opening clause states a specific verb and resource ("Classify a single blockchain transaction") and names the underlying mechanism (multi-source consensus engine, same as REST /v1/classify). "Single" implicitly contrasts with the classify_batch sibling, so an agent can pick between them 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 gives explicit invocation modes: tx_hash with optional auto-detected chain, or the contract_address + function_selector + chain tuple for a rule-library lookup, plus supported chain families. What is missing is an explicit statement of when to prefer this over classify_batch or lookup_contract; that routing is only implied by the word "single".

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.

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

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

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: the data source is an internal registry and results include 'category hints' and ABI 'availability', signaling these are advisory rather than authoritative. It omits what happens on a miss, but the annotation bar is largely met.

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 short sentences, zero waste: purpose first, return contents second, call timing last. Everything is front-loaded and each sentence earns its place.

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?

With a rich annotation set, a 100%-covered two-parameter schema, and an output schema that carries return structure, the description is nearly complete. The only gap is behavior on a failed lookup (unknown contract), which an agent would benefit from knowing.

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 coverage is 100% and both parameters (chain slug, 0x address) are fully documented in the schema, so the description carries no additional parameter burden. Baseline 3 is appropriate — the description adds no syntax or format detail 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 ('look up a smart contract in CryptoTaxEdge's registry') and enumerates what comes back (protocol metadata, contract type, ABI availability, label, category hints). The closing clause ties it to the sibling classify_* tools so an agent can tell which one to reach for first.

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?

Explicitly tells the agent to call this before deciding whether to classify a transaction, which is a concrete usage condition relative to classify_transaction/classify_batch. It stops short of stating when not to use it or what to do when the lookup misses, so no exclusion guidance.

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.

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

Name	Required	Description
`account`	No
`mapping_basis`	No

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds genuinely new context: a 100-transaction-per-call cap, the fact that entries are 'suggested, non-binding' with the ledger platform owning amounts, cost basis, and posting, and a route-to-review flag. That framing prevents an agent from treating the output as authoritative postings, which is exactly the kind of trait annotations cannot express. It stops short of describing error handling or what happens for unmappable roles.

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 purpose, then output shape, then the parameter choice, which is the right ordering. It is dense but mostly earns its space; the enumerated tax citations (IRC §1001, §61, Rev. Rul. 2019-24, 2023-14) add credibility but are the one stretch that could be trimmed.

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?

With an output schema present, the return values needn't be spelled out, and the description still summarizes them; combined with the batch cap, the chart-of-accounts option, and the non-binding framing, an agent has everything needed to invoke this correctly in a classification-to-ledger pipeline.

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%, so both parameters are already documented, including the per-role pattern matching and the omit-for-standard-chart behavior. The description largely restates that (account roles, omitting the chart, the 100 cap already in maxItems) rather than adding new semantic detail such as accepted 'type' values or matching fallback behavior.

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 verb and resource ('Map classified blockchain transactions into journal-entry-ready ledger lines against a chart of accounts') and explicitly scopes the input to already-classified transactions, which implicitly separates it from the sibling classifiers. An agent can tell what the tool produces (debit/credit lines, roll-ups) without opening the schema.

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?

It gives clear guidance for the optional parameter ('omit it for a standard crypto-treasury chart') and implies this runs downstream of classification, but never explicitly says when to use this versus classify_transaction or classify_batch, nor any exclusions or prerequisites. Usage is inferable but not stated.

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

Lukka Reference Data MCP
tech.lukka
Institutional asset taxonomy, scores, entity and VASP directories, mappings and crypto actions.
Cryptocurrency Finance Blockchain
1
https://refdata.mcp.lukka.tech
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
https://mcp.eaglevirtual.com/mcp
Taxy
eu.taxxy
Crypto and securities tax data: summaries, positions, lots, transactions; prepare wallet imports.
Finance Cryptocurrency
1
https://api.taxxy.eu/v1/mcp
bridge-watch on-chain intelligence A
top.agentsapi
Base on-chain address labels (eth-labels 104k category tags), tx explainer, clusters, CCTP USDC.
Blockchain Cryptocurrency Web3 & Decentralized Tech
71
https://agentsapi.top/mcp

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 2 months 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 6 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 8 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-11-03 15:48 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?