Skip to main content
Glama

AIsa Finance

by one.aisa
OverviewDiscussionsAdmin

Coin Historical Chart Data by ID

get_coingecko_coins_id_market_chart
Read-onlyIdempotent

This endpoint allows you to get the historical chart data of a coin including time in UNIX, price, market cap and 24hr volume based on particular coin ID

Published reference price: $0.008 USD per successful request. Declared unit rate: $0 USD per provider_credit. Account-specific pricing and final settlement may differ.

Input Schema

NameRequiredDescriptionDefault
idYesCoin ID. *refers to [`/coins/list`](/reference/coins-list).bitcoin
daysYesData up to number of days ago. You may use any integer or `max` for number of days.1
intervalNoData interval, leave empty for auto granularity.
precisionNoDecimal place for currency price value.
vs_currencyYesTarget currency of market data. *refers to [`/simple/supported_vs_currencies`](/reference/simple-supported-currencies).usd

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changed
    • addedInput schema / properties / days / default
      Added value: +"1"
    • changedInput schema / properties / days / description
      Previous value: -"Data up to N days ago. Accepts `1`, `7`, `14`, `30`, `90`, `180`, `365`, or `max`."New value: +"Data up to number of days ago. \nYou may use any integer or `max` for number of days."
    • removedInput schema / properties / days / example
      Removed value: -"7"
    • addedInput schema / properties / id / default
      Added value: +"bitcoin"
    • changedInput schema / properties / id / description
      Previous value: -"CoinGecko coin ID (e.g., `bitcoin`, `ethereum`). Get the list via `/coins/list`."New value: +"Coin ID. \n*refers to [`/coins/list`](/reference/coins-list)."
    • removedInput schema / properties / id / example
      Removed value: -"bitcoin"
    • changedInput schema / properties / interval / description
      Previous value: -"Data interval. CoinGecko supports `daily`; `hourly` is also available for supported ranges."New value: +"Data interval, leave empty for auto granularity."
    • changedInput schema / properties / interval / enum
      Previous value: -[
-  "daily",
-  "hourly"
-]New value: +[
+  "1m",
+  "5m",
+  "hourly",
+  "daily"
+]
    • changedInput schema / properties / precision / description
      Previous value: -"`full` or a value from `0` to `18` to specify decimal places for currency price values."New value: +"Decimal place for currency price value."
    • addedInput schema / properties / precision / enum
      Added value: +[
+  "full",
+  "0",
+  "1",
+  "2",
+  "3",
+  "4",
+  "5",
+  "6",
+  "7",
+  "8",
+  "9",
+  "10",
+  "11",
+  "12",
+  "13",
+  "14",
+  "15",
+  "16",
+  "17",
+  "18"
+]
    • removedInput schema / properties / precision / example
      Removed value: -"2"
    • changedInput schema / properties / vs_currency / description
      Previous value: -"Target currency for price (e.g., `usd`, `eur`, `btc`). See `/simple/supported_vs_currencies`."New value: +"Target currency of market data. \n*refers to [`/simple/supported_vs_currencies`](/reference/simple-supported-currencies)."
    • changedInput schema / required
      Previous value: -[
-  "id",
-  "vs_currency",
-  "days"
-]New value: +[
+  "id",
+  "days",
+  "vs_currency"
+]
  2. Changed3 schema fields changed
    • addedInput schema / properties / days / example
      Added value: +"7"
    • addedInput schema / properties / id / example
      Added value: +"bitcoin"
    • addedInput schema / properties / precision / example
      Added value: +"2"
  3. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds the returned field set and a per-request cost note ($0.008/request), which is genuine behavioral context an agent can act on. It says nothing about pagination, granularity defaults, or rate limits beyond price.

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?

The purpose is a single front-loaded sentence, followed by a compact pricing block. No wasted prose. Minus one point because the boilerplate pricing comment block is injected noise relative to the tool's actual semantics and the bold markdown is gratuitous.

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

Completeness3/5

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

An output schema exists, so return values need not be described, and annotations cover safety. What is missing is the routing context against the many coin-chart siblings (range vs. trailing days, ohlc, history). For a 5-parameter endpoint in a dense tool family, that gap keeps it at minimum viable.

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 description coverage is 100% (id, days, interval, precision, vs_currency all documented with enums), so the schema carries parameter semantics. The description echoes only the coin-ID selector and returned fields, adding no syntax or constraint detail beyond the schema. Baseline 3 applies.

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?

Specific verb+resource: gets historical chart data (UNIX time, price, market cap, 24hr volume) for a coin identified by ID. An agent knows exactly what the call returns. However, it never distinguishes itself from the near-identical sibling get_coingecko_coins_id_market_chart_range, which an agent must infer differs only by date-range selection.

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

Usage Guidelines2/5

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

No when-to-use guidance, no exclusions, no named alternatives. With siblings like market_chart_range (arbitrary date window vs. trailing 'days'), ohlc, and history, the description leaves the agent to guess which chart tool to pick. Only implied usage from the required 'days' parameter.

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

All AIsa Finance toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources