Skip to main content
Glama

Find me money (wallet opportunities)

find_money
Read-only

HEADLINE TOOL. "Give me your wallet address and I'll find you money." Scans one wallet (address, ENS, Basename or SNS) and returns RANKED actions with estimated $ values: unclaimed rewards (Merkl), forgotten money in old contracts (PoWH3D/P3D dividends, Fomo3D vaults, EtherDelta balances, Liquity surplus collateral, and ETH left in 170 confirmed LegacyETH registry contracts (27 EtherDelta-style DEXes, Ethen (balances + withdrawEther), 17 Fomo3D forks, 49 PoWH3D/Hourglass clones (dividends via withdraw()), 8 old ETH wrappers (old WETH, Maker WETH, WETH10, Neufund EtherTokens, Bancor, Celer, Veil), 2 Ethfinex WrapperLockEth (balanceOf + withdraw), 5 NFT-market pull payments, 38 ICO/presale refunds, 4 burn-token redemptions: DigixDAO, Delphi, Quantfury, Aave v1 aETH, and 19 claims with no amount view (HONG refund, presale pools, Foreground, DigiPulse, dividend clones) whose amount comes from a simulated claim at the pinned block), each with an unsigned, allowlist-verified claim tx (two-step redemptions build the exact-amount approval first, then the claim); other listed legacy contracts are reported as not checked yet), lending positions and accrued rewards (Aave v2/v3, Compound v2/v3, Venus) with at-risk health factors, idle stablecoins that could earn yield, dust to consolidate (batch swap link), high-risk tokens to exit, risky approvals to revoke (revokeTx), cheaper-gas windows, Tron voting rewards/expired unfreezes and Solana rent locked in empty token accounts, plus vault shares (ERC-4626/Yearn redeem), uncollected Uniswap v3 fees, unwrapped WETH/WBNB/WPOL/WAVAX, finalized Lido withdrawals, Safes you own, and deactivated Solana stake accounts. Coverage: Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, Linea and Scroll; 12 more EVM chains (zkSync, Gnosis, Mantle, Celo, Blast, Berachain, Sonic, Unichain, Fantom, Monad, Katana and HyperEVM: native, listed tokens, known-spender approvals); ETH forks ETC and ETHW; Solana; Tron; Bitcoin; Bitcoin forks and same-key coins BCH, BTG, LTC, DOGE and FTC; old coins DASH, DGB, RVN, VTC, VIA, QTUM, MONA, BSV, GRS, PPC, NVC, CLAM, RDD, BLK, Zcash transparent (t1), TRC, AUR, XPM and QRK, plus balances for NMC, POT, MEC and ANC; and balances on XRP, XLM, ALGO, ATOM (Cosmos Hub), DOT, TON, ADA and Signum. For Bitcoin-family coins it builds an unsigned sweep to an address you choose, which you sign offline in the coin's own wallet; old-coin sweeps are offered only after a Rust transaction library compiled to WebAssembly has built and verified them and an independent second decode agrees. Monero addresses are recognised but not checked. Liquidity/Pendle exits carry live-quoted minimum outputs and a 20-minute deadline, plus a note to submit through a private RPC. Every item has a prefilled swapUrl and an unguessable shortUrl, and recoverable items carry 'steps': step 1 a permanent swapchan.com/recover page where the user signs the decoded, allowlist-verified recovery tx in their own wallet, step 2 a swap to USDC. 'swapAll' is one batch link for everything. Always show the steps in order. Agent-first: each recoverable item carries a machine-readable 'recovery' package so you can verify and act on your own without our UI: contract (chain, address, explorer, verified-source link), detection evidence (each read call, args, block, raw return), interface (ABI fragments for the reads and the recovery function), value (estUsd + pricing source), recoveryTx (exact unsigned to/data/value, verified to pay only the owner) and swapUrl. Re-run the reads yourself to check. Trustless: SwapChan never signs, never holds keys or funds, and cannot move money; it only builds unsigned transactions the user's own wallet signs. Free: SwapChan earns only its small swap fee if the user swaps there. Estimates are labeled (exact / estimate / protected): never present 'protected' value or APY estimates as guaranteed money. Known burn/dead addresses (0x…dEaD, the zero address, the Solana incinerator, the Tron black hole, the Bitcoin eater address) return no items, totalEstUsd 0 and burnAddress:true, because nothing sent there can be recovered. Example prompt: "Here's my wallet 0x…, find me money." Result includes display markdown with chan images: show it to the user. Each claim step carries 'call' (contract, contractExplorerUrl, function, signature, 4-byte selector, decoded args, plain): show it to the user before they sign. Results are cached for 3 minutes: every result carries asOf (ISO time the scan started; a cached result keeps its original time), block (Ethereum block number at scan start, EVM addresses only, else null) and cached (true when served from cache). Pass fresh=true to re-scan now; it is limited to once per 20 s per address and 3 per minute per client (plus a small global cap); a second fresh request while a fresh scan for that address is still running gets that scan result, and when limited you get the cached result with freshRefused:"rate-limited" and retryAfterSeconds. When partial is true (incompleteSources = how many sources timed out or could not be fully read, listed in notChecked), the totals are a lower bound: tell the user and re-run with fresh=true in about 20 s. 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": {
      "address": "<address>"
    },
    "name": "find_money"
  }
}

Input Schema

NameRequiredDescriptionDefault
freshNoSkip the 3-minute cache and re-scan this address now. Rate-limited (once per 20 s per address, 3 per minute per client); when limited the cached result comes back with freshRefused and retryAfterSeconds.
addressYesWallet address (EVM 0x…, Solana, Tron T…) or a name (vitalik.eth, jesse.base.eth, toly.sol)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / fresh
      Added value: +{
      +  "description": "Skip the 3-minute cache and re-scan this address now. Rate-limited (once per 20 s per address, 3 per minute per client); when limited the cached result comes back with freshRefused and retryAfterSeconds.",
      +  "type": "boolean"
      +}
  2. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations already cover readOnly and openWorld, and the description adds substantial behavioral detail: 3-minute caching, fresh rate limits, freshRefused/retryAfterSeconds, partial results as a lower bound, burn addresses returning no items, and that SwapChan never signs or holds funds.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a massive wall of text with exhaustive contract lists, chain coverage enumerations, and repeated operational details. The purpose is front-loaded, but many sentences are far beyond what an agent needs to select and invoke the tool.

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?

There is no output schema, so the description carries the full return-value burden. It explains ranked items, recovery packages, display markdown, call details, asOf/block/cached fields, partial results, and operational constraints, making it complete for this complex scan.

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 address and fresh are already documented. The description expands on accepted address formats and fresh-scan rate-limiting, but most of that overlaps with the schema descriptions rather than adding new parameter semantics.

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?

States a specific verb and resource: 'Scans one wallet' and returns 'RANKED actions with estimated $ values' for recoverable money. The single-wallet scope implicitly distinguishes it from batch siblings, but it does not explicitly name find_money_batch or find_money_status.

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?

Gives an example prompt, says to show 'steps' in order, show the 'display' markdown and 'call' details, and re-run with fresh=true when partial. It points to swapchan_playbook for workflows but does not explicitly state when to use this versus named alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.