Skip to main content
Glama
bybit-exchange

Bybit MCP Server

Official

getEarnAprHistory

Read-only

Fetch historical APR rates for Bybit Earn products by product and category. Provides hourly records for FlexibleSaving and daily records for OnChain, covering up to 182 days.

Instructions

Query historical daily APR for a product. Supports FlexibleSaving and OnChain.

FlexibleSaving: Returns hourly APR records.

OnChain: Returns daily APR records.

Results are returned in descending order by date/time. Maximum query range is 182 days.

Authentication is optional (public endpoint).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endTimeYes
categoryYes
productIdYes
startTimeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.11

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already mark the call as read-only/open-world; description adds meaningful behavior beyond that: FlexibleSaving vs OnChain interval, descending date ordering, 182-day maximum query range, and optional authentication. No contradictions.

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 compact, front-loaded with the core query purpose, and uses short headings and bullets to segment category behavior, ordering, range, and auth. No filler.

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

Completeness4/5

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

For a read-only 4-parameter tool with no output schema, it covers the essential call semantics: category selection, time range limit, ordering, and authentication. The only notable gaps are time format and productId provenance.

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

Parameters3/5

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

Schema has 0% description coverage, so the description must compensate. It adds meaning for category (enum values and granularity) and hints at time-window constraints, but it never explains startTime/endTime units or the meaning/source of productId. Self-descriptive parameter names keep this from being lower.

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

Purpose4/5

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

States a specific verb ('Query') and resource ('historical daily APR for a product'), and explains the two supported categories with their respective granularities. It is immediately distinguishable from vague sibling names, though it does not explicitly contrast with nearby siblings such as getEarnYieldHistory or getTokenHistoricalApr.

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

Usage Guidelines4/5

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

Clear context: describes supported categories, expected record frequency, max 182-day range, and public-auth behavior. Does not include explicit exclusions or name alternative tools, but the scope is sufficient for an agent to decide whether this tool applies.

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

Install Server

Other Tools