Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_get_earn_flexible_positions

Read-onlyIdempotent

Retrieve your Simple Earn Flexible subscriptions with live APR, tiered rates, and rewards. Decide whether to redeem or top up based on current returns.

Instructions

List the caller's Simple Earn Flexible subscriptions and their live APR.

Calls GET /sapi/v1/simple-earn/flexible/position (SIGNED, USER_DATA). IP weight 150 per call (S1 spec, 2024-10 — Binance's docs site renders the Simple Earn pages empty, so this weight was not re-verified; treat it as approximate).

When to Use:

  • To see which Flexible products you are subscribed to, how much is deposited, and the current (and tiered, when Binance returns tiers) annual percentage rate.

  • Before deciding whether to redeem or top up a Flexible position.

When NOT to Use:

  • For time-locked Simple Earn products — use binance_get_earn_locked_positions.

  • For a single aggregate balance across all Earn products — use binance_get_earn_account.

Returns: A markdown list (or JSON with response_format="json") of positions: asset, product id, deposited amount, latest APR, tiered APR breakdown (when present), yesterday's airdrop rate, redeemability, auto-subscribe flag, and cumulative rewards (yesterday, real-time, bonus, total).

Pagination: limit (Binance size, max 100, default 20) and offset (house-style; see the module docstring for the offset -> current page-number mapping). total from Binance drives has_more. Display is additionally capped at MAX_DISPLAY_ROWS (50) even when limit asked for more — a truncation note is appended when rows were dropped.

Examples: params = {"asset": "USDT", "limit": 20} params = {"product_id": "BTC001"}

Error Handling: -2015 means the key lacks Simple Earn / USER_DATA permission, or this machine's IP is not on the key's allowlist. An empty rows list means no Flexible subscriptions exist (or the asset/product_id filter matched nothing).

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?

The description goes well beyond the read-only, idempotent, non-destructive annotations by disclosing the SIGNED USER_DATA endpoint, approximate IP weight, pagination behavior, the `MAX_DISPLAY_ROWS` truncation with a note, and specific error semantics like -2015 and empty `rows` meaning no matching subscriptions. This is substantial behavioral context that annotations alone do not provide.

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 long but well-organized with clear headings, front-loaded purpose, and each section earning its place: use cases, non-use cases, returns, pagination, examples, and error handling. No filler or repetition.

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?

Given the tool's complexity—auth requirements, pagination quirks, output format options, error codes, and sibling differentiation—the description covers everything an agent needs to call it correctly. The output schema and annotations handle the remaining structured details, so nothing essential 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?

Even though the top-level `params` wrapper lacks a description, the nested schema already documents each field, and the description adds crucial semantics: the `offset` to `current` page-number conversion, `limit` as Binance `size`, the `response_format` values, and concrete examples for `asset` and `product_id`. This fully compensates for any schema-level coverage gap.

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 opens with a specific verb and resource: 'List the caller's Simple Earn Flexible subscriptions and their live APR.' It clearly distinguishes itself from sibling tools by naming what it is not, such as locked positions and aggregate account balances.

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 direct routing guidance, naming `binance_get_earn_locked_positions` for locked products and `binance_get_earn_account` for aggregate balances. This leaves no ambiguity about when this tool should be selected over its siblings.

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