SwapChan

Pre-signing check of a contract call (unsigned, nothing sent)

contract_approve_call

Read-onlyIdempotent

Pre-signing verdict for one EVM contract call: builds the calldata, re-encodes it with the full ABI and exact signature, builds an unsigned tx (placeholder nonce and gas; the wallet sets the real ones), approves the calldata against the ABI (blocktools evmApproveCall: ok, unknown_selector or bad_calldata) and checks the unsigned tx with blocktools verifyTx. verifyTx refuses by default an approval of 2^128 or more, unasserted inner calls (multicall, Safe) and delegatecall; optional expect_spender, expect_amount, expect_unlimited, expect_recipient, expect_value, allow_inner_call and allow_delegatecall state what the user intends (failures such as spender_not_expected, amount_not_expected, recipient_not_expected, value_not_expected). Returns verdict pass or fail with reasons, the data, target and value, verifyTx's CHECK THESE text and its approvals, transfers and inner_calls. Show the verdict before the user signs; do not send on fail. SwapChan never signs, sends or broadcasts. Powered by blocktools (ABI coding). 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>",
      "address": "<address>",
      "function": "<function>"
    },
    "name": "contract_approve_call"
  }
}

Input Schema

Name	Required	Description
`abi`	No	Optional ABI JSON to use instead of the Sourcify / Etherscan lookup (labelled as pasted; not checked against source).
`args`	No	Arguments in order; arrays/tuples as JSON lists, big numbers as decimal strings.
`value`	No	Wei to send (payable functions only)
`address`	Yes	Contract address (0x...)
`chainId`	Yes	EVM chain id or name (1 eth, 8453 base, 42161 arbitrum, 10 optimism, 137 polygon, 56 bnb, 43114 avalanche, 59144 linea, 534352 scroll).
`function`	Yes	Function name, or the full signature for overloads, e.g. "balanceOf" or "get(uint256)"
`expect_value`	No	Exact native value in wei; else value_not_expected
`expect_amount`	No	Exact approval or transfer amount (base units); else amount_not_expected
`expect_spender`	No	Spender any approval must name; else spender_not_expected
`allow_inner_call`	No	Inner calls allowed inside multicall / Safe, as "TO:SELECTOR"; else inner_calls_not_asserted
`expect_recipient`	No	Recipient any token transfer must pay; else recipient_not_expected
`expect_unlimited`	No	Allow an unlimited approval to expect_spender (needs expect_spender; not with expect_amount)
`allow_delegatecall`	No	Targets a Safe delegatecall may reach; else delegatecall

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 2, 2026

addedInput schema / properties / allow_delegatecall

Added value: +{
+  "description": "Targets a Safe delegatecall may reach; else delegatecall",
+  "items": {
+    "description": "Contract address (0x...)",
+    "pattern": "^0x[0-9a-fA-F]{40}$",
+    "type": "string"
+  },
+  "maxItems": 64,
+  "type": "array"
+}

addedInput schema / properties / allow_inner_call

Added value: +{
+  "description": "Inner calls allowed inside multicall / Safe, as \"TO:SELECTOR\"; else inner_calls_not_asserted",
+  "items": {
+    "pattern": "^0x[0-9a-fA-F]{40}:0x[0-9a-fA-F]{8}$",
+    "type": "string"
+  },
+  "maxItems": 64,
+  "type": "array"
+}

addedInput schema / properties / expect_amount

Added value: +{
+  "description": "Exact approval or transfer amount (base units); else amount_not_expected",
+  "pattern": "^\\d{1,78}$",
+  "type": "string"
+}

addedInput schema / properties / expect_recipient

Added value: +{
+  "description": "Recipient any token transfer must pay; else recipient_not_expected",
+  "pattern": "^0x[0-9a-fA-F]{40}$",
+  "type": "string"
+}

addedInput schema / properties / expect_spender

Added value: +{
+  "description": "Spender any approval must name; else spender_not_expected",
+  "pattern": "^0x[0-9a-fA-F]{40}$",
+  "type": "string"
+}

addedInput schema / properties / expect_unlimited

Added value: +{
+  "description": "Allow an unlimited approval to expect_spender (needs expect_spender; not with expect_amount)",
+  "type": "boolean"
+}

addedInput schema / properties / expect_value

Added value: +{
+  "description": "Exact native value in wei; else value_not_expected",
+  "pattern": "^\\d{1,78}$",
+  "type": "string"
+}

AddedOct 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: it explains that nonce and gas are placeholders, that verifyTx refuses approvals of 2^128 or more by default, and that unasserted inner calls and delegatecall are rejected unless explicitly allowed. It also describes the expectation parameters and their failure modes (e.g., spender_not_expected) and confirms no signing or broadcasting occurs, which aligns with the readOnlyHint annotation.

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?

The description is front-loaded with the core purpose and is appropriately dense given the tool's complexity and 13 parameters. It avoids filler, though the single-paragraph structure and long inventory of failure names make it harder to scan than a shorter or more structured description would be. The length is largely earned by the need to disclose multiple safety behaviors.

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 pre-signing verification tool with no output schema, the description is thorough: it explains inputs, the unsigned tx behavior, default refusal conditions, expectation checks, failure outcomes, and the shape of the return value. An agent has enough information to call the tool correctly and interpret pass/fail results without needing additional documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents every parameter. The description still adds meaningful semantics by explaining the intent of expect_spender, expect_amount, expect_unlimited, expect_recipient, expect_value, allow_inner_call, and allow_delegatecall, and by naming the corresponding failure reasons. It does not add detail for the core abi/args/value/function parameters, but those are already well covered by 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 description states a specific verb and resource: a pre-signing verdict for one EVM contract call. It details the internal flow (calldata build, ABI re-encode, unsigned tx build, evmApproveCall, verifyTx) and clearly distinguishes this tool from signing/broadcasting tools by stating that SwapChan never signs, sends, or broadcasts. The title reinforces the scope.

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?

The description gives clear operational guidance: show the verdict before the user signs and do not send on fail. It also points to swapchan_playbook for workflow combinations. However, it does not explicitly contrast with sibling tools like contract_encode_call, verify_tx, or simulate_swap, leaving the agent to infer when this specific pre-signing check is preferred over those alternatives.

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.