Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_get_trade_fees

Read-onlyIdempotent

Check the maker and taker commission rates applied to your Binance account, optionally for one trading pair, to price a trade before placing it.

Instructions

Report the maker/taker commission rates that apply to this account.

Calls GET /sapi/v1/asset/tradeFee (SIGNED, IP weight 1). Without symbol Binance returns every symbol — thousands of rows — so the rendering is capped at 50 and the JSON output is clipped; pass symbol whenever you know it.

When to Use:

  • To price a trade properly before placing it.

  • To confirm a VIP-tier or BNB-discount fee change took effect.

When NOT to Use:

  • For the fee actually charged on an executed order — that is in the order's fills (binance_place_order) or in binance_get_my_trades (trade_history.py).

  • For the account-level commission rates on one symbol with the order-book context — binance_get_commission_rates (spot_account.py) reads /api/v3/account/commission.

Returns: A markdown table of symbol / maker / taker as percentages, capped at 50 rows, or the raw Binance array with response_format="json".

Examples: params = {"symbol": "BTCUSDT"} params = {}

Error Handling: -1121 means the symbol does not exist. -2015 means the key lacks Reading permission or this IP is not allowlisted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds significant context beyond that: the signed endpoint requirement, IP weight, the 50-row cap with JSON clipping behavior, and specific error codes (-1121, -2015) with their meanings. This fully discloses the tool's operational traits.

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 well-organized into clear sections (purpose, usage, returns, examples, error handling) with no redundant sentences. Every part adds value, and the most critical information (purpose and symbol behavior) is front-loaded.

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 read-only query tool, the description covers purpose, usage boundaries, return formats, parameter implications, and error handling. It also references the output schema implicitly. Nothing an agent needs to invoke it correctly is missing.

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 already provides descriptions for symbol and response_format, the description adds crucial behavioral semantics: omitting symbol returns thousands of rows and triggers capping/clipping, and response_format='json' returns the raw Binance array. This goes beyond simple schema definitions and informs correct parameter selection.

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 clearly states the tool reports maker/taker commission rates for the account, names the specific API endpoint, and explicitly distinguishes it from sibling tools like binance_get_commission_rates and binance_get_my_trades. The verb+resource is precise and unambiguous.

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?

It provides explicit 'When to Use' and 'When NOT to Use' sections, naming concrete alternatives (binance_place_order, binance_get_my_trades, binance_get_commission_rates) and the conditions under which they should be chosen. This leaves no ambiguity for the agent.

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

Deploy Server

Other Tools