What can you do with this server?

The SOL Claimer MCP Server integrates AI applications with the SOL Claimer API to analyze Solana wallets and recover locked SOL rent from unused or low-value token accounts. * analyze_empty_accounts: Scan a Solana wallet to find empty token accounts that can be closed, returning the count of eligible accounts and total recoverable SOL. * analyze_burnable_accounts: Identify token accounts with balances worth less than $1 USD that can be burned and closed, with details on token name, symbol, USD value, and recoverable SOL. * analyze_swappable_accounts: Locate token accounts with non-zero balances that can be swapped and subsequently closed to recover SOL. * get_how_it_works: Retrieve documentation about SOL Claimer's features and how rent recovery works.

Which integrations are available for this server?

Enables the analysis of Solana wallet addresses to identify empty or low-value token accounts, providing calculations for potential SOL rent recovery through closing or burning those accounts via the SOL Claimer API.

How do I use SOL Claimer MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SOL Claimer MCP Server Check 7cvkjYAkUYs4W8XcXsca7cBrEGFeSUjeZmKoNBvEwyri for empty accounts to recover SOL rent" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

SOL Claimer MCP Server

by solclaimer

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

SOL Claimer MCP Server

npm version License: MIT Node.js Version

A Model Context Protocol (MCP) server that provides seamless integration between LLM applications (ChatGPT, Claude, etc.) and the SOL Claimer API. This server enables AI assistants to analyze Solana token accounts and help users recover rent from empty and low-value token accounts.

Features

✅ Four Powerful Tools:
1. analyze_empty_accounts - Find and recover rent from empty token accounts
2. analyze_burnable_accounts - Identify low-value tokens (<$1) to burn and close
3. analyze_swappable_accounts - Find tokens with amount > 0 that can be swapped and closed
4. get_how_it_works - Learn about SOL Claimer functionality

Related MCP server: Unclaimed SOL Scanner

SOL Claimer Features (Page Copy)

SOL Claimer is a Solana SPL token manager focused on cleaning token accounts and recovering locked rent.

Claim Rent Fee - Close empty token accounts and reclaim SOL rent back to your wallet.
Create SPL / SPL22 Tokens - Launch standard or Token-2022 assets.
Mint New Coins - Mint additional supply for your token when needed.
Bulk Send Tokens - Send tokens to many wallets in one flow.
Burn Scam / Worthless Coins - Remove unwanted low-value tokens and recover account rent.
Swap Tiny Amounts and Get Rent Fee - Convert dust balances and close token accounts to unlock SOL.

How rent claiming works

On Solana, token accounts hold a rent-exempt SOL reserve. When an account is no longer needed, closing it returns that SOL to your wallet. SOL Claimer helps you find eligible accounts (empty or low-value), then guides you to burn/clear balances and close accounts so you can recover the rent safely.

🔄 Real-time API Integration - Direct connection to SOL Claimer API
🛡️ Error Handling - Graceful error management and user-friendly messages
📊 Rich Response Formatting - Detailed, readable analysis results

Prerequisites

