cryptotaxedge

Classify one transaction

classify_transaction

Read-onlyIdempotent

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.

Input Schema

TableJSON 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

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 2, 2026

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."

First observedSep 2, 2026

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.

All cryptotaxedge tools Inspect

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?