CoinGecko MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.4
Disambiguation4/5
Tools 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.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (get_* or search_*), using snake_case. This makes the set predictable and easy to understand.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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: '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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
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 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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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: '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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![coingecko-mcp-server MCP server](https://glama.ai/mcp/servers/friendlygeorge/coingecko-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/friendlygeorge/coingecko-mcp-server)

Score Badge

Copy to your README.md:

[![coingecko-mcp-server MCP server](https://glama.ai/mcp/servers/friendlygeorge/coingecko-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/friendlygeorge/coingecko-mcp-server)

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/friendlygeorge/coingecko-mcp-server'

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