Node.js 18+ (tested on v20+)
npm 10+
SOL Claimer API accessible at https://api.solclaimer.app
Environment variable SOLCLAIMER_API_URL (optional, defaults to https://api.solclaimer.app)

Installation

Option 1: Install from npm (Recommended)

# Install globally
npm install -g @solclaimer/mcp

# Or install locally in your project
npm install @solclaimer/mcp

Option 2: Install from source

# Clone the repository
git clone https://github.com/solclaimer/mcp.git
cd mcp

# Install dependencies
npm install

# Build the project
npm run build

# Start the server
npm start

Configuration

Environment Variables

Optionally set the SOL Claimer API URL:

export SOLCLAIMER_API_URL=https://api.solclaimer.app

If not set, defaults to https://api.solclaimer.app.

Development

# Watch TypeScript changes and run
npm run dev

# Format code
npm run format

# Lint code
npm run lint

Tools

1. analyze_empty_accounts

Analyzes a Solana wallet for empty token accounts that can be closed to recover rent.

Parameters:

wallet_address (string, required): The Solana wallet address to analyze

Response:

accountsToClose - Number of empty accounts found
totalSol - Total SOL available for recovery

2. analyze_burnable_accounts

Analyzes a wallet for token accounts with balances worth less than $1 USD that can be burned and closed.

Parameters:

wallet_address (string, required): The Solana wallet address to analyze

Response:

accountsToBurn - Number of burnable accounts found
totalSol - Total SOL available for recovery
totalUsdValue - Combined USD value of all burnable tokens
accountDetails - Array of detailed account information including:
- Token name and symbol
- Amount and USD value
- Rent (in lamports)
- Contract verification status

3. analyze_swappable_accounts

Analyzes a wallet for token accounts with amount > 0 that can be swapped and then closed.

Parameters:

wallet_address (string, required): The Solana wallet address to analyze

Response:

accountsToSwap - Number of swappable accounts found
totalSol - Total SOL available for recovery after swap and close
totalUsdValue - Combined USD value of all swappable tokens
accountDetails - Array of detailed account information including token name and symbol

4. get_how_it_works

Returns documentation about SOL Claimer features and capabilities.

Parameters: None

Response:

Information about SOL Claimer features
Description of how it works
Website link

Example Usage with Claude

User: "Can you analyze my Solana wallet at 7cvkjYAkUYs4W8XcXsca7cBrEGFeSUjeZmKoNBvEwyri?"

Claude: [Uses analyze_empty_accounts, analyze_burnable_accounts, and analyze_swappable_accounts tools]
"Based on the analysis, I found:
- 5 empty token accounts: 0.0101964 SOL can be recovered
- 12 burnable accounts: 0.0244713 SOL can be recovered (worth $0.52)
..."

Integration with LLM Platforms

Claude (via claude.ai or Claude API)

Create a Claude project with this MCP server
Configure the MCP server in your Claude settings
Claude will automatically use the available tools when analyzing Solana wallets

ChatGPT / OpenAI

Set up a custom integration pointing to this MCP server
Configure as a tool/action in your OpenAI integration
Use natural language to analyze wallets

Generic MCP Client Integration

Any MCP-compatible client can connect to this server using:

{
  "mcpServers": {
    "solclaimer": {
      "command": "node",
      "args": ["/path/to/dist/index.js"],
      "env": {
        "SOLCLAIMER_API_URL": "https://api.solclaimer.app"
      }
    }
  }
}

Architecture

Project Structure

src/
├── index.ts          # Main MCP server implementation
tsconfig.json         # TypeScript configuration
package.json          # Dependencies and scripts

Key Components

SolClaimerApiClient - Handles communication with the SOL Claimer API
MCP Server - Exposes four tools via the Model Context Protocol
Response Formatters - Transform API responses into readable text

Troubleshooting

Connection refused error

Ensure SOL Claimer API is reachable at the configured SOLCLAIMER_API_URL
Default: https://api.solclaimer.app
Check firewall and port accessibility

Invalid wallet address

Verify the Solana wallet address format (44-character base58 string)
Examples: 7cvkjYAkUYs4W8XcXsca7cBrEGFeSUjeZmKoNBvEwyri

API timeout

Check network connectivity to the SOL Claimer API
Increase timeout if API is slow (edit timeout in SolClaimerApiClient)
Check if Solana RPC endpoint is accessible

Performance

Requests include 30-second timeout to prevent hanging
No caching at MCP layer (respects API caching)
Suitable for real-time analysis

License

UNLICENSED

Available Tools

4 tools

analyze_burnable_accountsA

Analyze a Solana wallet for token accounts with balances worth less than $1 USD that can be burned and closed. Returns detailed information about each burnable account including token name, symbol, and USD value.

ParametersJSON Schema

Name	Required	Description	Default
`wallet_address`	Yes	The Solana wallet address to analyze

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden. It clearly indicates the tool is read-only analysis (identifies burnable accounts without performing burn/close) and describes the output fields (token name, symbol, USD value). However, it could explicitly state that no destructive actions are taken.

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

Conciseness5/5

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

The description is two sentences, front-loading the core action and condition in the first sentence, and detailing return values in the second. No extraneous words or repetition. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should explain return values. It lists token name, symbol, and USD value. While sufficient for a simple analysis tool, it could benefit from mentioning additional fields like account address or mint, but overall covers the essential information.

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?

The input schema has 100% description coverage (1 parameter 'wallet_address' described as 'The Solana wallet address to analyze'). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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 clearly states the tool's purpose: analyzing a Solana wallet for token accounts worth less than $1 that can be burned and closed. It includes specific verb 'analyze' and resource 'Solana wallet', and distinguishes from siblings like analyze_empty_accounts and analyze_swappable_accounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide guidance on when to use this tool versus the sibling tools (analyze_empty_accounts, analyze_swappable_accounts). There is no mention of prerequisites or scenarios where this tool is preferred, leaving the agent without decision support.

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

analyze_empty_accountsA

Analyze a Solana wallet for empty token accounts that can be closed to recover rent. Returns the number of empty accounts and total SOL that can be recovered.

ParametersJSON Schema

Name	Required	Description	Default
`wallet_address`	Yes	The Solana wallet address to analyze (e.g., '7cvkjYAkUYs4W8XcXsca7cBrEGFeSUjeZmKoNBvEwyri')

TDQS

A4/5.0

Behavior4/5

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

No annotations are present, so the description carries full burden. It correctly conveys that the tool is read-only (only analyzes, does not close accounts) and returns specific metrics. However, it does not mention network usage or any prerequisites.

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

Conciseness5/5

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

Two focused sentences with no extraneous information. The purpose and return values are communicated efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description is nearly complete. It covers purpose, input, and output. Minor omission: it could explicitly state that no mutations occur, but that's implied.

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?

With 100% schema coverage and a clear parameter description, the description adds minimal extra meaning beyond the schema. It restates the wallet address context but does not elaborate on format or examples beyond what the schema provides.

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 clearly states the tool analyzes a wallet for empty token accounts to recover rent, and specifies the return values (count and SOL amount). It distinguishes from siblings like analyze_burnable_accounts by focusing on 'empty' accounts and 'recover rent'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when wanting to find closable empty accounts, but provides no explicit guidance on when to choose this tool over its siblings or alternatives.

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

analyze_swappable_accountsA

Analyze a Solana wallet for token accounts with amount > 0 that can be swapped and then closed. Returns detailed token information for each swappable account.

ParametersJSON Schema

Name	Required	Description	Default
`wallet_address`	Yes	The Solana wallet address to analyze

TDQS

A3.7/5.0

Behavior4/5

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

The description implies a read-only operation by using the verb 'analyze' and stating 'returns detailed token information'. It also clarifies the tool filters accounts with amount > 0 and that are swappable, providing behavioral context. However, it does not explicitly state that no mutations occur, and no annotations are provided to reinforce this.

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

Conciseness5/5

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

The description is concise, using two sentences that front-load the purpose. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema, the description only mentions 'returns detailed token information' without specifying the structure or fields. For a simple one-parameter tool, this is somewhat incomplete but still adequate for understanding the core function.

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 coverage is 100% with a single parameter that already has a description. The tool description does not add extra semantic meaning beyond what the schema provides, so baseline score is appropriate.

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 clearly states the verb 'analyze', the resource 'Solana wallet for token accounts', and the specific criteria (amount > 0, swappable). It also distinguishes itself from siblings like analyze_burnable_accounts and analyze_empty_accounts by specifying the type of accounts analyzed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, nor any context on prerequisites or exclusions. The description only states what it does without indicating appropriate usage scenarios.

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

get_how_it_worksA

Get information about SOL Claimer features and how it helps recover SOL from token accounts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description bears full burden. It correctly identifies the operation as informational (read-only), but lacks details on idempotency, auth needs, or rate limits. Acceptable for a simple tool.

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

Conciseness5/5

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

Single sentence, no wasted words. Front-loaded with the verb 'Get' and resource. Every word earns its place.

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?

Given zero parameters, no output schema, and low complexity, the description is complete. An agent can correctly invoke the tool based on this description alone.

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?

No parameters exist, so the description doesn't need to add parameter details. Schema coverage is 100% (empty), and the description is consistent.

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 clearly states it retrieves information about SOL Claimer features and recovery, using a specific verb and resource. It distinguishes itself from sibling tools that analyze accounts, though it could be more specific about the exact information returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use versus alternatives, but the context implies it's for obtaining feature overviews. Without explicit when-not or alternative references, it's adequate but not comprehensive.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updatev1.0.6May 3, 2026
- Addedanalyze_swappable_accounts
3 tool updatesv1.0.2Mar 8, 2026
- First observedanalyze_burnable_accounts
- First observedanalyze_empty_accounts
- First observedget_how_it_works

Deploy Server

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

TDQS

A4.1/5.0

Scored 2026-05-03 05:05 across 4 tools

Disambiguation5/5

Each tool targets a distinct category of Solana token accounts (burnable, empty, swappable) plus an informational tool, with no overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (analyze_*, get_*), making it predictable for agents.

Tool Count5/5

Four tools is well-scoped for the domain of analyzing token accounts for SOL recovery—each tool serves a clear, non-redundant purpose.

Completeness4/5

Covers the three main account categories for analysis, but lacks tools for performing actual claiming actions (burning, closing, swapping), which may be intentional but slightly limits completeness.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Related MCP Connectors

Solana MCP by Vybe A
io.github.vybenetwork
Solana MCP for wallets, trades, markets, PnL, transfers, onchain data, signable swaps and API tools.
Blockchain Cryptocurrency Web3 & Decentralized Tech
521,320
Blueprint Agentic Staking (Solentic)A
io.github.blueprint-infrastructure
Native Solana staking for AI agents. 26 MCP tools, one-shot signing, webhooks.
Blockchain Autonomous Agents Finance
292
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111
crypto-defi-mcpOAuth
com.thenextgennexus
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Cryptocurrency Finance Blockchain
2

Related MCP Servers

rug-check-mcp
Blockchain Cryptocurrency Security
kukapay
A
license
Not graded
quality
D
maintenance
An MCP server that detects potential risks in Solana meme tokens, helping AI agents avoid rug pulls and unsafe projects.
Updated a year ago (2025-05-06 08:52 UTC)
21
MIT
Unclaimed SOL Scanner
Blockchain Finance
unclaimed-sol
A
license
A
quality
B
maintenance
Scan and claim reclaimable SOL from dormant Solana wallet accounts. The first Vibe Claiming MCP server.
Updated a month ago (2026-08-27 22:19 UTC)
1
48 npm
5
MIT
Solafon MCP
Blockchain Communication Web3 & Decentralized Tech
Solafon
A
license
B
quality
D
maintenance
An MCP server for building AI-powered bots and interacting with Solana wallets on the Solafon platform. It enables users to manage messages, check token balances, and handle transactions through natural language in MCP-compatible AI tools.
Updated 7 months ago (2026-02-23 11:16 UTC)
17
5 npm
MIT
solana-mcp-server
Blockchain Finance Web3 & Decentralized Tech
AiAgentKarl
A
license
A
quality
D
maintenance
MCP server giving AI agents access to Solana blockchain data. 7 tools: wallet balances, transaction history, token prices (Jupiter + CoinGecko), token metadata, DeFi yields (Raydium + Orca), and token safety checks (RugCheck scores, holder concentration, insider detection).
Updated 6 months ago (2026-04-03 16:05 UTC)
8
1
MIT

SOL Claimer MCP Server

Features

SOL Claimer Features (Page Copy)

How rent claiming works

Prerequisites

Installation

Option 1: Install from npm (Recommended)

Option 2: Install from source

Configuration

Environment Variables

Development

Tools

1. analyze_empty_accounts

2. analyze_burnable_accounts

3. analyze_swappable_accounts

4. get_how_it_works

Example Usage with Claude

Integration with LLM Platforms

Claude (via claude.ai or Claude API)

ChatGPT / OpenAI

Generic MCP Client Integration

Architecture

Project Structure

Key Components

Troubleshooting

Connection refused error

Invalid wallet address

API timeout

Performance

License

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers