Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_get_account_status

Read-onlyIdempotent

Check if your Binance account is in good standing before automated trading. Detects flags from abuse/AML controls, helping you avoid rejected orders.

Instructions

Report whether the account is in good standing with Binance.

Calls GET /sapi/v1/account/status (SIGNED, IP weight 1). Binance flags accounts that trip abuse/AML controls (e.g. excessive order cancellation) here; a healthy account reports "Normal".

When to Use:

  • Before an automated trading run, to confirm the account is not under review.

  • Alongside binance_get_api_trading_status when diagnosing rejected orders.

When NOT to Use:

  • To read API-key permission flags — use binance_get_api_restrictions.

  • To read trading-specific locks/triggers — use binance_get_api_trading_status.

Returns: A one-line markdown status, or the raw JSON envelope with response_format="json".

Examples: params = {} params = {"response_format": "json"}

Error Handling: -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

A4.9/5.0
Behavior5/5

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

Annotations already provide readOnly/idempotent hints, and the description adds rich behavioral context: the exact endpoint, SIGNED requirement, IP weight, what 'Normal' means, output format behavior, and error code -2015 semantics. This goes well beyond the structured fields.

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 with clear sections, front-loads the purpose, and every section (When to Use, NOT to Use, Returns, Examples, Error Handling) adds value without redundancy. It is thorough yet focused.

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 simple status read with one optional parameter, the description includes endpoint details, auth requirements, rate-limit weight, return formats, error handling, and sibling differentiation. Nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema description coverage is reported as 0%, so the description must compensate. It does so by explaining the response_format behavior in 'Returns' and providing two concrete example parameter sets, making the single parameter's effect clear even if the schema already has a short property description.

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 immediately states a specific verb and resource: 'Report whether the account is in good standing with Binance.' It also names two sibling tools in 'When NOT to Use' (binance_get_api_restrictions and binance_get_api_trading_status), making the boundary clear.

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?

The 'When to Use' section gives concrete scenarios (pre-trading-run check, alongside API trading status when diagnosing rejects), and 'When NOT to Use' explicitly names alternatives for permission flags and trading locks. This leaves no ambiguity about tool selection.

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