Provides tools for retrieving live and historical market data from Binance, including current price, 24h statistics, and OHLC candles for any trading pair.
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., "@binance-market-mcp-server what's the current price of BTCUSDT and its 24h change?"
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 (Model Context Protocol) server that gives Claude live and historical Bitcoin (or any Binance pair) market data — the data layer for a regime-switching DCA signal system. It does not compute momentum, EGARCH, or any signal logic itself; it fetches clean price data, and the analysis happens downstream in the skill/prompt that consumes it.
Two tools, backed by Binance's free public REST API (no key or signup required):
binance_get_current_priceLive snapshot: last price, 24h change (absolute + %), 24h high/low, 24h
volume. Defaults to BTCUSDT but accepts any Binance pair.
binance_get_historical_ohlcHistorical daily/hourly/weekly OHLC candles for a date range. Handles
pagination transparently past Binance's 1000-candle-per-request cap (returns
up to 2,000 candles per call; narrow the date range if you need more).
Binance's BTCUSDT history begins 2017-08-17 — covers the 2020 and 2024
halving cycles in full, most of the 2017–2018 cycle.
Both tools are read-only (no orders, no account access — this hits Binance's public market-data endpoints only, nothing that requires an API key).
Related MCP server: Binance Cryptocurrency MCP
CoinGecko's free Demo tier only gives ~1 year of historical daily data — not enough for multi-year cycle backtesting. Binance's public klines endpoint gives free, keyless access to daily candles back to 2017, which is what a 4+ year DCA horizon backtest actually needs.
binance-market-mcp-server/
├── package.json
├── tsconfig.json
├── src/
│ ├── index.ts # entry point, stdio + HTTP transport
│ ├── types.ts # shared TS interfaces
│ ├── constants.ts # API base URL, limits, defaults
│ ├── tools/market.ts # tool registration + handlers
│ ├── services/binance-client.ts # Binance API client, pagination, errors
│ └── schemas/market.ts # Zod input validation
└── dist/ # compiled output (after `npm run build`)npm install
npm run build
# stdio mode (for Claude Desktop / Claude Code local config)
npm start
# HTTP mode (for remote/claude.ai custom connector)
TRANSPORT=http PORT=3000 npm startQuick manual test once running in HTTP mode:
curl -X POST http://localhost:3000/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"test","version":"1.0.0"}}}'You should get back a serverInfo block confirming the handshake. This part
was verified in the build sandbox. What was NOT verified in the sandbox:
actual live calls to the Binance API (the sandbox's network whitelist
doesn't include api.binance.com). First real end-to-end test — an actual
binance_get_current_price call hitting live Binance — needs to happen
either locally on your machine or after deployment. Do this before trusting
the server for anything real.
Any Node-friendly host with a free tier works. Two straightforward options:
Push this folder to a GitHub repo.
On render.com: New → Web Service → connect the repo.
Build command: npm install && npm run build
Start command: npm start
Add environment variable: TRANSPORT=http (Render sets PORT itself).
Deploy. Your MCP endpoint will be https://<your-app>.onrender.com/mcp.
Note: Render's free tier spins down after inactivity — first request after idle will be slow (cold start, ~30-50s). Fine for a weekly manual check-in, not for anything latency-sensitive.
Same idea — connect repo, set TRANSPORT=http, Railway auto-detects Node
and runs npm run build && npm start. Railway's free tier has usage-hour
limits rather than spin-down; check current limits before committing to it
long-term.
Settings → Connectors → Add custom connector → paste your deployed
/mcp URL. No authentication is configured on this server (it's read-only
public market data) — if you want to restrict access, add an API-key check
in src/index.ts before connecting it to anything shared.
Whale wallet / on-chain data: not covered by this server. Flagged earlier as a free-tier data gap — needs a separate connector once that source is picked.
Other symbols: already generalized — symbol param works for any
Binance pair, not just BTCUSDT.
Rate limits: Binance public endpoints allow generous request volume for this use case (weekly checks + occasional backtest pulls). No API key needed. If you scale this to many symbols/high frequency, revisit.
Get the current price and 24-hour trading stats for a crypto trading pair from Binance.
This tool fetches a live snapshot: last traded price, 24h price change (absolute and %), 24h high/low, and 24h volume. It does NOT return historical data — use binance_get_historical_ohlc for that.
Args:
symbol (string, optional): Trading pair, e.g. "BTCUSDT". Defaults to "BTCUSDT".
Returns: { "symbol": string, "price": number, // last traded price "price_change_24h": number, // absolute change over 24h "price_change_percent_24h": number, // % change over 24h "high_24h": number, "low_24h": number, "volume_24h_base": number, // volume in base asset (e.g. BTC) "volume_24h_quote": number, // volume in quote asset (e.g. USDT) "as_of": string // ISO 8601 timestamp of this snapshot }
Examples:
Use when: "what's the current BTC price" -> symbol="BTCUSDT" (or omit, it's the default)
Use when: "check ETH price" -> symbol="ETHUSDT"
Don't use when: you need price history over time (use binance_get_historical_ohlc)
Error Handling:
Returns "Error: ..." text if the symbol is invalid or Binance is rate-limiting.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Trading pair symbol in Binance format, e.g. "BTCUSDT", "ETHUSDT". Defaults to "BTCUSDT". | BTCUSDT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds meaningful behavioral context: it is a 'live snapshot', will 'NOT return historical data', and error handling returns 'Error: ...' text when the symbol is invalid or Binance is rate-limiting. This goes beyond the annotations and clarifies the tool's runtime behavior.
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 well-structured with sections for Args, Returns, Examples, and Error Handling. It is front-loaded with the main purpose, and each section serves a clear function. Despite being longer than a one-liner, every part is necessary given the lack of an output schema.
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?
With no output schema, the description fully documents the return object shape, including field names and comments. It also covers error handling, parameter defaults, and explicitly differentiates from the sibling tool. For a tool with a single optional parameter, this is 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%, with a clear description of 'symbol' including default and pattern. The description's Args section largely repeats this, but the Examples section adds concrete usage-to-value mappings (e.g., 'check ETH price' -> symbol='ETHUSDT'), which helps an agent map natural language to the parameter. This adds modest value over the schema, so a 4 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 states a clear verb and resource: 'Get the current price and 24-hour trading stats for a crypto trading pair from Binance.' It explicitly distinguishes from the sibling tool by stating 'It does NOT return historical data — use binance_get_historical_ohlc for that.' This is specific and 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 provides explicit when-to-use examples ('what's the current BTC price', 'check ETH price') and a clear exclusion: 'Don't use when: you need price history over time (use binance_get_historical_ohlc).' This gives strong selection guidance relative to the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical OHLC (open/high/low/close) candles for a crypto trading pair from Binance, for a given date range and interval.
Use this to build price series for indicator calculation (momentum, moving averages, volatility models like EGARCH) or backtesting. Automatically paginates past Binance's 1000-candle-per-request limit. Caps total candles returned at 2000 per call — if your range would exceed that, the response is truncated and "truncated": true is set; split the request into smaller date ranges if you hit this.
Args:
symbol (string, optional): Trading pair, e.g. "BTCUSDT". Defaults to "BTCUSDT".
interval (string, optional): Candle size — "1h", "4h", "1d", or "1w". Defaults to "1d".
start_date (string, required): Start date, format YYYY-MM-DD. BTCUSDT data begins 2017-08-17.
end_date (string, required): End date, format YYYY-MM-DD.
Returns: { "symbol": string, "interval": string, "requested_start": string, "requested_end": string, "candle_count": number, "truncated": boolean, // true if more candles existed than were returned "note": string (optional), // present if truncated or range predates available data "candles": [ { "open_time": string, // ISO 8601 "open": number, "high": number, "low": number, "close": number, "volume": number, "close_time": string, // ISO 8601 "quote_volume": number, "trade_count": number } ] }
Examples:
Use when: "get me 5 years of daily BTC prices" -> symbol="BTCUSDT", interval="1d", start_date="2020-01-01", end_date="2025-01-01"
Use when: "weekly BTC candles for the last 2 years" -> interval="1w" with an appropriate date range
Don't use when: you just need the current price (use binance_get_current_price)
Error Handling:
Returns "Error: ..." text if dates are malformed, start is after end, or Binance is rate-limiting.
If start_date predates 2017-08-17, the response will include a "note" explaining the series starts later than requested.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Trading pair symbol in Binance format, e.g. "BTCUSDT". Defaults to "BTCUSDT". | BTCUSDT |
| end_date | Yes | End date (inclusive), format YYYY-MM-DD, e.g. "2024-12-31". | |
| interval | No | Candle interval. One of: 1d, 1w, 4h, 1h. Defaults to "1d" (daily), which is what most momentum/volatility backtesting needs. | 1d |
| start_date | Yes | Start date (inclusive), format YYYY-MM-DD, e.g. "2020-01-01". Binance BTCUSDT history begins 2017-08-17; earlier dates return no data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds major behavioral context: automatic pagination past Binance's 1000-candle limit, a 2000-candle cap with a 'truncated' flag, error handling for malformed dates/rate limits, and behavior for dates before available data. No contradiction with annotations.
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 well-structured with clearly labeled sections (Args, Returns, Examples, Error Handling). Every sentence serves a purpose—pagination, truncation, and error behavior are all disclosed without fluff. Though lengthy, it is information-dense and front-loaded with 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?
With no output schema, the description provides a detailed Returns block showing exact fields and types, plus a note field explanation. It covers edge cases (truncation, pre-2017 data) and error conditions, making invocation reliable. This is unusually complete for a read-only 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 descriptions already cover all four parameters (100% coverage), giving baseline 3. The description adds value through usage examples that map natural language queries to specific parameter values, and offers interval guidance ('1d' for most momentum/volatility backtesting). It also clarifies inclusive dates and data availability, though it largely restates schema info.
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 opens with a specific verb and resource: 'Get historical OHLC candles for a crypto trading pair from Binance.' It clearly distinguishes from the sibling tool via the contrast with binance_get_current_price, explicitly stating 'Don't use when: you just need the current price.'
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 explicit 'Use when' examples for price series construction and explicitly contrasts with the current-price tool. It also recommends appropriate intervals for backtesting, such as '1d' for momentum/volatility. This goes beyond generic guidance to actionable selection criteria.
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.0binance_get_current_pricebinance_get_historical_ohlcThe two tools have completely distinct purposes: one retrieves historical OHLC candles, the other fetches current price and 24h stats. There is no overlap or ambiguity between them.
Both tools follow the identical binance_ verb_noun pattern (get_historical_ohlc and get_current_price), making the naming predictable and clear.
At 2 tools, the server is minimal but well-scoped for the stated market-data purpose. Each tool covers a fundamental need (current quote vs. historical series), so the count is appropriate though slightly thin.
The two tools cover the core market-data needs: live price snapshot and historical candle data. Minor gaps exist (e.g., no order book, no multi-symbol endpoint), but the surface is coherent and sufficient for many use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Binance - 340 tools for market data, order books, and trading pairs
Crypto market signals and portfolio telemetry. 6 tools pay-per-call in USDC, no API key.
Live and historical cryptocurrency prices via CoinGecko free API.
Real-time crypto market data: candles, tickers, orderbooks across 13+ exchanges via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/picjhoe-dev/binance-market-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server