Provides read-only access to Binance spot market data, offering tools for fetching tickers, klines (candlesticks), order books, symbol information, and searching symbols.
Click on "Deploy 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-mcp What's the current BTCUSDT price?"
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.
A Model Context Protocol server that gives an LLM read-only access to Binance spot market data, for people who want a model to reason about real prices without giving it the ability to place an order.
A model can already be told to fetch api.binance.com/api/v3/klines itself. That
works until it doesn't, and the failures are quiet ones.
Symbols have to be guessed. Binance has 3,680 spot pairs. The name is a
concatenation with no separator, so a model writes BTC-USDT or btcusdt and gets
back HTTP 400 {"code": -1100, "msg": "Illegal characters found in parameter 'symbol'"}. That is a lowercase rejection, not a missing pair, and the model cannot
tell the difference. It retries with another guess. This server uppercases and strips
separators before the call, and it exposes a search tool so a guess can be resolved
instead of repeated.
Out-of-range limits are honoured silently. Ask /klines for 5000 candles and
Binance returns HTTP 200 with 1000 rows. Nothing in the response says it was
truncated. A model that asked for a year of hourly candles gets six weeks and
reasons about it as if it were a year. This server clamps limits itself and states
the cap in the tool schema, so the model knows what it asked for.
Rate limits are weighted, and the penalty is a ban. Binance budgets 6000
request weight per minute per IP, not 6000 requests. /exchangeInfo costs 20.
/depth costs 5 for 100 levels and 25 for 101. Asking for 5000 levels costs 250,
so twenty-four of those calls exhaust the minute. Cross the line and you get
HTTP 429; ignore the 429 and you get HTTP 418 and a temporary IP ban. A model
polling in a loop has no idea any of this is happening. This server reads the
X-MBX-USED-WEIGHT-1M header on every response and stops before the budget is
gone.
Every failure looks the same. A misspelled symbol, an exhausted rate limit and
a Binance outage all reach the model as "the tool failed". They call for three
different responses: fix the symbol, wait, and give up. This server returns a
typed error with a code and a retriable flag.
The payloads are shaped for machines that already know the schema. Numbers
arrive as strings, keys are camelCase, and the 24 hour ticker carries 21 fields.
The full /exchangeInfo document is 16.7 MB, which is not something to put near a
context window. This server renames, coerces and drops, and reduces the exchange
listing to the four fields search needs.
Related MCP server: Bybit MCP Server
Python 3.11 or newer. No API key, because nothing here needs one.
git clone https://github.com/iwaqaruddin/binance-mcp.git
cd binance-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"Confirm the checkout is sound:
ruff check . && mypy && pytest -qThe tests mock every HTTP call, so that command works offline.
Start the server by hand to see it boot. It speaks MCP over stdio, so it will look like it is hanging with no prompt. That is correct; press Ctrl-C to stop it.
binance-mcpThen point a client at it. For Claude Desktop, add this to
claude_desktop_config.json and restart the app. Use the absolute path to the
executable inside the virtualenv; the config is not run through a shell, so ~
and $PATH lookups do not apply.
{
"mcpServers": {
"binance": {
"command": "/absolute/path/to/binance-mcp/.venv/bin/binance-mcp",
"env": {
"BINANCE_MCP_MARKET_TTL_SECONDS": "2",
"BINANCE_MCP_LOG_LEVEL": "INFO"
}
}
}
}Configuration comes from the process environment. .env.example documents every
variable and its default; the server does not read a .env file itself, so set
values in the env block above or export them before launching. All of them have
working defaults, so the env block can be omitted entirely.
Tool | Arguments | Returns |
|
| Last price and the 24 hour window: open, high, low, price change and percent, weighted average, best bid and ask with sizes, volume in both assets, trade count, window start and end. |
|
| OHLCV candles, oldest first, as positional rows plus a |
|
| A book snapshot: |
|
| Trading status, base and quote assets, precisions, permitted order types, and the tick size, lot step size and minimum notional as exact strings. |
|
| Ranked symbol matches with base asset, quote asset, status and a score, plus the number of symbols searched. |
symbol is case-insensitive and separators are stripped, so btc/usdt and
BTCUSDT are the same request. interval is one of 1s, 1m, 3m, 5m, 15m,
30m, 1h, 2h, 4h, 6h, 8h, 12h, 1d, 3d, 1w, 1M.
Every failed call returns the same shape instead of a message:
{
"error": "rate_limited",
"message": "Local request-weight budget is exhausted for this minute.",
"retriable": true,
"retry_after_seconds": 41.2,
"used_weight": 4802,
"weight_limit": 6000,
"remaining_weight": 1198
}error is one of invalid_symbol, invalid_argument, rate_limited,
upstream_unavailable or internal_error.
There is no order placement, no account data and no signing code. The rejected
alternative was one server with a BINANCE_API_KEY and a --enable-trading flag,
which is how most exchange integrations are built.
The trade-off is that this repo cannot grow into a trading agent. That is the point. A server that can trade has to be trusted with prompt injection as a threat model: any text the model reads becomes a possible instruction to sell. A server with no key and no write path fails that attack by construction, and the security argument is a one-line audit rather than a policy document. Anyone who wants execution should build a separate server with its own approval path, and should have to think about it separately.
Responses are held in a fixed-size in-process dictionary: two seconds for market data, sixty for exchange metadata.
No cache at all was the first alternative. It loses because models re-ask. A model
comparing four pairs will often fetch the same ticker twice in one turn, and each
repeat spends weight on data that has not changed. The second alternative was
Redis, which buys a cache shared across processes and survives restarts. It loses
on operational cost: it turns a pip install into a service dependency, and a
market-data cache with a two-second lifetime has almost nothing to share. The
trade-off accepted is that every process keeps its own copy and a restart starts
cold. At this TTL, a cold start costs one request.
The market TTL is 2s rather than something longer because that is roughly the window in which a stale price is still the same price for reasoning purposes. It is configurable, and raising it is the correct move if several clients poll one symbol.
Every response carries the weight spent in the current minute. The server tracks
that number, and once the configured share of the budget is spent it waits for the
window to roll over. If the wait is longer than MAX_BACKOFF_SECONDS it fails the
call instead and reports how much budget is left.
The alternative was retry with exponential backoff on 429, which is the default
answer for most HTTP clients. It is the wrong answer here. Binance escalates
repeated 429s from one IP into an HTTP 418 ban, so a retry loop converts a
recoverable throttle into an outage that outlives the process. This server never
retries a 429. It treats one as evidence the budget is gone and blocks the next
call locally.
Two trade-offs come with this. A tool call can block for up to five seconds before
returning, which is visible latency inside a client's timeout. And the local
estimate can drift, because other processes on the same IP spend from the same
budget without this server seeing it. The header corrects the count on every
response, so drift lasts one request. Setting BINANCE_MCP_WEIGHT_LIMIT below 6000
is the fix when the IP is genuinely shared.
No moving averages, no RSI, no spread, not even a mid price from the order book this server just fetched.
The alternative is a get_rsi tool, and it is the single most requested feature of
servers like this. It loses on two counts. Every indicator has parameters and
conventions — Wilder smoothing or simple, close or typical price, how to seed the
first value — and a tool that picks silently produces numbers the caller cannot
reconcile with their charting platform. Worse, it moves the analysis inside an
opaque function: the model reports RSI 71 and neither it nor the user can see which
candles produced it. Serving the candles keeps the arithmetic in the transcript
where it can be checked.
The trade-off is real and it is token cost. A model computing a 200-period moving average has to read 200 candles to do it. That is the price of an auditable number, and it is why the next decision exists.
get_klines returns [[1700000000000, 67000.1, ...], ...] with a columns list,
rather than a list of objects with nine named keys each.
The alternative is self-describing objects, which are easier to read in a log and need no lookup. It loses on arithmetic: 500 candles as objects spends roughly a third of its tokens repeating the same nine keys, and context is the scarce resource in a tool that exists to feed a model. The trade-off is that a row is meaningless without its header, so the header ships in the same response and the output schema pins the type of every position.
This is the one place where the wire format is optimised for the consumer rather than for readability, and it is contained to a single tool.
Prices, volumes and percentages are converted to JSON numbers. Tick size, lot step size and minimum notional stay strings, exactly as Binance published them.
Converting everything to numbers was the alternative, and it is more consistent.
It loses where exactness is load-bearing. A tick size of 0.01000000 describes a
decimal grid, and a value that survives a float round-trip a few times stops
landing on that grid; an order priced off a drifted tick size is rejected by the
exchange or, worse, quietly rounded. Leaving everything as strings was the other
alternative, and it loses because it makes the model parse before it can compare,
which it does inconsistently.
The trade-off accepted: a quote volume above roughly 10^15 loses its last digits to float representation. No spot pair is close, and the failure is a rounding error in a number nobody trades on, rather than a rejected order.
You are polling faster than once every couple of seconds. The cache returns identical data within its TTL, so a tighter loop gets the same answer while still paying MCP round-trip cost. If you need every tick, you need the websocket streams and this server does not have them.
You need sub-second freshness. A cached ticker can be two seconds old, an order book snapshot is stale the moment it is serialised, and the request itself takes tens of milliseconds. Do not build anything that acts on a price this returns. Market making, arbitrage, and stop placement all need a direct websocket feed and a clock you control.
You need private account data. Balances, open orders, fills, positions and funding history all require a signed request. There is no code path here that can produce one.
You want the model to execute. No tool here places, modifies or cancels an order, and adding one is out of scope rather than not yet done.
You need the full order book. Depth is capped at 100 levels per side, which is a slice of the book. Reconstructing a full book means the depth snapshot endpoint plus the diff stream, which is a different program.
You are running this in a multi-tenant service. The weight budget is tracked
per process, and the exchange enforces it per IP. Several instances behind one
egress IP will oversubscribe the budget until a 429 arrives. Lowering
BINANCE_MCP_WEIGHT_LIMIT divides the budget but does not coordinate it.
The cache does not deduplicate concurrent identical requests. Two tool calls for the same symbol arriving in the same event-loop tick both reach the network, and the second populates a cache entry the first already wrote.
There is no request coalescing or coordination across processes, for the reason in the section above.
Spot only. Futures, options and margin endpoints live on different hosts with different weight budgets and are not covered.
search_symbols matches ticker strings, not names. A query for bitcoin finds
nothing; btc finds everything. Ranking prefers pairs quoted in the more liquid
stablecoins, which is a judgement call about the current spot market rather than a
property of the data.
Klines are the most recent N candles. There is no start or end time argument, so historical windows that do not end at the present cannot be requested.
The weight table for each endpoint is hardcoded. If Binance repriced an endpoint, the first request of a minute would be mis-estimated. The response header corrects it immediately, so the consequence is one optimistic request rather than a ban.
Single-flight deduplication of in-flight identical requests, which is the cheapest remaining weight saving.
A start_time and end_time pair on get_klines, so historical windows can be
requested without walking backwards.
Optional --transport http so one server process can back several clients, which
also makes a shared weight budget tractable.
Testnet documentation. BINANCE_MCP_BASE_URL already points at
testnet.binance.vision if you set it, but nothing here verifies that the testnet
symbol list behaves the same way.
MIT. See LICENSE.
Historical OHLCV candles for one symbol, oldest first, up to 500 per call. Rows are positional; the 'columns' field names them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of most recent candles, oldest first. Clamped to 500; larger values are silently reduced rather than rejected. | |
| symbol | Yes | Trading pair, base asset first, no separator. Case-insensitive; BTC/USDT and btc-usdt both normalise to BTCUSDT. | |
| interval | No | Candle width. Defaults to 1h. | 1h |
| Name | Required | Description |
|---|---|---|
| symbol | Yes | |
| candles | Yes | Oldest first. Times are epoch ms UTC. |
| columns | No | |
| interval | Yes | Kline intervals accepted by the spot API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral details beyond annotations: results are oldest-first, limited to 500, rows are positional, and the 'columns' field names them. This meaningfully helps an agent interpret the response.
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 carry all essential information with no filler. The core purpose and ordering are front-loaded, and the note about positional rows is a valuable, compact addition.
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 rich annotations, full schema coverage, and presence of an output schema, the description is sufficient. It tells the agent what the tool returns, how results are ordered, and where field names come from, leaving no critical gap for this relatively simple 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%, so the schema fully documents symbol, limit, and interval. The description adds little parameter-specific meaning beyond the schema; 'up to 500 per call' restates the limit constraint already present in the schema.
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 specific verb and resource: returns historical OHLCV candles for one symbol. It also clarifies ordering (oldest first) and the 500-candle cap, distinguishing it from siblings like get_ticker and get_order_book, which serve different market-data purposes.
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 makes clear this is for historical candle data, giving an agent context for when to choose it over ticker or order book tools. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current order book snapshot for one symbol, up to 100 levels per side. A snapshot, not a stream: it is stale the moment it is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Price levels per side. Clamped to 100; larger values are silently reduced rather than rejected. | |
| symbol | Yes | Trading pair, base asset first, no separator. Case-insensitive; BTC/USDT and btc-usdt both normalise to BTCUSDT. |
| Name | Required | Description |
|---|---|---|
| asks | Yes | Ascending by price. |
| bids | Yes | Descending by price. |
| symbol | Yes | |
| last_update_id | Yes | Binance sequence id for this snapshot. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly and idempotent hints, and the description adds meaningful behavioral context: up to 100 levels per side, snapshot semantics, and immediate staleness. This goes beyond the structured annotations and helps the agent avoid misuse.
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 tight sentences with no filler. The core scope is front-loaded and the staleness caveat is immediately useful. Every sentence contributes value.
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 output schema, input schema, and annotations, the description is complete enough. It covers the key behavioral caveat, limits, and scope, so an agent can select and invoke the tool correctly.
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%, with symbol and depth already well documented. The description reinforces 'one symbol' and level limits but does not add significant new parameter semantics beyond the schema.
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 states a clear verb/resource: 'Current order book snapshot for one symbol'. It distinguishes the order book from siblings like get_ticker and get_klines by naming the exact data object and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: when a current order book snapshot for a single symbol is needed. It also warns that it is not a stream, which sets expectations, though it does not explicitly name alternatives or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trading rules for one symbol: status, base and quote assets, precisions, tick size, lot step size and minimum notional.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair, base asset first, no separator. Case-insensitive; BTC/USDT and btc-usdt both normalise to BTCUSDT. |
| Name | Required | Description |
|---|---|---|
| rules | Yes | Order constraints, as published. Strings, so the values stay exact. |
| status | Yes | TRADING, HALT, BREAK, or another exchange status. |
| symbol | Yes | |
| base_asset | Yes | |
| order_types | Yes | |
| permissions | Yes | |
| quote_asset | Yes | |
| filter_types | Yes | Every filter Binance publishes for this symbol, including ones not parsed. |
| base_asset_precision | Yes | |
| quote_asset_precision | Yes | |
| is_spot_trading_allowed | Yes | |
| is_margin_trading_allowed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific data fields returned, which is useful context, but it does not disclose any additional behavioral traits such as symbol validation behavior, rate limits, or state changes.
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 sentence that leads with the core purpose ('Trading rules for one symbol') and then lists the included fields. Every word earns its place; 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?
For a one-parameter, read-only tool with an output schema and rich annotations, the description is largely complete. It names the key returned information categories. It could have added how invalid symbols are handled or referenced a sibling for symbol discovery, but these are minor 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 schema description for the single parameter 'symbol' is thorough, covering format, ordering, case sensitivity, and normalization, so schema coverage is 100%. The tool description adds no param semantics beyond that, so baseline 3 applies.
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 the tool returns trading rules for one symbol and enumerates the specific attributes (status, base/quote assets, precisions, tick size, lot step, minimum notional). This clearly distinguishes it from siblings like get_ticker or get_order_book by naming the resource and content.
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 statement about when to use this tool versus alternatives is provided. Sibling tools exist (get_ticker, get_klines, get_order_book, search_symbols), but the description does not mention them or give exclusion conditions, so an agent must infer usage from the tool name and field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current price and 24 hour rolling statistics for one symbol: last, open, high, low, best bid and ask, volume in both assets, and trade count.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair, base asset first, no separator. Case-insensitive; BTC/USDT and btc-usdt both normalise to BTCUSDT. |
| Name | Required | Description |
|---|---|---|
| symbol | Yes | |
| trades | Yes | |
| ask_qty | Yes | |
| bid_qty | Yes | |
| ask_price | Yes | |
| bid_price | Yes | |
| low_price | Yes | |
| open_time | Yes | Window start, epoch ms UTC. |
| close_time | Yes | Window end, epoch ms UTC. |
| high_price | Yes | |
| last_price | Yes | |
| open_price | Yes | |
| base_volume | Yes | Volume in the base asset. |
| price_change | Yes | |
| quote_volume | Yes | Volume in the quote asset. |
| prev_close_price | Yes | |
| weighted_avg_price | Yes | |
| price_change_percent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds the 24-hour rolling window and the returned fields, but it does not disclose update latency, staleness, or error behavior. This is acceptable given the strong annotation coverage, and there is no contradiction.
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 sentence with the purpose front-loaded and every listed field earning its place. There is no filler, vague phrasing, or redundant restatement of the tool name.
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 presence of an output schema, strong annotations, and a single fully documented parameter, the description provides enough context for an agent to invoke the tool correctly for a single-symbol ticker request. The only notable gap is sibling routing, which is already addressed in the usage_guidelines score.
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 the schema already documents the symbol parameter thoroughly, including formatting, case-insensitivity, and normalization examples. The description only reinforces that one symbol is accepted, which adds no meaningful semantic value beyond the schema.
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 identifies the resource (a single symbol's ticker) and the specific data returned: current price, 24-hour rolling statistics, best bid/ask, volume, and trade count. It lacks an explicit verb like 'retrieves' or 'returns', and it does not explicitly name sibling tools, though 'one symbol' and '24 hour rolling statistics' help separate it from get_klines and get_order_book.
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 this tool is for current/24-hour snapshot data for one symbol, but it gives no explicit when-to-use or when-not-to-use guidance and names no alternatives among the sibling tools. An agent must infer that get_klines is for historical candles and get_order_book is for depth data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find symbols by partial name or asset code. Use this to resolve a vague pair such as 'sol usd' into an exact symbol before calling other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches to return. Clamped to 25. | |
| query | Yes | Free text matched against symbol names and asset codes. 'bitcoin' will not match; 'btc' will. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| matches | Yes | |
| symbols_searched | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds the partial-match behavior and the resolution role, modestly enriching beyond the annotations, but leaves matching details like case sensitivity to the parameter description.
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 zero waste: the first delivers the core purpose, the second delivers usage guidance with a concrete example. Purpose is front-loaded and every clause 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?
The tool is simple (2 params, 1 required), and the combination of description, fully-documented schema, comprehensive annotations, and an output schema leaves nothing material uncovered. An agent has everything needed to decide when to call it and what result to expect.
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%: query documents matching behavior with examples ('bitcoin' will not match; 'btc' will), and limit documents its default and clamping. With the schema doing the heavy lifting, the baseline 3 applies; the description adds no additional parameter-specific detail.
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?
States a specific verb and resource: 'Find symbols by partial name or asset code.' The matching mechanism is explicit, and the phrase 'before calling other tools' positions it as the discovery step distinct from siblings like get_ticker and get_symbol_info, which operate on already-resolved symbols.
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?
Explicitly states when to use it: 'Use this to resolve a vague pair such as "sol usd" into an exact symbol before calling other tools,' giving both a trigger condition and a concrete example. It provides clear workflow context but doesn't name specific alternative tools or state when not to use it.
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.0get_klinesget_order_bookget_symbol_infoget_tickersearch_symbolsScored across 5 tools
Each tool targets a clearly distinct data surface: current statistics, historical candles, order book depth, symbol metadata, and symbol resolution. There is no meaningful overlap or ambiguity between them.
All tools follow a consistent get_ or search_ pattern with clear resource nouns: get_ticker, get_klines, get_order_book, get_symbol_info, search_symbols. No mixed conventions or vague verbs.
Five tools is well-scoped for a read-only Binance market data server. Each tool provides a distinct, necessary capability without unnecessary bloat or thinness.
The tool surface covers the core public market data needs: symbol discovery, trading rules, current pricing, historical candles, and order book depth. There are no obvious gaps for the apparent read-only market data scope.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Read-only MCP server for Robinhood Chain token discovery, research, and due diligence via GMGN.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…