Which integrations are available for this server?

Provides Solana RPC endpoint integration for enhanced performance and reliability when querying Solana blockchain data. Enables Bitcoin blockchain queries including balance checks, transaction history, and network statistics via Blockchain.info API. Used for Bitcoin data retrieval (balance, transactions) without requiring an API key. Supports Ethereum blockchain operations such as ETH balance checks, transaction history, gas price monitoring, and ERC-20 token balances via Etherscan. Allows SOL balance queries and transaction history retrieval via public or Alchemy/QuickNode RPC endpoints.

How do I use Crypto MCP Server?

1. Click on "Install 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., "@Crypto MCP Server what is the current price of Bitcoin?" 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.

Crypto MCP Server

by rex-automata

Overview Schema Related Servers Score Discussions

TypeScript

Remote

🔐 Crypto MCP Server

The first blockchain & cryptocurrency MCP server - Connect AI agents to Ethereum, Solana, Bitcoin, and cryptocurrency markets.

License: MIT TypeScript MCP

🚀 Features

Multi-Chain Support: Ethereum, Solana, and Bitcoin
Wallet Balance Queries: Check balances for any address
Transaction History: Get detailed transaction data
Real-Time Prices: Live cryptocurrency prices from CoinGecko
Gas Price Monitoring: Track Ethereum gas prices
Whale Tracking: Monitor large wallet movements
Token Information: ERC-20 token balances and data
Market Data: Top tokens, price history, and search

Related MCP server: Armor Crypto MCP

📦 Installation

Prerequisites

Node.js 18.0.0 or higher
npm or yarn
API keys (see API Keys section)

Quick Start

Clone or download this repository

git clone https://github.com/rex-automata/crypto-mcp-server.git
cd crypto-mcp-server

Install dependencies

npm install

Configure environment variables

cp .env.example .env
# Edit .env and add your API keys

Build the project

npm run build

Test the server

npm start

🔑 API Keys

Required APIs (Free Tier)

Etherscan API

Get it at: https://etherscan.io/apis
Free tier: 5 calls/second, 100,000 calls/day
Add to .env: ETHERSCAN_API_KEY=your_key_here

CoinGecko API

Get it at: https://www.coingecko.com/en/api/pricing
Free tier: Works without API key (50 calls/minute)
Pro tier: Higher rate limits available
Add to .env: COINGECKO_API_KEY=your_key_here (optional)

Solana RPC

