Skip to main content
Glama
Bitcompare MCP Server

Bitcompare MCP Server

Official

Historical rates

get_rate_history
Read-onlyIdempotent

Retrieve historical rate timeseries for a crypto symbol to analyze past yield trends; recent points are per-tick, older points daily, limited by plan and available data.

Instructions

Historical rate timeseries for a symbol. Recent history (~30 days) is per-tick; older history is daily granularity. Depth is clamped to your plan (up to 365 days on Pro) and bounded by how far back data has been recorded. (Current plan: up to 7 days of history.)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "get_rate_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoDays of history. Clamped server-side to your plan (Free 7, Starter 30, Growth 90, Pro 365, Enterprise 1825) and bounded by available data. Points within ~30 days are per-tick; older points are daily.
symbolYesCoin symbol, case-insensitive
providerNoProvider slug to scope to, case-insensitive

Output Schema

NameRequiredDescriptionDefault
dataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.2.0
    • changedInput schema / properties / days / description
      Previous value: -"Days of history. Clamped to the plan limit (7 Free, 1825 Pro)."New value: +"Days of history. Clamped server-side to your plan (Free 7, Starter 30, Growth 90, Pro 365, Enterprise 1825) and bounded by available data. Points within ~30 days are per-tick; older points are daily."
    • changedInput schema / properties / provider / description
      Previous value: -"Provider slug to scope to"New value: +"Provider slug to scope to, case-insensitive"
    • changedInput schema / properties / symbol / description
      Previous value: -"Coin symbol"New value: +"Coin symbol, case-insensitive"
    • addedOutput schema / properties / data
      Added value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "count": {
      +      "type": "number"
      +    },
      +    "history": {
      +      "items": {
      +        "additionalProperties": true,
      +        "properties": {
      +          "category": {
      +            "enum": [
      +              "lending",
      +              "borrowing",
      +              "staking",
      +              "price"
      +            ],
      +            "type": "string"
      +          },
      +          "coinId": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "createdAt": {
      +            "type": "string"
      +          },
      +          "metadata": {
      +            "anyOf": [
      +              {
      +                "additionalProperties": {},
      +                "type": "object"
      +              },
      +              {
      +                "type": "null"
      +              }
      +            ]
      +          },
      +          "provider": {
      +            "type": "string"
      +          },
      +          "providerSymbol": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "rate": {
      +            "type": "number"
      +          },
      +          "symbol": {
      +            "type": "string"
      +          },
      +          "timestamp": {
      +            "description": "ISO-8601 observation time (oldest → newest)",
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "provider",
      +          "symbol",
      +          "category",
      +          "rate",
      +          "timestamp",
      +          "createdAt",
      +          "coinId"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "symbol": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "symbol",
      +    "history",
      +    "count"
      +  ],
      +  "type": "object"
      +}
    • removedOutput schema / properties / points
      Removed value: -{
      -  "description": "Time-ordered rate observations (oldest → newest)",
      -  "items": {
      -    "additionalProperties": true,
      -    "properties": {
      -      "timestamp": {
      -        "description": "ISO-8601 timestamp of the data point",
      -        "type": "string"
      -      },
      -      "value": {
      -        "description": "The recorded numeric value",
      -        "type": "number"
      -      }
      -    },
      -    "required": [
      -      "timestamp",
      -      "value"
      -    ],
      -    "type": "object"
      -  },
      -  "type": "array"
      -}
    • removedOutput schema / properties / provider
      Removed value: -{
      -  "type": "string"
      -}
    • removedOutput schema / properties / symbol
      Removed value: -{
      -  "type": "string"
      -}
    • changedOutput schema / required
      Previous value: -[
      -  "symbol",
      -  "points"
      -]New value: +[
      +  "data"
      +]
  2. First observedv1.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds real behavioral disclosure beyond that: resolution switches from per-tick to daily around 30 days, depth is silently clamped server-side to the caller's plan, and results are additionally bounded by recorded data. It does not discuss response size or cost of large day values, which is the only notable omission.

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?

Three tight sentences, front-loaded with what the tool returns, then granularity, then depth limits. The parenthetical current-plan callout is high-value, non-redundant information; nothing could be cut without losing meaning.

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?

Output schema exists, so return values need no explanation, and the description covers the two things an agent could otherwise get wrong: granularity changes with age and requested depth may be silently reduced. The remaining gap is that it never says how the caller learns their data was clamped (truncated result vs. error).

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 coverage is 100%, so the baseline is 3; the description earns a notch above by explaining the interplay between the days parameter, plan tier, and the granularity breakpoint in prose rather than repeating field text. It adds nothing about the provider parameter, but the schema already defines it.

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 resource and shape: 'Historical rate timeseries for a symbol,' which distinguishes it from a current-rate tool. It stops short of naming a sibling (e.g., get_rates / get_rate_by_symbol) as the alternative for non-historical lookups, leaving that routing to inference.

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

Usage Guidelines3/5

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

Conveys the important context of when the data is per-tick versus daily and that depth is bounded by plan and by data availability, which implies the correct usage envelope. However, there is no explicit statement of when to pick this over get_rates, get_rate_changes, or coin_history, and no exclusions.

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