Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CoinGecko MCP Server What's 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.
An MCP server for CoinGecko — connect any MCP-compatible client to free crypto market data.
An MCP (Model Context Protocol) server that gives AI assistants and agents access to CoinGecko's free crypto market data API — prices, market caps, trending coins, historical data, and global stats — through natural language.
Use it with Claude Desktop, Cursor, Windsurf, Cline, Continue, or any MCP-compatible client to ask questions about crypto markets, compare tokens, and track prices.
Related MCP server: coingecko-mcp-server
No API key required — CoinGecko's free tier works out of the box (rate-limited to ~27 calls/min)
8 built-in tools — covers the most common crypto data queries
Clean markdown output — results read naturally in chat
Rate-limited automatically — respects free tier limits, retries on 429
Tool | Description |
| Search for cryptocurrencies by name or symbol |
| Get current prices, market caps, and 24h changes for one or more coins |
| Get top N coins by market cap with full stats |
| Get currently trending coins (last 24h search volume) |
| Get detailed info about a specific coin (description, links, market data, categories) |
| Get historical price data (daily, weekly, monthly, yearly) |
| Get global crypto market stats (total MCap, BTC dominance, active cryptos) |
| Compare prices and stats of multiple tokens side-by-side |
Add this to your MCP client config (e.g. claude_desktop_config.json):
{
"mcpServers": {
"coingecko": {
"command": "npx",
"args": ["-y", "coingecko-mcp-server"]
}
}
}That's it. No API key, no install step. npx downloads and runs it automatically.
Ask your AI assistant things like:
"What's the current price of Bitcoin and Ethereum?"
"Show me the top 10 coins by market cap"
"What's trending on CoinGecko right now?"
"Compare Solana, Avalanche, and Polkadot"
"How has Bitcoin performed over the last 30 days?"
"What's the total crypto market cap and BTC dominance?"
"Search for AI-related crypto tokens"
"Tell me about Chainlink — categories, links, market data"
get_trending🔥 Trending Coins (last 24h):
1. Bitcoin (BTC) — Rank #1 | MCap: $1,340.2B | 24h: +2.1%
2. Ethereum (ETH) — Rank #2 | MCap: $412.8B | 24h: +1.8%
3. Solana (SOL) — Rank #5 | MCap: $78.4B | 24h: +4.3%
...get_token_price_comparisonToken Comparison (USD):
| Coin | Price | MCap | 24h | 7d | Vol |
|------|-------|------|-----|-----|-----|
| Bitcoin (BTC) | $67,234 | $1,340.2B | +2.1% | +5.3% | $28,400M |
| Ethereum (ETH) | $3,456 | $412.8B | +1.8% | +3.1% | $14,200M |
| Solana (SOL) | $178.5 | $78.4B | +4.3% | +12.1% | $3,800M |Ask "What's my portfolio worth?" after listing your holdings. The server compares prices across multiple tokens and gives you a snapshot with market caps, 24h changes, and volume.
"Show me trending coins with high volume" — find new opportunities by checking what's getting attention. Combine with get_coin_details to deep-dive into categories and links before committing.
"What's the total crypto market cap and BTC dominance?" gives you macro context in seconds. Use get_global_stats before making any allocation decision.
"Compare Solana, Avalanche, and Polkadot" — side-by-side price, market cap, and performance data. Faster than opening three tabs on CoinGecko.
"How has Bitcoin performed over the last 30 days?" — daily price history for trend analysis. Works with any timeframe (daily, weekly, monthly, yearly).
No API key by default — uses CoinGecko's free tier. Optional API key for higher rate limits.
Read-only — only fetches public market data from CoinGecko's API. No writes, no mutations.
No local file access — does not read or write any files on your machine.
No shell access — does not execute commands or spawn processes.
Rate-limited — automatically caps requests to stay within free tier limits.
Open source — MIT licensed. Inspect the code at GitHub.
The server auto-retries on 429, but if you're making rapid queries, add a short delay between requests. Free tier allows ~27 calls/minute. If you hit this frequently, set a COINGECKO_API_KEY for higher limits.
Use search_coins first to find the correct CoinGecko ID. Coin IDs are lowercase slugs (e.g. bitcoin, ethereum, solana), not ticker symbols.
Make sure Node.js 18+ is installed: node --version. If using npx, ensure npm is up to date: npm install -g npm@latest.
Verify the config path is correct. Claude Desktop uses ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and %APPDATA%\Claude\claude_desktop_config.json on Windows. Restart the client after config changes.
CoinGecko's free tier has ~300ms latency per call. Multi-coin queries (get_prices, get_token_price_comparison) make one API call regardless of how many coins you pass, so batch your queries.
Node.js 18+
No API key needed (CoinGecko free tier)
The server automatically rate-limits requests to ~27 calls/minute to stay within CoinGecko's free tier. If you have a CoinGecko Pro API key, you can set the COINGECKO_API_KEY environment variable for higher limits:
{
"mcpServers": {
"coingecko": {
"command": "coingecko-mcp-server",
"env": {
"COINGECKO_API_KEY": "your_key_here"
}
}
}
}git clone https://github.com/nova/coingecko-mcp-server.git
cd coingecko-mcp-server
npm install
npm run build
npm startMIT
Get comprehensive details for a single coin by ID: current price, market cap, 24h/7d/30d changes, ATH/ATL, supply data, categories, genesis date, description, and links (homepage, Twitter, GitHub). Returns formatted markdown with all available market data. Use search_coins to find the coin ID first.
| Name | Required | Description | Default |
|---|---|---|---|
| coin_id | Yes | CoinGecko coin ID (e.g. 'bitcoin', 'ethereum') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description states it returns formatted markdown with all available market data, which is a key behavioral detail. Does not mention auth, rate limits, or error handling, but for a read-only tool this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first lists capabilities, second output format, third usage hint. No wasted words.
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?
Single parameter, straightforward. Description covers return content in detail despite lacking output schema. Could mention error cases for invalid coin_id, but overall complete.
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 already describes coin_id with examples (bitcoin, ethereum). Description adds 'single coin by ID' but doesn't add new meaning beyond the schema. Baseline 3 is appropriate due to 100% schema coverage.
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 it gets comprehensive details for a single coin by ID, listing many specific data points (price, market cap, changes, etc.). Distinguishes from siblings by naming search_coins for finding the ID first.
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?
Provides guidance to use search_coins first, implying proper sequence. Lacks explicit comparisons with other siblings like get_price_history or get_market_overview for when to use this vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate crypto market statistics: total market cap, 24h volume, BTC/ETH dominance percentages, number of active cryptocurrencies and exchanges, and 24h market cap change. Returns formatted summary of the entire crypto market in one call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains what data is returned and that it is a 'formatted summary', but it does not detail the output format (e.g., JSON structure, units, if it's a string) or any potential side effects, rate limits, or authentication needs. It is fairly clear for a read-only tool without parameters but lacks some depth.
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 two sentences, front-loaded with the action, and lists the key data points without unnecessary words. Every sentence adds value, and it is succinct.
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?
Given the tool's simplicity (no parameters, no output schema), the description covers the main returned data points. However, it lacks details on whether data is real-time, any usage limits, or the exact output format. It is nearly complete but could improve slightly.
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?
The tool has zero parameters, so the schema coverage is 100% by default. The rubric states a baseline of 4 for 0 parameters. The description does not need to add parameter meaning, so this score reflects the baseline due to no parameters.
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 clearly states the tool retrieves aggregate crypto market statistics with a specific list of data points (market cap, volume, dominance percentages, etc.). It uses a specific verb 'Get' and the resource is clearly defined as global crypto market stats. It distinguishes itself from siblings by emphasizing it returns the entire market summary in one call, unlike other tools that might focus on individual coins or detailed market overview.
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?
The description implies usage as a single call for overall market stats (e.g., 'entire crypto market in one call'), but it does not explicitly state when to use this vs. alternatives like get_market_overview. No guidance on exclusions or prerequisites is provided. It gives a hint but lacks clear directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top cryptocurrencies ranked by market cap with price, market cap, 24h change, and 24h volume. Returns up to N coins (default 20) sorted by market cap descending. Useful for a quick snapshot of the overall market or identifying top performers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of top coins (default 20) | |
| vs_currency | No | Target currency (default: usd) | usd |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good transparency: it specifies the return fields (price, market cap, 24h change, volume), sorting (market cap descending), and default limit. It does not mention side effects, permissions, or rate limits, but for a read-only data retrieval this is acceptable. The description adds value beyond the schema by clarifying the output structure.
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 two sentences, each concise and informative. The first sentence states the core functionality, the second expands on defaults, sorting, and use case. No redundancy, every sentence serves a purpose.
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?
Given the tool's simplicity (2 optional params, no output schema), the description covers the main purpose, returned data, ordering, default, and use case. It does not mention potential errors, maximum limit, or pagination, but for a quick snapshot tool it is sufficient. Missing explicit differentiation from siblings, but the purpose is clear.
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% with descriptions for both parameters. The description reinforces the 'limit' parameter's meaning and default but does not add new information beyond what the schema already provides. For 'vs_currency', the description's mention of 'price' hints at its effect, but the schema already states 'Target currency'. No significant added value.
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 clearly states that it gets top cryptocurrencies ranked by market cap, listing specific fields (price, market cap, 24h change, 24h volume) and the sorting order. It distinguishes from siblings like get_coin_details (specific coin) and get_global_stats (global stats), making the tool's scope unambiguous.
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?
The description says 'useful for a quick snapshot of the overall market or identifying top performers,' which implies usage context but does not explicitly state when not to use it or provide alternatives. For example, it could mention that for historical data use get_price_history or for specific coins use get_coin_details. The guidance is vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical price data for a coin over N days (1, 7, 30, 90, 365, or max). Returns sampled daily prices with date stamps and overall period change percentage. Useful for charting trends and identifying price patterns over time.
| Name | Required | Description | Default |
|---|---|---|---|
| coin_id | Yes | CoinGecko coin ID (e.g. 'bitcoin') | |
| vs_currency | No | Target currency (default: usd) | usd |
| days | No | Number of days of history (1, 7, 30, 90, 365, or 'max') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that returns are 'sampled daily prices with date stamps and overall period change percentage,' which is helpful. However, it does not mention potential error handling (e.g., invalid coin_id), sampling method (e.g., end-of-day), or limitations (e.g., rate limits). The description is adequate but not comprehensive.
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 three sentences with front-loading: first sentence states purpose, second adds return details, third provides use case. No filler or redundant information. Every sentence earns its place. It is appropriately sized for the tool's simplicity.
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?
Given the tool's simplicity (3 parameters, no output schema), the description covers purpose, return structure, and typical use case. It lacks explicit details on the exact output format (e.g., array of objects), but the mention of 'sampled daily prices with date stamps' gives a strong hint. With no output schema, the description is reasonably complete for an AI to understand the result.
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 baseline is 3. The description repeats the allowed days values from the schema (1, 7, 30, 90, 365, max) but adds no new meaning beyond what the schema already provides. The parameter descriptions in the schema are already sufficient for an AI agent.
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 clearly states the tool's purpose: 'Get historical price data for a coin over N days'. It lists specific day options (1, 7, 30, 90, 365, max) and mentions return contents (daily prices, date stamps, percentage change). This provides clear verb+resource specificity and helps distinguish from sibling tools like get_prices (current prices) and get_trending (trending data).
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?
The description provides clear usage context: 'Useful for charting trends and identifying price patterns over time.' However, it does not explicitly state when not to use this tool or offer alternatives. Given sibling tools like get_prices (possibly for current prices) and get_token_price_comparison (for multiple tokens), the description could benefit from exclusions, but the implied use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time prices, market caps, 24h volume, and 24h price change for one or more coins. Accepts comma-separated CoinGecko IDs (use search_coins to find IDs). Returns formatted price, market cap, volume, and 24h change percentage for each coin. Useful for quick price checks across multiple tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| coin_ids | Yes | Comma-separated CoinGecko IDs (e.g. 'bitcoin,ethereum,solana') | |
| vs_currency | No | Target currency (default: usd) | usd |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the tool returns formatted price, market cap, volume, and change percentage, and accepts comma-separated IDs. However, it does not disclose potential rate limits, data freshness constraints, or error handling. For a simple query tool, this is acceptable but could be more transparent.
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 three sentences, front-loaded with the main purpose, and each sentence adds distinct value: what data is returned, how to specify coins, and when to use. No wasted words.
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?
Given the tool's simplicity and no output schema, the description adequately covers inputs (two parameters), output format (price, market cap, volume, change), and usage context (quick price checks). It could mention data source or limitations, but is complete for its purpose.
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% with descriptions for both parameters. The description adds that coin_ids are comma-separated CoinGecko IDs and suggests using search_coins to find them. This adds some value beyond schema but is not extensive; baseline 3 is appropriate.
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 clearly states the tool retrieves real-time prices, market caps, 24h volume, and price change for coins. It specifies the resource (coins) and action (get), and distinguishes from siblings like get_price_history by focusing on current data. Mention of using search_coins to find IDs further clarifies scope.
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?
The description indicates it is 'useful for quick price checks' and advises using search_coins for IDs, but does not explicitly state when not to use this tool or compare to alternatives like get_coin_details or get_price_history. The guidance is adequate but lacks exclusions or specific context for choosing among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare multiple tokens side-by-side in a formatted table. Shows price, market cap, 24h change, 7d change, and 24h volume for each coin. Accepts comma-separated CoinGecko IDs. Use search_coins to find IDs, then compare with this tool for a quick multi-token comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| coin_ids | Yes | Comma-separated coin IDs (e.g. 'bitcoin,ethereum,solana,avalanche-2') | |
| vs_currency | No | Target currency | usd |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the tool produces a 'formatted table' and lists the displayed metrics, which is transparent about what the tool does. However, it does not mention error handling (e.g., invalid IDs) or data freshness, which would be beneficial.
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?
Two sentences that are front-loaded with the main purpose, followed by a usage workflow. Every word adds value; no redundancy or filler. Highly efficient.
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?
The tool has 2 parameters, no output schema, and no annotations. The description covers the function, parameters, and workflow. It is missing details on output format (e.g., table vs raw JSON) and error scenarios, but for a read-only query tool, it is reasonably complete.
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?
The input schema has 100% coverage, so the baseline is 3. The description adds value by explaining that coin_ids should be comma-separated CoinGecko IDs and provides examples ('bitcoin,ethereum,solana,avalanche-2'). This clarification goes beyond the schema's description.
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 clearly states the tool compares multiple tokens side-by-side in a formatted table, specifying exactly what data is shown (price, market cap, 24h change, 7d change, 24h volume). It also distinguishes from siblings like search_coins and get_prices by providing a usage workflow.
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?
The description explicitly tells when to use the tool ('for a quick multi-token comparison') and provides a clear workflow: use search_coins to find IDs, then compare. It implies not to use it for single coin details, guiding the agent to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top trending coins on CoinGecko over the last 24 hours based on search volume. Returns each trending coin's name, symbol, rank, market cap, and 24h price change. Useful for spotting momentum and emerging narratives in the crypto market.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly describes a read-only operation returning specific data. However, it lacks explicit mention of non-destructive nature or any potential side effects, rate limits, or authentication requirements, which would be helpful.
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 consists of two concise sentences. The first sentence states the tool's action and scope, and the second lists the returned fields. No unnecessary words, well-structured with key information front-loaded.
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?
Given no parameters and no output schema, the description adequately explains the tool's purpose and return values. It is complete enough for an agent to understand what the tool does and its output. However, lacking output schema means the agent must infer field types.
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?
The input schema has no parameters, so the description does not need to cover parameter semantics. The baseline for zero parameters is 4, and the description adds value by explaining what data is returned, which is sufficient.
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 clearly states the tool retrieves 'top trending coins' over 24 hours based on search volume, specifying the returned fields (name, symbol, rank, market cap, 24h price change). It distinguishes from siblings like get_coin_details (specific coin) and get_market_overview (broader market data).
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?
The description mentions usefulness 'for spotting momentum and emerging narratives,' which implies context but does not explicitly state when to use this tool versus alternatives like get_market_overview or search_coins. No exclusions or when-not guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cryptocurrencies by name or symbol. Returns matching coins ranked by market cap, each with name, symbol, rank, and CoinGecko ID. Use the returned ID in get_prices, get_coin_details, or get_price_history for full data on a specific coin.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term (e.g. 'bitcoin', 'ETH', 'solana') | |
| limit | No | Max results (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states results are ranked by market cap and lists return fields, but does not cover rate limits, pagination behavior, or error conditions. The description is adequate but not comprehensive.
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 three well-structured sentences: purpose, return format, and follow-up usage. No wasted words; critical information is front-loaded.
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?
Given no output schema and no annotations, the description covers the essential elements: what the tool does, what it returns, and how to use the output. Missing details like sorting order (implied but not explicit) and result size limits beyond the limit parameter, but overall satisfactory.
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% (both parameters have descriptions). The tool description reiterates the search term and limit purpose but adds no new semantic meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
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 clearly states the tool's purpose: 'Search cryptocurrencies by name or symbol.' It specifies the return fields (name, symbol, rank, CoinGecko ID) and differentiates from sibling tools by instructing to use the returned ID for further details.
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?
The description provides when to use this tool (to search for coins) and how to proceed after getting results (use ID in other tools). It implicitly discourages direct use if ID is already known, though it lacks explicit 'when not to use' guidance.
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. Dates show when Glama detected each change.
v1.0.4get_coin_detailsget_global_statsget_market_overviewget_price_historyget_pricesget_token_price_comparisonget_trendingsearch_coinsTools are mostly distinct with clear purposes. The only potential confusion is between get_prices and get_token_price_comparison, both returning price data for multiple coins, but the comparison tool adds 7d change and a table format, and descriptions clarify the difference.
All tool names follow a consistent verb_noun pattern (get_* or search_*), using snake_case. This makes the set predictable and easy to understand.
With 8 tools covering search, details, multiple prices, comparison, overview, history, trending, and global stats, the count is well-scoped for a crypto data API without unnecessary bloat.
The tool set covers essential crypto data queries. Minor gaps include no direct listing of all coins (search_coins is limited) and no exchange-specific data, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Official CoinMarketCap MCP server: real-time crypto prices, market cap, rankings and exchange data.
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/friendlygeorge/coingecko-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
