Provides US tax classification for on-chain Ethereum transactions, including swaps, liquidity adds, rewards, and bridges, with per-leg asset breakdowns and counterparty identification.
Provides US tax classification for on-chain Solana transactions, including swaps, liquidity adds, rewards, and bridges, with per-leg asset breakdowns and counterparty identification.
US tax classification for on-chain transactions, as an MCP server. Submit transaction hashes and get back the canonical event category, the US tax treatment with cited authority, a calibrated confidence score, an explicit route-to-review flag on uncertain rows, and per-leg breakdowns with counterparty identification. 80+ chains, including Ethereum, the major L2s, and Solana.
This is a remote MCP server — nothing to install or run locally.
Endpoint: https://mcp.cryptotaxedge.com/ (streamable HTTP, JSON-RPC 2.0)
Auth: Authorization: Bearer YOUR_API_KEY — free self-serve Developer key
(no card) at dashboard.cryptotaxedge.com
under Settings → API Keys
Site: cryptotaxedge.com
Every classification carries the reliability envelope:
Field | Meaning |
| Canonical event type (swap, liquidity_add, reward, bridge, ...) |
| Closed enum: |
|
|
| Routing signal: how strongly independent evidence agreed |
| The honesty contract — uncertain rows are flagged, never guessed |
| On contested treatments (LP, wrap, liquid staking): the position not taken |
| Per-leg sent/received breakdown with counterparties |
Plain transfers, approvals, spam, failed and unsupported transactions, and every repeat come back fully identified at no charge.
Related MCP server: Crypto Tax MCP
List the tools:
curl -X POST https://mcp.cryptotaxedge.com/ \
-H "Authorization: Bearer $CTE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Classify a batch (up to 100 per call):
curl -X POST https://mcp.cryptotaxedge.com/ \
-H "Authorization: Bearer $CTE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"classify_batch","arguments":{"transactions":[{"tx_id":"row_1","tx_hash":"0x...","chain":"ethereum"}]}}}'The same engine is available over plain REST — see the API docs and the developer quickstart.
server.json — published to the official
MCP Registry as
io.github.sturs49/cryptotaxedge.
Listed on Glama
(glama.json).
MIT © 2026 Kevin Stursberg / CryptoTaxEdge. This repository is the public listing (docs, registry manifest, and a small catalog proxy). The classification engine is the remote server above, not this repo.
Glama grades Tool Definition Quality from a container that starts and answers
MCP initialize + tools/list. The image is a tiny Node proxy — it does not
ship the engine. Catalog methods are forwarded to https://mcp.cryptotaxedge.com/.
Listen port: 8080 (override with PORT; binds 0.0.0.0)
Paths: POST / and POST /mcp (streamable HTTP / JSON-RPC)
Health: GET / or GET /health
No API key for initialize, tools/list, or ping
tools/call returns 401 unless CTE_API_KEY is set or the request
already has Authorization: Bearer …
docker build -t cryptotaxedge-mcp .
docker run --rm -p 8080:8080 cryptotaxedge-mcpcurl -X POST http://localhost:8080/ \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"local","version":"0"}}}'
curl -X POST http://localhost:8080/ \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'If Glama generates a Dockerfile and wraps CMD with mcp-proxy --, set the
admin CMD arguments to ["node", "server.mjs", "--stdio"]. The same process
also accepts stdio when started without --stdio.
The category vocabulary and treatment semantics this server returns are the CryptoTaxEdge Classification Standard: an open, versioned schema with worked examples and tax-position caveats, licensed CC BY 4.0. The standard and the 2026 H1 labelled benchmark corpus (388 public transaction hashes) are archived at DOI 10.5281/zenodo.21911546 and mirrored as a Hugging Face dataset: CryptoTaxEdge/crypto-tax-classification-2026h1.
Methodology and benchmark notes: cryptotaxedge.com/research
Verbatim request/response captures, replayed nightly against the live engine: sturs49/cryptotaxedge-examples
Classifications are informational only, not tax advice. Verify results with a qualified tax professional before filing.
Classify a batch of blockchain transactions (up to 100) using CryptoTaxEdge's classification engine. Built for accounting platforms integrating CTE as their classification layer. Returns per-transaction: canonical category (swap / transfer / income_receipt / fee_payment / borrow / repay / collateral_supply / collateral_withdraw / liquidity_add / liquidity_remove / unclassified), tax treatment (taxable, tax category), confidence score, and a natural-language explanation. 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 | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/idempotent/openWorld annotations by detailing the per-transaction result structure, the handling of complex multi-step transactions, supported chains, and the effect of firm policy parameters. It does not discuss rate limits or authentication requirements, but those concerns are less critical given the annotations already establish a safe read-only and idempotent operation.
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 information-dense without being padded: it covers scope, output fields, special handling for complex transactions, supported chains, and policy parameters in a well-organized flow. The core action and key constraints are front-loaded, and every sentence adds value.
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 complexity of the tool, the rich output schema, and the annotations, the description is complete enough for an agent to select and invoke it correctly. It explains return values, constraints, special-case behavior, supported networks, and optional policy-driven parameters without leaving critical operational gaps.
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 the schema already fully documents transactions, firm_id, and engagement_id. The description reinforces the firm_id/engagement_id policy behavior and mentions the max batch size, but it does not add substantial meaning beyond the structured schema descriptions. 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 opens with a precise verb and resource: 'Classify a batch of blockchain transactions (up to 100)'. It clearly distinguishes itself from classify_transaction by emphasizing batch processing, and enumerates the concrete output fields an agent can expect. The purpose is immediately identifiable and not a tautology of the tool name.
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?
The description clearly states the intended use case: accounting platforms integrating CTE as their classification layer, with batches up to 100 transactions. It gives useful context about when to use this batch tool, but it does not explicitly mention when to prefer classify_transaction or other sibling tools, so it stops short of a full when/when-not comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 (swap / transfer / stake / lend / bridge / etc.), treatment (disposal / income / non_taxable / expense / needs_review), taxable, confidence, needs_review, plus a natural-language description. 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 | Default |
|---|---|---|---|
| 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). |
| Name | Required | Description |
|---|---|---|
| taxable | No | null when needs_review |
| category | Yes | Canonical category (closed enum, see https://cryptotaxedge.com/taxonomy) |
| protocol | No | |
| treatment | Yes | |
| confidence | Yes | |
| explanation | No | |
| needs_review | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses the multi-source consensus engine, the public REST /v1/classify semantics, the exact output fields, and the auto-detection of chain from tx_hash. This gives an agent a strong behavioral model of what will happen and what it will receive.
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 four sentences, front-loaded with purpose, and every sentence contributes: what it does, what it returns, where it works, and how to invoke it. No filler or redundant restatement of schema fields.
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?
The description covers input alternatives, output fields, chain support, and key behavioral semantics. It even clarifies the 'either tx_hash or contract_address is required' rule despite the schema listing no required parameters, which is exactly the kind of contextual gap an agent needs resolved.
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?
The input schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds meaningful context by explaining the two alternative lookup modes and the rule-library tuple lookup behavior, which goes beyond the schema's field-level 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?
The description begins with a specific verb and resource: 'Classify a single blockchain transaction', which clearly distinguishes it from the sibling classify_batch tool. It also spells out the return contract fields and supported chains, leaving no ambiguity about what the tool does.
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?
The description clearly states the conditions for use: single-transaction classification, EVM/Solana support, and two input modes (tx_hash or contract_address + function_selector + chain). It does not explicitly name the alternative tools or say 'use classify_batch for multiple transactions', but the 'single' qualifier and sibling names make the intended usage clear without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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). |
| Name | Required | Description |
|---|---|---|
| name | No | |
| chain | No | |
| category | No | |
| protocol | No |
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.
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.
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.
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.
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.
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 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. |
| Name | Required | Description |
|---|---|---|
| account | No | |
| mapping_basis | No |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0classify_batchclassify_transactionlookup_contractmap_to_chart_of_accountsScored across 4 tools
classify_transaction and classify_batch share the same core action and could be confused, though their single-vs-batch distinction is clearly described. lookup_contract and map_to_chart_of_accounts are each unambiguously distinct from the classification tools.
All tool names follow a clear verb_noun style: classify_transaction, classify_batch, lookup_contract, and map_to_chart_of_accounts. The pattern is consistently applied and easy to predict.
Four tools is well-scoped for this server's purpose: contract lookup, single classification, batch classification, and chart-of-accounts mapping. Each tool earns its place and the count stays comfortably within the ideal range.
The core workflow of lookup, classify, batch-classify, and map to ledger entries is well covered. The only notable gap is the absence of a reclassification or review-override tool for adjusting previous decisions, but this is a minor gap for a stateless classification API.
US tax classification for on-chain transactions: category, treatment, confidence, review flags.
Multi-chain wallet intelligence: balances, transactions, ENS, OFAC screening across 7 chains.
TaxSort — Tollbooth-monetized MCP server for personal tax transaction classification
49 crypto intelligence APIs. Whale tracking, DeFi yields, alpha signals. Pay in USDC on Base.