Default: Uses public endpoint (https://api.mainnet-beta.solana.com)
Free upgrades: Alchemy (https://www.alchemy.com) or QuickNode (https://www.quicknode.com)
Add to .env: SOLANA_RPC_URL=your_rpc_url (optional)

Blockchain.info (Bitcoin)

No API key required for basic usage
Higher limits available at https://www.blockchain.com/api

🛠️ Usage

MCP Client Configuration

Add to your MCP client settings (e.g., Claude Desktop):

{
  "mcpServers": {
    "crypto": {
      "command": "node",
      "args": ["/path/to/crypto-mcp-server/dist/index.js"],
      "env": {
        "ETHERSCAN_API_KEY": "your_key_here",
        "COINGECKO_API_KEY": "your_key_here",
        "SOLANA_RPC_URL": "https://api.mainnet-beta.solana.com"
      }
    }
  }
}

Available Tools

Ethereum Tools

get_eth_balance - Get ETH balance for an address
get_eth_transactions - Get transaction history
get_gas_price - Get current gas prices
get_token_balance - Get ERC-20 token balance

Solana Tools

get_sol_balance - Get SOL balance for an address
get_sol_transactions - Get transaction history

Bitcoin Tools

get_btc_balance - Get BTC balance for an address
get_btc_transactions - Get transaction history
get_btc_stats - Get Bitcoin network statistics

Price Tools

get_token_price - Get current price for a cryptocurrency
get_multiple_prices - Get prices for multiple tokens
get_top_tokens - Get top cryptocurrencies by market cap
search_token - Search for a cryptocurrency
get_price_history - Get historical price data

Whale Tracking Tools

is_whale_address - Check if an address is a whale
get_whale_transactions - Get large transactions for an address
get_known_whale_addresses - Get list of known whale addresses

💡 Example Usage

// Get Ethereum balance
{
  "tool": "get_eth_balance",
  "arguments": {
    "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
  }
}

// Get Bitcoin price
{
  "tool": "get_token_price",
  "arguments": {
    "coinId": "bitcoin"
  }
}

// Check if address is a whale
{
  "tool": "is_whale_address",
  "arguments": {
    "address": "0xBE0eB53F46cd790Cd13851d5EFf43D12404d33E8",
    "chain": "ethereum"
  }
}

// Get top 10 cryptocurrencies
{
  "tool": "get_top_tokens",
  "arguments": {
    "limit": 10
  }
}

📁 Project Structure

crypto-mcp-server/
├── index.ts                 # Main MCP server
├── tools/
│   ├── ethereum.ts         # Ethereum tools
│   ├── solana.ts           # Solana tools
│   ├── bitcoin.ts          # Bitcoin tools
│   ├── prices.ts           # Price tracking tools
│   └── whale.ts            # Whale tracking tools
├── package.json
├── tsconfig.json
├── .env.example
└── README.md

🚧 Roadmap

Phase 1: Core Features (Current)

✅ Multi-chain balance queries
✅ Transaction history
✅ Price tracking
✅ Gas monitoring
✅ Basic whale tracking

Phase 2: Premium Features (Planned)

🔲 Real-time transaction monitoring webhooks
🔲 Advanced whale alerts (Telegram/Discord notifications)
🔲 Portfolio tracking across chains
🔲 NFT balance and floor price tracking
🔲 DeFi protocol integration (Uniswap, Aave, etc.)
🔲 Custom alert conditions
🔲 Historical data export

Phase 3: Enterprise Features

🔲 Multi-user support with API key management
🔲 Rate limiting and quota management
🔲 Advanced analytics and reporting
🔲 Custom RPC endpoints
🔲 White-label deployment options

💰 Monetization Strategy

Freemium Model
- Free tier: Basic queries with public APIs
- Pro tier ($9/month): Higher rate limits, more chains
- Enterprise tier ($99/month): Custom features, dedicated support
API Access
- Sell API access to the MCP server
- Volume-based pricing
Premium Features
- Real-time alerts: $5/month
- Advanced whale tracking: $15/month
- Portfolio analytics: $10/month
Consulting/Custom Development
- Custom blockchain integrations
- Private deployment

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Fork the repository
Create your feature branch (git checkout -b feature/AmazingFeature)
Commit your changes (git commit -m 'Add some AmazingFeature')
Push to the branch (git push origin feature/AmazingFeature)
Open a Pull Request

📝 License

This project is licensed under the MIT License - see the LICENSE file for details.

🔗 Links

GitHub: https://github.com/rex-automata/crypto-mcp-server
MCP Documentation: https://modelcontextprotocol.io
Issues: https://github.com/rex-automata/crypto-mcp-server/issues

⚠️ Disclaimer

This software is provided for informational purposes only. It does not constitute financial advice. Always do your own research before making any investment decisions.

📧 Contact

GitHub: @rex-automata
Issues: GitHub Issues

Built with ❤️ for the MCP community

Available Tools

9 tools

get_btc_balanceA

Get Bitcoin wallet balance for a given address

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Bitcoin wallet address

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read-only operation ('Get balance') and no destructive behavior. However, it does not mention any limitations such as rate limits or address validation, but for a simple balance check, the provided information is adequate.

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 a single sentence that is concise and to the point, containing no wasted words or redundant information.

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?

Given the simplicity of the tool (one parameter, no output schema), the description covers the basic purpose and input. It lacks details about the response format but is otherwise complete for its intended use.

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% as the single parameter 'address' has a description. The tool description adds no extra meaning beyond the schema, so the baseline score of 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 verb 'Get' and the resource 'Bitcoin wallet balance', and specifies the required input 'for a given address'. It effectively distinguishes this tool from siblings like get_btc_transactions and get_eth_balance.

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 does not explicitly state when to use this tool versus alternatives, nor does it include when-not-to-use scenarios. However, the context of getting a balance is straightforward and implied by the name and description, making it minimally adequate.

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

get_btc_transactionsB

Get recent Bitcoin transactions for an address

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of transactions to return (default: 10)
`address`	Yes	Bitcoin wallet address

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must disclose behaviors. It only says 'Get recent transactions' but doesn't clarify whether it returns confirmed/pending transactions, pagination, rate limits, or meaning of 'recent'. Key behavioral gaps for a blockchain tool.

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?

One sentence, 6 words, no fluff. However, it omits important details, so it's not maximally effective. Still, it's concise and front-loaded.

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

Completeness2/5

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

Low complexity but description is minimal: no mention of returned fields, ordering, date range, or error handling. Without output schema, more context is needed for correct use by an AI agent.

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% (both params described in schema). The description adds no additional meaning beyond the schema; it only repeats the resource. Baseline 3 is appropriate as schema does the heavy lifting.

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 'Get recent Bitcoin transactions for an address' is specific: verb 'Get', resource 'Bitcoin transactions', and scope 'for an address'. It clearly distinguishes from sibling tools like get_btc_balance (balance) and get_eth_transactions (different blockchain).

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, no prerequisites or exclusions. The description simply states what it does without context for selection.

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

get_eth_balanceB

Get Ethereum wallet balance for a given address

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Ethereum wallet address (0x...)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, and the description does not disclose any behavioral traits such as idempotency, rate limits, or data freshness. The bare statement 'Get...balance' leaves the agent guessing about side effects or restrictions.

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 a single, concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it easy to scan.

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?

For a tool with one required parameter and no output schema, the description covers the basic purpose. However, it omits details like the denomination (wei/ether) and response format, which could be helpful but are not essential.

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% (the only parameter 'address' is described in the schema as 'Ethereum wallet address (0x...)'). The description adds no further semantic value beyond rephrasing the schema. Baseline is 3.

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 action ('Get'), the resource ('Ethereum wallet balance'), and the input condition ('for a given address'). It unambiguously distinguishes this tool from siblings like 'get_btc_balance' or 'get_eth_transactions'.

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 is provided on when to use this tool vs alternatives, nor any conditions or prerequisites. For a simple read tool, this omission is noticeable but not critical.

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

get_eth_transactionsA

Get recent Ethereum transactions for an address

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of transactions to return (default: 10)
`address`	Yes	Ethereum wallet address (0x...)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility. It states 'recent' but does not define the time or block range, nor does it mention authentication, rate limits, side effects, or response structure. This is insufficient for a tool with no annotations.

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 a single sentence that is front-loaded with the core action. No redundant words or filler.

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?

The tool is simple with two parameters and no output schema. The description covers the basic purpose but lacks details on the meaning of 'recent' or the return format. For a straightforward read tool, this is minimally adequate but not thorough.

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 both parameters (address and limit) described. The description does not add meaning beyond what the schema provides. Baseline 3 is appropriate as the schema does the heavy lifting.

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 'Get' and the resource 'recent Ethereum transactions for an address'. It distinguishes from siblings like get_eth_balance, get_btc_transactions, and get_sol_transactions by specifying the chain and data type.

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 when-to-use or when-not-to-use guidance is provided. The description implies usage for retrieving transaction history, but lacks context on alternatives or filtering. The sibling tools cover different chains, so the purpose is clear by comparison, but no explicit guidance is given.

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

get_gas_priceA

Get current Ethereum gas prices (slow, standard, fast)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, and the description does not disclose read-only behavior, side effects, or limitations. For a tool with no parameters, basic transparency is adequate but not enhanced.

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?

A single, concise sentence communicates the purpose and output categories without any wasted words.

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?

Given no parameters and no output schema, the description covers the essential output categories. However, it could be more precise about units (e.g., Gwei) or return format.

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 in the schema (coverage 100%). The description adds value by specifying the output categories (slow, standard, fast), which is helpful beyond the empty 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 clearly states the action (Get) and resource (Ethereum gas prices) with specific categories (slow, standard, fast). It distinguishes from sibling tools which deal with balances, transactions, and token prices.

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 implies usage for retrieving gas prices, and sibling tools cover unrelated functions (balances, transactions). However, no explicit guidance on when not to use or alternatives is provided.

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

get_sol_balanceA

Get Solana wallet balance for a given address

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Solana wallet address (base58 encoded)

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It clearly indicates a read-only operation ('Get'), which is sufficient for a simple balance tool; no additional behavioral warnings seem necessary.

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?

One concise sentence with no wasted words; the purpose is front-loaded and immediately understandable.

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 simple tool with one parameter, no output schema, and no nested objects, the description is fully complete and requires no additional 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 description adds no new meaning beyond the input schema, which already describes the parameter as 'Solana wallet address (base58 encoded)'. Schema coverage is 100%, 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 'Get Solana wallet balance for a given address' uses a specific verb and resource, clearly distinguishing it from sibling tools like get_btc_balance and get_eth_balance.

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 this tool versus alternatives; usage is implied by the tool name and siblings, but no exclusions or context are provided.

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

get_sol_transactionsB

Get recent Solana transactions for an address

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of transactions to return (default: 10)
`address`	Yes	Solana wallet address (base58 encoded)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description bears full burden. It fails to disclose what 'recent' means, pagination behavior, authentication needs, or any side effects. Minimal behavioral insight.

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?

Single sentence, no wasted words. However, it is underspecified for a list tool, sacrificing completeness for brevity.

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

Completeness2/5

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

No output schema. Description omits return format, ordering, time window, or whether results are paginated. Incomplete for an agent to reliably use the tool.

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 descriptions for both parameters. The description adds only the word 'recent', which is ambiguous. Baseline 3 is appropriate as description adds little beyond schema.

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 states the verb 'Get' and the resource 'recent Solana transactions for an address', clearly differentiating from sibling tools like get_sol_balance or get_btc_transactions. However, 'recent' is vague, lacking specificity on time range.

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?

Usage is implied by the purpose: for Solana transaction history. No explicit guidance on when not to use or alternatives, though sibling names provide context.

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

get_token_priceC

Get current price and market data for cryptocurrencies

ParametersJSON Schema

Name	Required	Description	Default
`tokenIds`	Yes	CoinGecko token IDs (e.g., ["bitcoin", "ethereum", "solana"])
`vsCurrency`	No	Currency to convert to (default: "usd")	usd

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose any behavioral traits (e.g., read-only, rate limits, error handling). It merely states the function without context.

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

Conciseness3/5

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

The description is very short (one sentence), which is concise, but at the expense of completeness. It could include more detail without being verbose.

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

Completeness2/5

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

Given the lack of output schema, the description should elaborate on the return format (e.g., price, market cap). It fails to provide enough context for a complete understanding of the tool's output.

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 covers all parameters with descriptions, so baseline is 3. The description adds no additional parameter information beyond what is already in the schema.

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 the tool retrieves price and market data for cryptocurrencies. It distinguishes from sibling tools like balance checkers and search, though it lacks specificity on what market data includes.

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. For instance, it doesn't mention that for individual token balances, sibling tools like get_btc_balance should be used.

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

search_tokensB

Search for cryptocurrency tokens by name or symbol

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query (token name or symbol)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It only mentions search by name/symbol but fails to disclose crucial traits: case sensitivity, partial matching, limit on results, response format, or error behavior. An agent cannot infer what will happen on query.

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 a single, front-loaded sentence with no wasted words. It is appropriately sized for the tool's simplicity, though it could benefit from additional brief details without sacrificing conciseness.

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

Completeness2/5

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

Given the absence of an output schema, the description should explain what the tool returns (e.g., list of token objects, matching tokens, or empty array). It does not mention pagination, result limits, or how to interpret results, leaving the agent without sufficient context for a search tool.

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% and the only parameter 'query' is adequately described as 'Search query (token name or symbol)'. The description confirms this but adds no new meaning beyond the schema, meeting the baseline for adequate parameter semantics.

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 'Search for cryptocurrency tokens by name or symbol', specifying a distinct verb and resource. It effectively distinguishes from sibling tools which are all specific getters (e.g., get_token_price, get_btc_balance), making its purpose as a discovery tool unambiguous.

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 for finding tokens but does not explicitly state when to use this tool vs alternatives like get_token_price. No context on prerequisites or typical flow (e.g., 'Use this to find token IDs before querying prices') is provided, leaving the agent to infer.

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. Dates show when Glama detected each change.

9 tool updatesv1.0.0Jul 13, 2026
- First observedget_btc_balance
- First observedget_btc_transactions
- First observedget_eth_balance
- First observedget_eth_transactions
- First observedget_gas_price
- First observedget_sol_balance
- First observedget_sol_transactions
- First observedget_token_price
- First observedsearch_tokens

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a specific blockchain (BTC, ETH, SOL) and operation (balance, transactions, gas price, token price, search) with no overlap. The purposes are clearly distinct.

Naming Consistency4/5

All tools follow a get_<chain>_<action> pattern except search_tokens, which uses a different verb and no chain prefix. This minor deviation slightly reduces consistency.

Tool Count5/5

9 tools cover the essential read operations for BTC, ETH, and SOL, plus generic token data. The scope is well-balanced and not excessive.

Completeness5/5

The tool set covers key crypto data needs: balances, transactions, gas prices, token prices, and search. There are no obvious gaps for a read-only data server.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

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
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111
Hive Capital A
io.github.srotzin
HiveCapital MCP Server — autonomous investment layer for AI agents
Finance Autonomous Agents Blockchain
2
AlgoVesta MCP TradingOAuth
com.algovesta
Trade 16 crypto exchanges + MetaTrader 5 from your AI assistant via one MCP connection.
Cryptocurrency Finance
2

Related MCP Servers

crypto-sentiment-mcp
Cryptocurrency Social Media Research & Data
kukapay
A
license
A
quality
F
maintenance
An MCP server that delivers cryptocurrency sentiment analysis to AI agents.
Updated a year ago (2025-03-27 22:59 UTC)
5
48
MIT
Armor Crypto MCPofficial
Blockchain Cryptocurrency Web3 & Decentralized Tech
armorwallet
A
license
C
quality
C
maintenance
An MCP server providing unified access to blockchain operations, bridging, swapping, and crypto trading strategies for AI agents.
Updated a year ago (2025-07-29 15:53 UTC)
37
178
GPL 3.0
crypto-projects-mcp
Cryptocurrency Blockchain
kukapay
A
license
B
quality
F
maintenance
An MCP server that provides cryptocurrency project data to AI agents
Updated a year ago (2025-05-11 12:57 UTC)
1
1
MIT
x402 MCP Server
Finance Cryptocurrency
fernsugi
A
license
Not graded
quality
D
maintenance
An MCP server that provides DeFi data tools (crypto prices, whale concentration, funding rates) for AI agents via the x402 protocol.
Updated 7 months ago (2026-02-21 17:50 UTC)
20
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rex-automata/crypto-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🔐 Crypto MCP Server

🚀 Features

📦 Installation

Prerequisites

Quick Start

🔑 API Keys

Required APIs (Free Tier)

Etherscan API

CoinGecko API

Solana RPC

Blockchain.info (Bitcoin)

🛠️ Usage

MCP Client Configuration

Available Tools

Ethereum Tools

Solana Tools

Bitcoin Tools

Price Tools

Whale Tracking Tools

💡 Example Usage

📁 Project Structure

🚧 Roadmap

Phase 1: Core Features (Current)

Phase 2: Premium Features (Planned)

Phase 3: Enterprise Features

💰 Monetization Strategy

🤝 Contributing

📝 License

🔗 Links

⚠️ Disclaimer

📧 Contact

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Armor Crypto MCPofficial

Latest Blog Posts

MCP directory API