amazing-binance-mcp

Overview Schema Source Related Servers Discussions Admin

binance_get_convert_pairs

Read-onlyIdempotent

Verify accessible convertible asset pairs and their min/max amounts to confirm a conversion is possible before requesting a quote.

Instructions

List the convertible asset pairs and their per-pair minimum/maximum amounts.

Calls GET /sapi/v1/convert/exchangeInfo — unauthenticated (no key needed) but IP weight 3000 of a 12,000/min budget, so four unfiltered calls exhaust a minute. The pair list barely changes: cache the answer and pass from_asset/to_asset to keep the response small.

When to Use:

Before quoting, to check a pair is convertible at all and that the amount you plan to convert sits between fromAssetMinAmount and fromAssetMaxAmount.
To find what a given asset can be converted into (from_asset="BTC").

When NOT to Use:

To get a price — that is binance_get_convert_quote (a quote reserves a ratio).
To read spot symbol filters — that is binance_get_exchange_info; convert pairs and spot trading pairs are different lists with different rules.

Returns: One row per pair: from → to plus the min/max amount on both legs. Markdown display is capped at 100 pairs with a note to narrow the filter; response_format="json" carries every row returned.

Examples: params = {"from_asset": "BTC"} params = {"from_asset": "BTC", "to_asset": "USDT"}

Error Handling: 429 means the IP weight budget is gone — wait out Retry-After rather than retrying; this single endpoint is 3000 weight per call.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses unauthenticated access, IP weight of 3000 out of a 12,000/min budget, the rarely-changing pair list with caching advice, the markdown 100-pair cap, JSON behavior, and 429 handling with `Retry-After`. This gives an agent important runtime behavior that annotations alone do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average, but every section earns its place: purpose, endpoint, rate limit, caching, when-to-use, when-not-to-use, return behavior, examples, and error handling. It is organized with clear headers and front-loaded with the core purpose and critical rate information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list tool with non-obvious rate limits and close sibling tools, the description covers all necessary context: start from the key endpoint, common usage cases, alternative tools, response shape, filter examples, and error handling. Nothing critical is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema coverage signal is 0% for the top-level `params` wrapper, the description compensates thoroughly by explaining why `from_asset`/`to_asset` should be used, providing concrete examples, and describing how `response_format` affects output. This is exactly the semantic guidance an agent needs beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'List the convertible asset pairs and their per-pair minimum/maximum amounts.' It clearly identifies the endpoint (`GET /sapi/v1/convert/exchangeInfo`) and differentiates from siblings by exactly naming what the tool is not for, such as `binance_get_convert_quote` and `binance_get_exchange_info`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'When to Use' and 'When NOT to Use' sections give concrete scenarios: checking convertibility and amount bounds before quoting, or discovering available conversions via `from_asset`. It also names the alternative tools and the conditions under which they should be used instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server