Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_get_earn_locked_positions

Read-onlyIdempotent

List your Binance Simple Earn Locked positions to view APY, duration, accrued days, and redeem dates. Filter by asset or position ID to decide whether to auto-renew or opt out.

Instructions

List the caller's Simple Earn Locked subscriptions and their APY/redeem dates.

Calls GET /sapi/v1/simple-earn/locked/position (SIGNED, USER_DATA). IP weight 150 per call (S1 spec, 2024-10 — same unverified caveat as binance_get_earn_flexible_positions; treat it as approximate).

When to Use:

  • To see time-locked Earn positions: duration, accrued days, APY, and redeem date.

  • Before deciding whether to let a position auto-renew or opt out.

When NOT to Use:

  • For on-demand redeemable positions — use binance_get_earn_flexible_positions.

  • For a single aggregate balance — use binance_get_earn_account.

Returns: A markdown list (or JSON) of positions: asset, position id, project id, amount, APY, duration/accrued days, reward asset, purchase and redeem dates, and the renewable/auto-renew flags.

Pagination: Same limit/offset -> Binance size/current mapping as binance_get_earn_flexible_positions (see the module docstring).

Examples: params = {"asset": "AXS"} params = {"position_id": "123123"}

Error Handling: -2015 as above (permission or IP allowlist). An empty rows list means no Locked subscriptions match the filters.

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.8/5.0
Behavior5/5

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

Goes far beyond annotations: discloses signed endpoint, IP weight with caveat, pagination mapping, specific error code (-2015), empty-rows semantics, and response format. All consistent with readOnlyHint/idempotentHint.

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

Conciseness4/5

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

Well-structured with clear section headers and no filler. Slightly long but every paragraph serves a purpose (use cases, returns, pagination, examples, errors).

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?

Covers all necessary invocation details: filters, pagination, errors, response representation, and logical use case. With an output schema present, nothing essential 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 already documents each parameter thoroughly, so baseline is 3. The description adds usage examples (asset, position_id) and a cross-reference for pagination mapping, offering extra guidance beyond the 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?

States a specific action and resource: 'List the caller's Simple Earn Locked subscriptions and their APY/redeem dates.' Clearly differentiates from siblings by explicitly naming what it is not for (flexible positions, account aggregate).

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?

Provides explicit 'When to Use' and 'When NOT to Use' sections, naming sibling tools and the exact conditions to choose them. This is textbook usage guidance.

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