Loading ToolBench
Agent wallet with fail-closed transaction guards: spend policy, artifact verification, delegated-execution guardrails. Agents propose; deterministic code verifies; only the user signs.
Pantessa Yeetful exposes 18 tools with generally clear naming (verb_noun pattern) and detailed descriptions (avg 180+ chars). However, critical gaps emerge: input schemas are inferred from descriptions rather than explicitly visible in source; parameter type definitions are sparse or missing; output schemas are undocumented; error handling lacks recovery guidance. Tools like plan_funding and fund_and_build have rich descriptions but no visible JSON Schema validation. The thinking-tools (1 - 8) lack explicit schema registration. Wallet tools (14 - 18) have better parameter documentation but still omit output structure. No evidence of permission gates, audit trails, or secret injection patterns despite handling sensitive operations (spend policy, transaction signing).
The chains this planner scans as sources and plans onto as destinations, with per-chain destination gas floors. Robinhood Chain funding rides the robinhood MCP's LiFi plan instead. Free, instant.
The ETH/USD price the planner sizes gas legs with — one Uniswap v3 QuoterV2 staticcall on Base, no oracle, no key. Use to sanity-check a plan's dollar figures.
The ONE-CALL composite for agents that can sign but can't orchestrate: scan + plan + an executable RUNBOOK in a single response. Call when an action refused on insufficient funds and you want the exact ordered tool calls, not just a plan. Returns everything plan_funding returns PLUS `runbook.steps` — numbered steps naming the NEAR Intents MCP tool for each leg (build_swap with verbatim params → submit_deposit_tx → await_completion) and ending with the follow-up action. Execute the steps in order, signing each deposit transfer with the user's own wallet; deposit addresses come from build_swap's responses, NEVER invented. Construction-only.
Just the NATIVE token balance on every covered chain in one call — "do I have gas on Arbitrum?" before building a transaction there. Faster than a full portfolio when only gas matters.
THE answer when any build/action refuses on insufficient funds ("needs 20 USDC on Arbitrum but the wallet holds 3"): turn the shortfall into an executable cross-chain funding plan instead of a dead end. Input = destination chain, the token that must land there, and the SHORTFALL (needed minus held — not the full ask). Returns ranked options of ordered legs; a native-ETH gas leg is prepended automatically when the destination wallet can't pay for the follow-up action. Execute each leg IN ORDER via the NEAR Intents MCP's build_swap with these exact params and the user's own address, wait for settlement, then retry the original action — NEVER invent routes, amounts, or deposit addresses. Construction-only.
Input schemas not explicitly visible in source code. Tool definitions inferred from descriptions rather than registered with JSON Schema. Cannot verify parameter types, constraints, or validation rules.
Output schemas completely undocumented. No visible return type definitions for any tool. LLMs cannot predict response structure or plan downstream tool calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
THE answer to "show my portfolio / what do I hold / balances on X and Y": every native + ERC-20 holding across the covered chains in ONE call, live, USD-priced, spam filtered, sorted richest-first with per-chain subtotals. ALWAYS call fresh after a transaction settles — balances change the moment a tx lands. The chat renders the result as a rich card (owner:"$USER_ADDRESS").
A wallet's most recent sent + received transfers (external + ERC-20) across the covered chains, merged newest-first with explorer links; spoofed scam-token symbols are flagged. Answers "what did I do recently?" and finds a deposit/delivery transaction after a swap.
Where a wallet's movable money sits: ETH + USDC across Base/Arbitrum/Ethereum in one call, gas-reserve aware (ETH counts only above what its own transfer costs; USDC only where the wallet also holds gas to sign). Call when an action failed on balance and you want to see what could fund it — then plan_funding turns it into an executable plan. failedChains means UNKNOWN, never empty.
One token's live balance for a wallet on one chain — the precise post-transaction check ("did the USDC arrive on Arbitrum?"). token = the 0x contract address, or "native" for the gas token. Unknown contract address → use portfolio instead.
One transaction's live status by hash: CONFIRMED (with confirmation count), REVERTED (no state changed), or still pending — plus the explorer link. Call right after the user signs something, then re-read balances with portfolio to show fresh numbers.
Which tool on the picked MCP, with which arguments. The planner proposes; deterministic code builds the request and refuses ambiguity.
Checks every transaction before it reaches your wallet: recipient, min-out, balance, allowance, validity. Signables break the loop — nothing auto-executes.
Who writes the answer when no paid inference is in scope — the house model, at $0, over fresh tool results.
Allow or deny every spend against your grant — allowlist, per-call, per-day, lifetime caps. One gate, every path; denials are ledgered, not swallowed.
Turns a DAO name into its governance space — "Nate DAO" → nategeier.dcl.eth. One match continues silently; several become a question.
Turns a token symbol into its canonical Base address — merged official Uniswap + Coingecko lists, no guessed addresses ever.
Which MCP answers this message — shortlist the catalog, rank by keyword + vector + reputation, pick.
Where a swap executes — CoW by default (solver-routed, MEV-protected), Uniswap when you name it.
No error handling guidance. Tools lack recovery instructions, error categorization (retryable vs fatal), or actionable error messages. Agents cannot self-correct on failures.
Sensitive operations (spend policy, transaction signing, fund transfers) lack permission gates, audit trails, and confirmation patterns. No evidence of least-privilege access control or logging.
Parameter descriptions lack format constraints, ranges, and validation rules. E.g., 'chain' accepts 'name or EVM chainId' but no enum or pattern specified; 'amount' is numeric but no min/max bounds.