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

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.

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

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?