SwapChan

Verify an unsigned transaction before signing

verify_tx

Read-only

Run SwapChan's calldata guard + simulation on any unsigned tx and return a verdict (ok / caution / danger), findings, balance-diff simulation and a plain-language summary for human sign-off. Covers unlimited approvals, approvals to a spender other than expected.spender, including inside multicall and Safe batches (an exact-balance approval to a drainer is still danger when you name the spender), Permit2, setApprovalForAll, Safe DELEGATECALL, proxy upgrades, EIP-7702, ownership transfers, address poisoning lookalikes, minOut vs quote, Solana program allowlist + simulateTransaction, Tron AccountPermissionUpdate. Always show the summary to the human and get an explicit yes for THIS tx before their wallet signs. Trustless: read-only, never signs. Result includes display markdown with chan images: show it to the user. How to combine this with the other tools: swapchan_playbook (workflows: find-money, best-swap, rebalance, revoke-approvals, bridge-stuck, token-safety, recover-old-wallet).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "chainId": "<chainId>",
      "tx": "<tx>"
    },
    "name": "verify_tx"
  }
}

Input Schema

Name	Required	Description
`tx`	Yes	EVM {from,to,data,value}, Solana base64 tx, or Tron tx JSON
`chainId`	Yes	Chain id (1, 8453, 42161, 10, 137, 56, 43114, 59144, 534352, 792703809 Solana, 8253038 Bitcoin, 728126428 Tron) or name (eth, base, arbitrum, optimism, polygon, bnb, avalanche, linea, scroll, solana, bitcoin, tron).
`expected`	No	expected.recipient and expected.minOut are checked against the simulated outcome (pass tx.from); if they cannot be checked, the verdict is danger.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 3, 2026

addedInput schema / properties / expected / properties / amount

Added value: +{
+  "description": "EVM only, needs spender: exact approval amount in base units (amount-not-expected on mismatch)",
+  "type": "string"
+}

addedInput schema / properties / expected / properties / spender

Added value: +{
+  "description": "EVM only: the spender you intend to approve. Any approval (approve, increaseAllowance, permit, Permit2, setApprovalForAll) naming another address is danger (spender-not-expected); approvals inside multicall, Safe execTransaction and Safe MultiSend batches are decoded (nested up to 4 deep) and checked the same way; a batch that does not decode, a DELEGATECALL other than into a known Safe MultiSend, or deeper nesting is danger (spender-unchecked).",
+  "type": "string"
+}

Changed2 schema fields changedOct 25, 2026

addedInput schema / properties / expected / description

Added value: +"expected.recipient and expected.minOut are checked against the simulated outcome (pass tx.from); if they cannot be checked, the verdict is danger."

addedInput schema / properties / expected / properties / outToken

Added value: +{
+  "description": "Token whose simulated receipt must be >= minOut (default: largest receipt)",
+  "type": "string"
+}

AddedOct 24, 2026

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond readOnlyHint/openWorldHint it discloses fail-closed semantics ('if they cannot be checked, the verdict is danger'), the meaning of each verdict tier, that approvals in multicall/Safe batches are decoded up to 4 deep, and that deeper nesting or unknown DELEGATECALL is danger. It adds operational context the annotations cannot carry: never signs, and the human sign-off requirement. 'Trustless: read-only, never signs' is consistent with readOnlyHint.

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 and the human-sign-off instruction are front-loaded, which is good. However the middle of the description is one very long run-on enumeration of threat classes (Permit2, EIP-7702, address poisoning, Solana allowlist, Tron AccountPermissionUpdate) that is dense to parse. The closing pointer to swapchan_playbook reads as cross-promotion rather than essential guidance.

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 security-verification tool with no output schema, the description explains what is returned (verdict, findings, balance-diff simulation, plain-language summary, and a display markdown with images), that it is read-only, and how failure paths resolve. An agent has enough to call it and act on the result.

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 parameter descriptions are unusually detailed, including the expected.spender danger rules and 'pass tx.from'. The prose does reinforce a few semantic points (expected.spender mismatch, minOut vs quote, unlimited approvals), but it largely restates what the schema already states, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: run a calldata guard plus simulation on an unsigned tx and return a verdict, findings, balance diff and summary. It clearly scopes to pre-signing verification against any unsigned tx. It stops short of naming the sibling to prefer instead (e.g. simulate_swap, broadcast_tx, explain_transaction), so an agent must infer the boundary from the coverage list.

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 usage direction: 'Always show the summary to the human and get an explicit yes for THIS tx before their wallet signs', plus a pointer to swapchan_playbook for workflows. That establishes when to call it. It does not state when NOT to use it or which sibling handles already-signed broadcasts or plain exploratory simulation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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