7 Transaction Types in Claude Desktop: Complete MCP Transaction Reference

2026-09-18

7 Transaction Types in Claude Desktop: Complete MCP Transaction Reference

MCP developers who want to give Claude onchain capabilities have a surprisingly complete toolkit available today — WAIaaS is an MCP server that exposes 45 tools to Claude Desktop, covering every transaction type your agent might need. Add one JSON block to your claude_desktop_config.json, and your Claude agent goes from conversational to onchain in minutes. This post walks through all 7 supported transaction types, shows you exactly what Claude calls under the hood, and gets you running with a working config.

Why Transaction Type Coverage Matters

When you're building an AI agent that touches real money, vague abstractions are dangerous. An agent that can "send stuff" isn't the same as an agent that understands the difference between a raw native transfer, a token approval, and an NFT move. Each of those operations carries different risk profiles, different policy rules, and different confirmation requirements.

WAIaaS models this explicitly. The transaction schema uses a discriminated union of exactly 7 types: Transfer, TokenTransfer, ContractCall, Approve, Batch, NftTransfer, and ContractDeploy. Claude doesn't need to guess what kind of transaction to construct — it picks the right shape, every time, because the MCP tool definitions enforce the schema.

Step 0: Get the MCP Server Running

Before any of the transaction types below work, you need two things: a running WAIaaS daemon and a session token scoped to a wallet.

The fastest path is the CLI quickstart:

npm install -g @waiaas/cli
waiaas init
waiaas start
waiaas quickset --mode mainnet

quickset creates your wallets, generates session tokens, and prints the exact JSON block to paste into Claude Desktop. If you want to register manually, the config looks like this:

{
  "mcpServers": {
    "waiaas": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_SESSION_TOKEN": "wai_sess_<your-token>",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    }
  }
}

Or use the auto-register shortcut:

waiaas mcp setup --all

That's it. Restart Claude Desktop, and you'll see the WAIaaS tools available in the tool panel. Now let's look at what Claude can actually do.

The 7 Transaction Types

1. Transfer (Native Token)

The simplest type: send the chain's native token (SOL, ETH, etc.) from the agent's wallet to an address.

When you say "Send 0.1 SOL to this address," Claude calls the send_token MCP tool, which maps to this REST call under the hood:

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "type": "TRANSFER",
    "to": "recipient-address",
    "amount": "0.1"
  }'

The transaction goes through the 7-stage pipeline: validate → auth → policy → wait → execute → confirm. If your SPENDING_LIMIT policy has a notify_max_usd threshold, you'll get a notification but the transaction still executes. If it hits delay_max_usd, it queues for the delay window. Above that, it requires your explicit approval.

2. TokenTransfer (ERC-20 / SPL Token)

When Claude needs to send a specific token — USDC, WETH, an SPL token — it uses TokenTransfer. The type distinction matters for policy: ALLOWED_TOKENS policy is evaluated against the token address here, and it's default-deny. If you haven't whitelisted the token, the transaction is blocked.

This is why the policy setup matters before you let an agent loose. A minimal USDC whitelist on Solana looks like:

curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "ALLOWED_TOKENS",
    "rules": {
      "tokens": [{"address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "symbol": "USDC", "chain": "solana"}]
    }
  }'

Without this, Claude trying to move USDC hits POLICY_DENIED and gets back a structured error it can explain to you.

3. ContractCall (Arbitrary Smart Contract Interaction)

This is the workhorse for DeFi. When Claude calls the execute_action MCP tool for a Jupiter swap, an Aave deposit, or any of the 15 integrated DeFi protocols, it ultimately resolves to a ContractCall transaction type.

The REST layer for a Jupiter swap looks like this:

curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount": "1000000000"
  }'

ContractCall transactions are governed by the CONTRACT_WHITELIST policy — also default-deny. You need to explicitly whitelist Jupiter's router address before Claude can swap. This is intentional: an agent that can call arbitrary contracts without restriction is a significant security surface.

The 15 DeFi protocol providers available via action-provider MCP tool include: aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, and zerox-swap.

4. Approve (Token Approvals)

Token approvals are a distinct transaction type in WAIaaS, not just another ContractCall. This matters because approvals have their own policy types: APPROVED_SPENDERS (default-deny whitelist of addresses that can receive approvals), APPROVE_AMOUNT_LIMIT (blocks unlimited approvals), and APPROVE_TIER_OVERRIDE (forces a specific security tier for all approval transactions regardless of amount).

If Claude is preparing a DeFi position that requires approving a DEX router to spend your USDC, it will first construct an Approve transaction. Without APPROVED_SPENDERS configured, this is blocked. This prevents a class of attacks where an agent could be tricked into approving a malicious contract.

Before running an agent that interacts with DeFi, add:

curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "APPROVED_SPENDERS",
    "rules": {
      "spenders": [{"address": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4", "name": "Jupiter", "maxAmount": "1000000000"}]
    }
  }'

5. Batch (Atomic Multi-Step Transactions)

Batch lets Claude bundle multiple operations into a single atomic transaction. This is useful for approve+swap in one step, or multi-token portfolio rebalancing. The send_batch MCP tool maps to this type.

On EVM chains with ERC-4337 Account Abstraction enabled, batches execute as a single UserOperation — one signature, one gas payment, atomic success or failure. On Solana, batch transactions use native instruction bundling.

Before executing a batch, Claude can simulate it:

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "type": "TRANSFER",
    "to": "recipient-address",
    "amount": "0.1",
    "dryRun": true
  }'

