Provides access to live cryptocurrency market data and order book depth from Binance.US, enabling agents to retrieve real-time bid/ask spreads and market liquidity information.
First MCP server for live market data. Gives any AI agent real-time crypto prices, candlestick charts, order books, technical analysis, and market sentiment.
Zero API keys. Zero dependencies. Works out of the box.
BTC: $70,741 24h: +2.3% Vol: $39.8B MCap: $1.42T
ETH: $2,162 24h: +2.5% Vol: $17.5B
SOL: $91.70 24h: +3.2% Vol: $3.9B
Technical Analysis (BTC 30-day):
RSI(14): 64.85 → NEUTRAL
SMA(20): $69,884
Trend: SIDEWAYS
Z-score: 0.57 → NORMAL
Volatility: 101.62% annualized
Order Book (BTC/USDT):
Spread: $15.17 (0.021%)
Best bid: $70,750.15
Best ask: $70,765.32
Fear & Greed Index:
2026-03-25: 14 (Extreme Fear)
2026-03-24: 11 (Extreme Fear)
Trending: TAO, PENGU, SIREN, HYPE, BPRelated MCP server: market-data-mcp
Add to Claude Code settings.json:
"mcpServers": {
"market": {
"command": "npx",
"args": ["-y", "mcp-market-data"]
}
}8 tools for any AI agent:
Tool | What it does |
| Current price, 24h change, volume, market cap, ATH for any crypto |
| OHLCV candlestick data — 1 day to 1 year of history |
| Live order book depth — top 20 bids/asks, spread, mid price |
| Top 100 cryptos ranked by market cap |
| What's trending right now on the market |
| Technical analysis: RSI, SMA(20/50), volatility, z-score, trend signals |
| Compare up to 10 assets side by side |
| Crypto Fear & Greed Index — 7-day sentiment history |
"What's BTC at?"
price(symbol: "BTC")
→ { price: 71234.56, change_24h: +2.3%, volume_24h: $28B, market_cap: $1.4T }"Is ETH overbought?"
analyze(symbol: "ETH")
→ { rsi_14: 72.3, rsi_signal: "OVERBOUGHT", trend: "UPTREND", zscore: 1.8 }"Show me the order book for SOL"
order_book(symbol: "SOL")
→ { bids: [...], asks: [...], spread: $0.02, spread_pct: "0.01%" }"What's trending?"
trending()
→ { coins: [{ name: "Pepe", symbol: "PEPE", rank: 28 }, ...] }"Compare BTC vs ETH vs SOL"
compare(symbols: "BTC,ETH,SOL")
→ [{ symbol: "BTC", price: 71234, change_24h: +2.3% }, ...]"What's the market mood?"
feargreed()
→ [{ value: 73, label: "Greed", date: "2026-03-25" }, ...]CoinGecko — prices, market cap, trending, candles (free, no key)
Binance.US — order book depth (free, no key)
Alternative.me — Fear & Greed Index (free, no key)
12/12 evals passing on live data:
✓ Initialize returns version
✓ Lists all 8 tools
✓ Price returns BTC with real data
✓ Price returns ETH
✓ Candles returns OHLC array
✓ Order book returns bids and asks
✓ Market cap returns ranked list
✓ Trending returns coins
✓ Analyze returns RSI + signals
✓ Compare returns multiple assets
✓ Fear & Greed returns index
✓ Handles bad symbol gracefullyAI agents discussing markets can't check live prices. Now they can.
No API keys to configure. No accounts to create. Just install and go.
Technical analysis built in — agents get actionable signals, not just numbers.
First MCP server purpose-built for financial data.
MIT
Technical analysis for any crypto: RSI, SMA, volatility, z-score, trend direction. Actionable signals included.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Crypto symbol | |
| days | No | Lookback period in days (default: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits like data sources, rate limits, or limitations on coin types. Minimal info beyond listing indicators.
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?
Single sentence front-loads key information (technical analysis, indicators, signals) with no waste.
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?
Despite listing indicators, description is brief. No output schema provided, so agent cannot infer return structure. Missing info on error handling or validity. Incomplete for a multi-indicator tool.
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 parameters are well-documented in schema. Description adds no extra meaning beyond what schema already provides (symbol, lookback days).
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?
Description clearly states it performs technical analysis on crypto, listing specific indicators (RSI, SMA, etc.) and mentions actionable signals. It distinguishes from siblings like 'price' or 'candles'.
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 use for technical analysis but does not explicitly state when to use this tool vs alternatives or provide exclusions. No comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OHLCV candlestick data for any crypto. Returns open, high, low, close for each period.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Crypto symbol | |
| days | No | Number of days of history (1, 7, 14, 30, 90, 180, 365). Default: 7 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It accurately states this is a read operation ('Get') and lists returned fields. However, it does not disclose potential rate limits, data source, or period granularity, which are relevant for correct usage.
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?
Single sentence that is front-loaded with the main action ('Get OHLCV candlestick data'). No redundant words; every part contributes to understanding.
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, description does mention return fields but omits volume (despite tool name 'candles' implying OHLCV). Missing granularity of 'period' and any behavioral constraints. Adequate but incomplete.
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?
Input schema covers both parameters with descriptions. Description adds value by clarifying the resource is crypto and specifying the returned fields (OHLC). This goes beyond the schema which only defines 'symbol' and 'days'.
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?
Description uses clear verb 'Get' and resource 'OHLCV candlestick data', specifying the output fields (open, high, low, close). It distinguishes from sibling tools like 'price' (single price) and 'market_cap' (market capitalization).
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 on when to use this tool versus alternatives (e.g., 'price' for single point, 'order_book' for depth). No 'when not to use' or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare multiple assets side by side — prices, changes, market caps.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | Comma-separated symbols (e.g., "BTC,ETH,SOL") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose whether the operation is read-only, any required permissions, or side effects, leaving the agent uninformed about behavioral traits.
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 waste. It efficiently conveys 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?
Given the tool's simplicity (1 parameter, no output schema), the description covers the basic action but lacks information about the return format or how results are presented, which is a gap for contextual completeness.
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 value by explaining what is compared (prices, changes, market caps), which goes beyond the schema's parameter description of comma-separated symbols.
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 assets side by side on prices, changes, and market caps, which distinguishes it from sibling tools like 'price' or 'market_cap' that likely handle single assets.
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 guidance is provided on when to use this tool versus alternatives like 'analyze' or 'price'. The description does not mention any conditions, exclusions, or contextual triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crypto Fear & Greed Index — market sentiment indicator. Shows last 7 days.
| 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 must fully disclose behavior. It only states it shows last 7 days but omits details like output format, units, or whether any authentication is needed.
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 extremely concise—one sentence that is front-loaded and contains no unnecessary words. Every element is essential for understanding the tool's basic function.
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 is minimally sufficient for a simple information retrieval tool. However, it lacks detail on the exact output shape or value interpretation, which could aid comprehension.
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, and schema coverage is 100% (vacuously). Per guidelines, 0 parameters yields a baseline score of 4.
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 provides the Crypto Fear & Greed Index, a market sentiment indicator, and specifies it shows the last 7 days. This uniquely identifies its purpose among siblings like 'price' or 'trending'.
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 does not explicitly guide when to use this tool versus siblings. While the purpose implies sentiment analysis, no contextual usage tips or exclusion criteria are given.
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 prices, volumes, and 24h changes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of coins to return (default: 20, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially discloses behavior by listing returned fields, but omits details like ordering direction, data freshness, or any side effects. It adds some value but lacks comprehensive behavioral context.
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 concise sentence of 13 words, front-loaded with the key action and resource. Every word adds value, with no redundancy or 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?
Given the simple input schema (one optional param) and no output schema, the description covers the main purpose and returned data types. It is slightly incomplete in specifying exact fields (e.g., coin identifiers are implied but not stated), but sufficient for a basic list tool.
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% for the single 'limit' parameter. The description does not add extra meaning beyond the schema, so it meets the baseline but does not enhance understanding of the parameter's effect beyond what is already documented.
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 action ('Get') and the specific resource ('top cryptocurrencies ranked by market cap') with data types ('prices, volumes, and 24h changes'). It effectively differentiates from sibling tools like 'price' (single coin price) or 'trending' by specifying 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?
The description does not provide guidance on when to use this tool versus alternatives like 'price' or 'trending'. No mention of use cases, prerequisites, or exclusions, leaving the agent to infer application without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live order book — top 20 bids and asks with spread. Shows market depth and liquidity.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair (BTC, ETHUSDT, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'live' and shows top 20 bids/asks but does not disclose if it's read-only, rate limits, or error handling for invalid symbols.
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 with no fluff, front-loaded with key information. Every sentence earns its place.
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?
No output schema; description does not explain return structure beyond top 20 bids/asks with spread. For a low-complexity tool, it is somewhat adequate but lacks detail on response format.
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% (one parameter 'symbol' described as trading pair). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a live order book, specifying top 20 bids and asks with spread, and mentions market depth and liquidity. It is distinct from siblings like price or candles.
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 on when or when not to use this tool versus alternatives. The description implies it's for real-time market depth but lacks comparisons or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current price, 24h change, volume, market cap for any cryptocurrency. Examples: BTC, ETH, SOL, DOGE.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Crypto symbol (BTC, ETH, SOL, DOGE, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries transparency burden. It declares it's a read operation ('Get') and lists returned fields, but does not disclose data freshness, rate limits, or response structure. Adequate for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by examples. No fluff; every word earns its place.
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 simplicity (1 param, no output schema, no annotations), description covers purpose and data fields. Lacks details on return format (e.g., JSON field names), but still fairly complete for a straightforward price lookup.
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% and parameter description is clear. Description repeats the symbol examples, adding no extra semantics beyond the schema. Baseline 3 applies as schema carries the weight.
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 current price, 24h change, volume, and market cap for any cryptocurrency, using specific verbs and resource. It distinguishes from siblings like 'candles' (historical) and 'compare' by listing exact data fields.
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 single-symbol price data and gives examples, but lacks explicit guidance on when to use this tool vs siblings like 'candles' or 'compare'. No when-not or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get trending cryptocurrencies right now — what people are searching for and trading.
| 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 must fully disclose behavioral traits. It only states the basic function without revealing any side effects, authentication needs, rate limits, or data freshness, which is insufficient for a tool with no annotation coverage.
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, well-formed sentence that conveys the tool's purpose without any redundant or extraneous words. Every word contributes to clarity.
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 simplicity (0 parameters, no annotations, no output schema), the description provides the essential purpose but lacks any additional context about output format, update frequency, or limitations. This may be sufficient for a trivial tool but offers minimal information beyond the name.
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 zero parameters, so schema coverage is 100% and the baseline is 4. The description adds no parameter information, but none is needed.
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 'Get' and the resource 'trending cryptocurrencies', specifying the temporal scope ('right now') and the data sources ('searching and trading'), which effectively distinguishes it from sibling tools like price, market_cap, and analyze.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or when not to use it, leaving the agent without decision-making support for tool selection.
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.
v0.1.0analyzecandlescomparefeargreedmarket_caporder_bookpricetrendingScored across 8 tools
Each tool targets a distinct aspect of market data: price, candles, analysis, sentiment, etc., with no overlap. An agent can easily differentiate them.
Most tool names are single-word lowercase descriptors, but 'order_book' and 'market_cap' use underscores, creating a slight inconsistency.
Eight tools cover the essential market data operations without being excessive, fitting the server's purpose well.
The toolkit includes price, candles, analysis, sentiment, order book, comparisons, trending, and market cap rankings, covering key areas with no obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Crypto market signals, technical indicators, and sentiment analysis for AI agents.
Live crypto prices, conversion, gas tracker, portfolio tools, and calculators for AI agents.
Crypto market signals and portfolio telemetry. 6 tools pay-per-call in USDC, no API key.
Open API Marketplace for AI Agents. Crypto data tools with USDC payments on Base.
