cryptotaxedge

Classify transaction batch

classify_batch

Read-onlyIdempotent

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.

Input 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

Name	Required	Description	Default
`results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedSep 2, 2026

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

First observedSep 2, 2026

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.

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?