The simulate-transaction MCP tool and the dryRun flag let Claude reason about what a transaction will do before committing. For batch operations especially, this is worth building into your agent's workflow.

6. NftTransfer

NFT moves are a distinct type with their own resolution path. WAIaaS supports ERC-721 and ERC-1155 on EVM chains and Metaplex NFTs on Solana, with metadata caching so Claude can tell you what you're actually moving before it moves it.

The transfer_nft and list_nfts MCP tools let Claude inventory your NFTs and execute transfers. From Claude Desktop:

User: "Show me my NFTs"
→ Claude calls list_nfts → returns collection with metadata

User: "Transfer the Solana Monkey #4231 to this address"
→ Claude calls transfer_nft with the mint address and recipient

The get_nft_metadata tool resolves metadata before the transfer, so Claude can confirm with you: "This will transfer Solana Monkey #4231 (floor price: X SOL) to address Y. Confirm?" — before the NftTransfer transaction hits the pipeline.

7. ContractDeploy

The seventh type is ContractDeploy — deploying a new smart contract from the agent's wallet. This is the highest-risk transaction type by nature and will almost always land in the APPROVAL security tier under a SPENDING_LIMIT policy given the gas costs involved.

This type is available for agents building onchain systems programmatically — deploying escrow contracts, token contracts, or agent-owned infrastructure. It follows the same pipeline as every other type: validate → auth → policy → wait → execute → confirm.

Security Tiers in Practice

Every one of these 7 types flows through the policy engine with 4 possible outcomes: INSTANT (execute now, no notification), NOTIFY (execute now, notify you), DELAY (queue it, cancellable window), or APPROVAL (you must sign off via WalletConnect, Telegram, or Push).

A realistic policy setup for an agent you trust with small amounts but want oversight on larger moves:

curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "SPENDING_LIMIT",
    "rules": {
      "instant_max_usd": 100,
      "notify_max_usd": 500,
      "delay_max_usd": 2000,
      "delay_seconds": 900,
      "daily_limit_usd": 5000
    }
  }'

Under $100: Claude acts immediately. $100-$500: acts immediately, you get notified. $500-$2000: queues for 15 minutes, you can cancel. Over $2000: stops and waits for your wallet signature.

When Claude's transaction is blocked by policy, it receives a structured error it can explain:

{
  "error": {
    "code": "POLICY_DENIED",
    "message": "Transaction denied by SPENDING_LIMIT policy",
    "domain": "POLICY",
    "retryable": false
  }
}

Claude can surface this to you as "This transfer exceeds your daily limit — do you want to approve it manually?" rather than silently failing.

Quick Start: From Zero to All 7 Types in 5 Steps

1. Install the CLI and start the daemon:

npm install -g @waiaas/cli
waiaas init
waiaas start

2. Create wallets and sessions:

waiaas quickset --mode mainnet

3. Paste the printed config into Claude Desktop's config file (or run waiaas mcp setup --all to auto-register).

4. Set up your policies (at minimum: SPENDING_LIMIT, ALLOWED_TOKENS, CONTRACT_WHITELIST, APPROVED_SPENDERS).

5. Open Claude Desktop and try:

"What's my wallet balance?"
"Swap 0.01 SOL for USDC on Jupiter"
"Show my DeFi positions"

Claude will call get_balance, then execute_action with the jupiter-swap provider, then get_defi_positions — all from natural language, all going through your policy rules.

Multi-Wallet Setup

If you're running separate agents for different strategies, you can run multiple MCP server instances, each scoped to a different wallet and session token:

{
  "mcpServers": {
    "waiaas-trading": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_AGENT_ID": "019c47d6-51ef-7f43-a76b-d50e875d95f4",
        "WAIAAS_AGENT_NAME": "trading-agent",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    },
    "waiaas-solana": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_AGENT_ID": "019c4cd2-86e8-758f-a61e-9c560307c788",
        "WAIAAS_AGENT_NAME": "solana-wallet",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    }
  }
}

Each wallet gets its own policy set, its own session limits, and its own spending controls. Claude Desktop will show both as separate tool namespaces.

Exploring the OpenAPI Reference

The 39 REST API route modules behind all of this are documented at /reference on your running daemon:

# View the full OpenAPI spec
curl http://127.0.0.1:3100/doc -o openapi.json

# Open the interactive Scalar reference UI
open http://127.0.0.1:3100/reference

Every MCP tool has a corresponding REST endpoint — useful if you're debugging what Claude is actually calling, or building your own integration alongside the MCP server.

What's Next

If you're already using Claude Desktop and want to go further, the next step is setting up incoming transaction monitoring so your agent gets notified of deposits, and configuring WalletConnect so you can approve high-value transactions from your phone. The full 45-tool MCP reference and all policy types are documented in the WAIaaS repo.