Real-time crypto market intelligence for AI assistants.
CryptoSense MCP wraps the CoinGecko free API (no key needed) into a production-ready Model Context Protocol server built with FastMCP. Connect it to Claude, Cursor, Windsurf, or any MCP-compatible client and ask natural-language questions about crypto markets.
Tool | Description |
| Current price, market cap, volume & 24h change for any coin |
| Top 10 trending coins by search volume (last 24 h) |
| Global market cap, BTC/ETH dominance, 24h change |
| Top N coins by market cap with full stats |
| Side-by-side comparison of 2+ coins |
| USD value of your holdings with best/worst performer |
All tools require a CryptoSense API key (see Authentication).
Related MCP server: revolut mcp pulse
uv (recommended)# 1. Clone
git clone https://github.com/your-org/cryptosense-mcp.git
cd cryptosense-mcp
# 2. Create venv and install
uv venv && uv pip install -e .
# 3. Copy and edit environment variables
cp .env.example .env
# Edit .env: set CMC_API_KEY if you have one, adjust MCP_PORT if needed
# 4. Generate your first API key
python -c "
import asyncio
from src.cryptosense.auth import generate_api_key
key = asyncio.run(generate_api_key('you@example.com'))
print('Your API key:', key)
"
# 5. Start the server
cryptosense-mcp
# or: python -m cryptosense.serverpippip install -e .
cp .env.example .env
python -m cryptosense.serverdocker build -t cryptosense-mcp .
docker run -p 8000:8000 \
-e CMC_API_KEY=your_key \
-v cryptosense-data:/app/data \
cryptosense-mcpEvery tool call requires an api_key parameter with a valid CryptoSense key.
import asyncio
from cryptosense.auth import generate_api_key
key = asyncio.run(generate_api_key(email="you@example.com", plan="free"))
print(key) # cs_Abc123...Keys are stored in keys.db (SQLite). The keys.db file lives next to the server process (or at DATABASE_URL from .env).
CoinGecko's free public API works without a key. If you experience rate limiting (30 calls/min on the free tier), sign up at https://www.coingecko.com/en/api for a free Demo API key and add it to your .env:
CG_API_KEY=CG-xxxxxxxxxxxxxxxxxxxxThe server currently uses the public endpoint. If you add a key, pass it via the
x-cg-demo-api-keyheader in_fetch()calls.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"cryptosense": {
"command": "python",
"args": ["-m", "cryptosense.server"],
"cwd": "/absolute/path/to/cryptosense-mcp",
"env": {
"MCP_HOST": "127.0.0.1",
"MCP_PORT": "8000"
}
}
}
}Or if the server is already running remotely, use the HTTP transport URL:
{
"mcpServers": {
"cryptosense": {
"url": "http://localhost:8000/mcp"
}
}
}Open Settings → MCP → Add new MCP server and enter:
Field | Value |
Name | CryptoSense |
Type | HTTP |
URL |
|
Or add to ~/.cursor/mcp.json:
{
"mcpServers": {
"cryptosense": {
"url": "http://localhost:8000/mcp"
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"cryptosense": {
"serverUrl": "http://localhost:8000/mcp"
}
}
}price — Get coin price"What is the price of Bitcoin?" "How much is Ethereum worth in EUR?" "Show me Solana's 24h change and market cap."
price(coin="bitcoin", currency="usd", api_key="cs_...")
# → { "coin": "bitcoin", "price": 67420.0, "market_cap": 1.32T, "change_24h_percent": 2.4, ... }top_coins — Top coins by market cap"Show me top 10 coins." "What are the top 20 cryptocurrencies by market cap?" "List the 5 biggest coins in EUR."
top_coins(limit=10, currency="usd", api_key="cs_...")
# → { "coins": [{ "rank": 1, "name": "Bitcoin", "price": 67420, ... }, ...] }trending — Trending now"What is trending in crypto today?" "Which coin is everyone searching for?" "Show me the hottest altcoins right now."
trending(api_key="cs_...")
# → { "trending_coins": [{ "name": "Pepe", "symbol": "PEPE", "market_cap_rank": 54, ... }] }portfolio_value — Portfolio calculator"Calculate my portfolio: 0.5 BTC, 5 ETH, 100 SOL." "How much is my crypto worth? I have 1 bitcoin and 10 ethereum." "What is my total if I hold 0.1 BTC, 500 DOGE, and 2 ETH?"
portfolio_value(
holdings={"bitcoin": 0.5, "ethereum": 5, "solana": 100},
currency="usd",
api_key="cs_...",
)
# → { "total_value": 54230.00, "best_performer": {...}, "breakdown": [...] }compare — Side-by-side comparison"Compare Bitcoin and Ethereum." "Which performs better: Solana, Avalanche, or Polkadot?" "Show me BTC vs ETH vs BNB."
compare(coins=["bitcoin", "ethereum", "solana"], currency="usd", api_key="cs_...")
# → { "comparison": [...], "best_performer_24h": "solana", "worst_performer_24h": "bitcoin" }market_overview — Global snapshot"What is the total crypto market cap?" "What is Bitcoin's market dominance today?" "Give me a global crypto summary."
market_overview(api_key="cs_...")
# → { "total_market_cap_usd": 2.45T, "btc_dominance_percent": 52.3, ... }Variable | Default | Description |
| — | CoinMarketCap API key (optional, reserved for future CMC tools) |
|
| Server bind address |
|
| Server port |
|
| Path to the SQLite database |
| — | Set to |
All tools return a friendly {"error": "..."} dict on failure — no stack traces are ever returned to the client. Handled conditions:
Invalid / missing API key → prompt to generate one
Coin not found → suggests using the full CoinGecko ID
Rate limit (429) → asks to wait and retry
Network errors → descriptive message
Invalid parameters → caught before the API call
MIT
Compare two or more cryptocurrencies side by side.
Shows price, market cap, 24h volume, and 24h performance for each coin.
| Name | Required | Description | Default |
|---|---|---|---|
| coins | Yes | List of CoinGecko coin IDs, e.g. ["bitcoin", "ethereum", "solana"]. | |
| api_key | No | Your CryptoSense API key. | |
| currency | No | Fiat currency (default: "usd"). | usd |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It states the informational output, which is helpful, but it does not explicitly confirm the operation is read-only, mention authentication requirements beyond the api_key parameter, or disclose any rate limits, errors, or side effects. The 'compare' verb implies a safe operation, but this is under-specified.
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 concise sentences, front-loaded with the primary action ('Compare...') and followed by a compact list of the displayed metrics. Every sentence adds value, with no redundant or filler content.
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 a complete input schema and an output schema, so the description need not explain return values. It effectively covers the core function and the minimum coin count. It is slightly thin on usage guidance relative to siblings, but for a straightforward comparison tool with full schema coverage, it is adequately 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 coverage is 100%, so the baseline is 3. The description adds meaningful context by specifying 'two or more' for the coins parameter, a constraint not present in the schema (no minItems), and by clarifying the per-coin metrics returned. This goes beyond the schema's property descriptions.
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 uses a specific verb ('Compare') and resource ('cryptocurrencies'), and clearly indicates a side-by-side comparison of multiple coins. It also lists the exact metrics shown (price, market cap, 24h volume, 24h performance), which distinguishes it from sibling tools like price (single coin) or market_overview (broad market).
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 for comparing two or more cryptocurrencies, but it does not explicitly contrast with alternatives or state when not to use it. The phrase 'two or more' hints that it is not for single-coin queries, but no direct references to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the global crypto market overview.
Includes total market cap, 24h volume, BTC dominance, ETH dominance, and active coin/market counts.
Example prompts:
"What is the total crypto market cap?"
"Give me a global crypto market summary."
"What is Bitcoin's market dominance?"
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose data source, request behavior, rate limits, or whether an API key is required or optional. The presence of an api_key parameter is not addressed, leaving operational behavior opaque.
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 compact and front-loaded with the main purpose, followed by a useful bullet-style list of deliverables and concrete example prompts. Every sentence contributes meaningful information without redundancy.
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 output schema handles return values, and the listed metrics give a good sense of the tool's scope. However, missing guidance on the api_key parameter and lack of behavioral or alternative-tool context leave the description only minimally 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 one parameter, api_key, with 0% schema description coverage, and the description does not mention it at all. This fails to compensate for the low schema coverage, giving the agent no additional guidance on how or whether to supply the key.
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 a specific verb and resource: 'Get the global crypto market overview.' It then enumerates the included metrics (market cap, 24h volume, BTC/ETH dominance, active counts), which distinguishes it from sibling tools like price, trending, and top_coins.
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 example prompts give concrete usage context, such as asking for total crypto market cap or Bitcoin dominance. However, it does not explicitly mention when not to use the tool or direct users to alternatives, so it misses the top level of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the current USD value of a crypto portfolio.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Your CryptoSense API key. | |
| currency | No | Fiat currency for valuation (default: "usd"). | usd |
| holdings | Yes | Dict mapping coin ID to amount, e.g. {"bitcoin": 0.5, "ethereum": 2}. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description carries the full burden of behavioral disclosure. It does not mention that the currency parameter can override USD, how unknown holdings are handled, whether an API key is needed, or any data-source/rate-limit details.
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?
A single, front-loaded sentence conveys the core action with no redundant words. It is concise and well-structured for quick agent parsing.
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 is simple, has a detailed schema, and an output schema exists, so the description need not explain return values. However, it lacks any context about when to choose this tool or how to handle edge cases, leaving some gaps for a fully informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level meaning and its 'USD' wording could be misleading given the currency parameter, but the schema already documents each parameter clearly.
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 verb 'calculate' and the resource 'crypto portfolio', and it distinguishes this tool from siblings like price or trending by focusing on aggregate valuation. However, it specifies 'USD value' while the schema's currency parameter allows other fiat currencies, creating minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you need a portfolio valuation rather than single-coin pricing. There is no explicit mention of alternatives or scenarios where another tool would be preferred, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current price, 24h change, market cap, and volume for any cryptocurrency.
Example prompts:
"What is the price of Bitcoin?"
"How much is Ethereum worth in EUR?"
"Show me Solana's market cap and 24h change."
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | ||
| api_key | No | ||
| currency | No | usd |
| Name | Required | Description |
|---|---|---|
No output 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 of behavioral disclosure. It states the output fields but does not disclose the default currency behavior, the purpose of the api_key parameter, error handling, or any rate limits. The 'Get' verb implies a read operation but lacks deeper transparency.
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 long, front-loaded with a clear purpose, and followed by illustrative examples. Every sentence earns its place without unnecessary detail.
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?
For a simple tool with three parameters and an output schema, the description covers the core purpose and provides examples. It is missing usage guidelines and api_key semantics, but given the low complexity, it is nearly complete. The main gap is lack of explicit sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'coin' via 'any cryptocurrency' and for 'currency' via the EUR example, but it leaves the 'api_key' parameter entirely unexplained. This is partial compensation, not complete.
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 uses a specific verb 'Get' and clearly states the resource: current price, 24h change, market cap, and volume for any cryptocurrency. The example prompts demonstrate the tool's scope for individual coins, which distinguishes it from sibling tools like market_overview and top_coins that likely cover 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 example prompts imply when to use the tool (e.g., when a user asks for a specific coin's price), but there is no explicit statement of when to use this tool versus alternatives, no exclusions, and no mention of sibling tools. Usage context is clear but guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top N cryptocurrencies by market cap with price and stats.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many coins to return (1–50, default 10). | |
| api_key | No | Your CryptoSense API key. | |
| currency | No | Fiat currency for prices (default: "usd"). | usd |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 implies a read-only operation ('Get') but does not mention authentication requirements, rate limits, or behavior with an invalid or missing API key. 'With price and stats' gives a minimal hint but is largely covered by the output schema.
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 a single, front-loaded sentence with no redundant or irrelevant information. Every word contributes to the core 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?
The tool is simple, optional parameters are fully documented in the schema, and an output schema exists to detail return fields. The description is sufficient for basic use, though it could mention auth expectations; however, the structured data compensates for most gaps.
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 provides 100% parameter coverage with descriptions for 'limit', 'api_key', and 'currency', so the baseline is 3. The description adds no additional parameter meaning beyond the schema, and it does not mention any parameter interplay or constraints.
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 uses a specific verb ('Get') and clearly defines the resource ('top N cryptocurrencies by market cap') with an outcome ('with price and stats'). It effectively distinguishes itself from siblings like 'price' and 'trending' by emphasizing market-cap ranking.
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?
No explicit guidance is given about when to use this tool versus alternatives such as 'trending' or 'market_overview'. The use case is only implied by the purpose statement, and no exclusions or alternative references are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top 10 trending cryptocurrencies on CoinGecko right now.
Trending is based on search volume over the last 24 hours.
Example prompts:
"What is trending in crypto today?"
"Show me the hottest coins right now."
"Which crypto is everyone searching for?"
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the data source (CoinGecko), the metric (search volume), the time window (last 24 hours), and the output size (top 10). It does not mention rate limits or whether an API key is required, but given the simple read-only nature and presence of an output schema, this is sufficient.
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 concise and front-loaded with the core statement. The second sentence adds essential context about the trending metric, and the example prompts are practical without being verbose. Every element earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and the presence of an output schema, the description is largely complete. It explains what the tool does, how trending is determined, and when to use it. The only gap is the lack of api_key parameter guidance, but that is a minor omission for a tool with one optional parameter.
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 description provides no explanation of the single api_key parameter, and the schema coverage is 0%. The optional api_key with a default empty string is not described, so the agent cannot infer when or how to provide it. The description should at least note that an API key is optional or required for higher rate limits.
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 function: 'Get the top 10 trending cryptocurrencies on CoinGecko right now.' It specifies the resource (CoinGecko), the action (get), the result limit (top 10), and the temporal scope (right now). It also differentiates from siblings by explicitly stating trending is based on search volume over 24 hours, which distinguishes it from top_coins or price tools.
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 context for when to use the tool through example prompts like 'What is trending in crypto today?' and 'Show me the hottest coins right now.' It implies usage for trending/search-volume queries, but it does not explicitly exclude alternatives (e.g., top_coins for market cap) or name sibling tools as alternatives.
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.0comparemarket_overviewportfolio_valuepricetop_coinstrendingEach tool targets a distinct query type: single price lookup, trending list, global stats, top N, comparison, and portfolio calculation. Overlap is minimal, with trending and top_coins differing by search volume versus market cap.
All names follow a consistent lowercase_with_underscores style, but the grammatical pattern is mixed: nouns (price, market_overview), gerund (trending), adjective+noun (top_coins), verb (compare), and compound noun (portfolio_value). No verb_noun pattern is established, though names remain readable.
Six tools is well-scoped for a crypto market data server, fitting comfortably within the ideal 3-15 range. Each tool has a clear purpose without redundancy.
The surface covers single-coin pricing, market lists, global overview, comparison, and portfolio valuation, covering core workflows. Historical price data and detailed coin metadata are missing, but these are not essential to the server's apparent purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Crypto trading intelligence MCP — 34+ endpoints, x402 pay-per-use, AI agent strategy & execution
Crypto market data & research MCP: price, derivatives, on-chain, sentiment, news, catalysts.
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/josephibra/cryptosense-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server