Reclaim overpaid rent from Solana token accounts (SIMD-0437). Non-custodial, no API key.
Scored across 4 tools
Each tool occupies a distinct stage of the workflow: scan_wallet is read-only analysis, build_reclaim produces unsigned transactions, submit_reclaim broadcasts signed ones, and get_rent_status reports protocol-wide SIMD-0437 state. The descriptions make the boundaries explicit, including that build_reclaim re-scans but does not send, which prevents confusion with scan_wallet or submit_reclaim.
All four names follow a clean snake_case verb_noun pattern (scan_wallet, build_reclaim, submit_reclaim, get_rent_status). Verbs are meaningful and map to the action performed.
Four tools is a tight, well-scoped set that maps exactly onto the scan → build → sign/submit pipeline plus a protocol status check. No tool is redundant or missing for the stated purpose.
The core lifecycle is fully covered — status, scan, build, submit — including fee handling, burn options, and a browser signUrl fallback. The only minor gap is there is no tool to re-check the settlement of an already-submitted claim later, though submit_reclaim returns signatures and per-transaction status.
Re-scans the wallet on the chain and builds the reclaim as unsigned, simulated Solana transactions (base64, versioned). They withdraw excess rent, close empty accounts and pay the service fee as the last instruction; nothing else leaves the wallet. Tokens are only burned for accounts listed in burn. The wallet's owner signs every transaction unchanged (the fee payer is the wallet, compute budget instructions may be added) and passes them to submit_reclaim within about 30 seconds, before the blockhash expires. Do not send them yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Optional UNRENT referral code. The referrer gets a share of the service fee; the wallet pays the same. | |
| burn | No | Token accounts to burn and close (from the scan's burn.candidates). Only when the wallet owner explicitly asked for it. | |
| wallet | Yes | Solana wallet address (base58). | |
| accounts | No | Only these account addresses (from a scan). Default: everything reclaimable. | |
| burnMaxUsd | No | Highest USD value per account that may be burned (capped by burn.cleanupMaxUsd). Dust is burned regardless. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only covering safety flags, the description adds substantial behavioral context: transactions are unsigned and simulated, they withdraw rent/close accounts/pay fee last, nothing else leaves the wallet, tokens are burned only for `burn` accounts, the owner must sign unchanged, and a ~30s expiry window applies. This tells the agent exactly what will change and what constraints to respect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and output format, then proceeds through what the transactions do, the burn constraint, and the signing/timing requirement. Every sentence carries operational information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description fully specifies the return artifact (base64 versioned unsigned transactions) and the required next step. Nothing an agent needs to invoke and correctly handle the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema carries the parameter details (baseline 3). The description adds value by clarifying the `burn` safety semantics ('Tokens are only burned for accounts listed in `burn`'), reinforcing the schema's intent rather than merely restating it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Re-scans the wallet... builds the reclaim') and names the exact output artifact: unsigned, simulated, base64 versioned Solana transactions. It is clearly distinguishable from scan_wallet (read) and submit_reclaim (sends), so an agent knows precisely what this produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent to submit_reclaim within ~30 seconds before blockhash expiry, and adds a hard exclusion: 'Do not send them yourself.' It does not explicitly say when to prefer this over scan_wallet, but the build-vs-scan distinction is implicit in 'Re-scans... and builds.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where Solana's rent reduction (SIMD-0437) stands: the live lamports_per_byte, which of the five steps are live, when the next is expected, and whether a step is already queued on chain (it then activates at the next epoch boundary). Older accounts keep their higher deposit until it is withdrawn; each step makes more SOL reclaimable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and open-world behavior. The description adds meaningful domain context: a queued step activates at the next epoch boundary, and older accounts keep their higher deposit until withdrawal. It could mention refresh or rate semantics, but it adds solid behavioral value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the status scope and then adds one operational caveat. Every clause carries useful information, with no filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must convey the return content itself. It lists the live lamports_per_byte, which steps are live, the next expected step, queued status, and activation timing, which is complete for a zero-parameter status read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no input parameters, so there are no parameter semantics for the description to clarify. The zero-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific resource and state, 'Where Solana's rent reduction (SIMD-0437) stands,' and enumerates the exact status fields returned. It does not name sibling tools, but the informational framing distinguishes it from the build/scan/submit reclaim actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no sibling routing is stated. The note that each step makes more SOL reclaimable hints at using this before a reclaim action, but the agent must infer that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the token accounts and mints of a Solana wallet and returns the SOL that can be reclaimed now: excess rent (WithdrawExcessLamports, accounts stay open), empty token accounts (CloseAccount) and mint excess, the UNRENT service fee, the net amount, a forecast for the remaining rent steps, and tokens that may optionally be burned and closed (dust). Read-only, needs no signature. Amounts are in SOL. Also returns signUrl: a link to finish the reclaim on unrent.xyz with a browser wallet (Phantom, Solflare, Backpack…), for when you cannot sign for the wallet yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Optional UNRENT referral code. The referrer gets a share of the service fee; the wallet pays the same. | |
| wallet | Yes | Solana wallet address (base58). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint/idempotentHint/openWorldHint, but the description adds real context beyond them: no signature required, amounts denominated in SOL, the WithdrawExcessLamports vs CloseAccount distinction, and the external signUrl fallback with named wallets. This meaningfully informs behavior for a mutation-adjacent workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first clause, and the long enumeration of return fields is dense with distinct information rather than filler. It is a single long sentence plus a fallback sentence, which is slightly heavy but every clause carries weight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing return values, and it does so comprehensively (excess rent, empty accounts, mint excess, fee, net, forecast, dust, signUrl). Safety and signature requirements are also covered. Only the relationship to the sibling build/submit tools is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (wallet, ref). The description adds only the SOL unit convention and does not explain the referral code semantics shown in the schema, so it neither compensates nor detracts. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states a specific verb and resource: it reads a Solana wallet's token accounts and mints and returns reclaimable SOL. It elaborates exactly what is returned (excess rent, empty accounts, mint excess, service fee, net, forecast, dust), which is unusually precise. It does not, however, explicitly differentiate itself from siblings like get_rent_status or build_reclaim, so an agent must infer the read-vs-build-vs-submit split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: it is a read-only scan that returns a signUrl for when 'you cannot sign for the wallet yourself,' which hints at a browser fallback flow. But there is no explicit guidance on when to prefer this over get_rent_status, or that this is the discovery step preceding build_reclaim/submit_reclaim, so the agent must infer the ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks the signed transactions against the ones build_reclaim made (same instructions, same fee, signed by the wallet) and sends them to Solana. Returns the signature and status of every transaction. A claim can be submitted once; after an expired blockhash, build again.
| Name | Required | Description | Default |
|---|---|---|---|
| signed | Yes | The signed transactions, base64, in the order the build returned them. | |
| claimId | Yes | claimId from the build. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true; the description adds real context on top, confirming the once-only submission semantics, the blockhash expiry failure mode, and that the return payload contains signature and status per transaction. It does not spell out irreversibility or fee/auth requirements, but the annotation contradiction is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what it does, what it returns, and the one-shot/expiry caveat is front-loaded first. No filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 return burden — and it does, stating the signature and status of every transaction. Combined with the validation contract against build_reclaim and the expiry caveat, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; however the description adds semantic constraints the schema does not carry — that the signed array must match build_reclaim's instructions and fee and be signed by the wallet, and that ordering matters ('in the order the build returned them'). That is genuine meaning beyond the field types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (checks then sends) and resource (signed reclaim transactions to Solana), and explicitly ties itself to the sibling build_reclaim whose output it validates against. An agent can distinguish it from build_reclaim without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the operative constraint ('A claim can be submitted once') and the recovery path ('after an expired blockhash, build again'), which implicitly routes back to build_reclaim. It does not name explicit when-not-to-use conditions beyond the single-submission rule, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
build_reclaimget_rent_statusscan_walletsubmit_reclaimBatch send SOL or any SPL token to 1000+ wallets via x402. AI agent payments on Solana.
Read-only tools for agents: everything a Solana or Robinhood Chain wallet can get back (rent, wrapped SOL, LP fees, dead positions, failed deploys), whether a token is safe, when it unlocks, which protocol upgrades are live, and what a token operation costs. Every answer names the page where the user acts with their own wallet. Nothing here moves funds or holds keys.
Run all your Solana wallets from your AI: send, swap, split, consolidate and clean up.
Paid Solana token safety checks over Streamable HTTP MCP (x402 USDC on Solana + Base).
Add one secure layer between your agents and this server.
