Skip to main content
Glama

Cryptocompare

by io.github.pipeworx-io

Histo Minute

histo_minute
Read-onlyIdempotent

Minute-granularity historical OHLC + volume for a crypto pair (BTC/USD, ETH/USDT, etc.) across major exchanges. Use for short-timeframe charting, intraday backtests, and tick-level analysis.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eNo
fsymYes
toTsNo
tsymYes
limitNo
aggregateNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
DataNoArray of OHLC candles
TypeNoData type
TimeToNoEnd timestamp of data
ResponseNoResponse status
TimeFromNoStart timestamp of data
AggregatedNoWhether data is aggregated

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "fsym": "BTC",
+    "limit": 60,
+    "tsym": "USD"
+  },
+  {
+    "aggregate": 5,
+    "fsym": "ETH",
+    "limit": 30,
+    "tsym": "USD"
+  }
+]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "description": "Minute OHLC candlestick data",
+  "properties": {
+    "Aggregated": {
+      "description": "Whether data is aggregated",
+      "type": "boolean"
+    },
+    "Data": {
+      "description": "Array of OHLC candles",
+      "items": {
+        "properties": {
+          "close": {
+            "description": "Closing price",
+            "type": "number"
+          },
+          "high": {
+            "description": "Highest price",
+            "type": "number"
+          },
+          "low": {
+            "description": "Lowest price",
+            "type": "number"
+          },
+          "open": {
+            "description": "Opening price",
+            "type": "number"
+          },
+          "time": {
+            "description": "Unix timestamp",
+            "type": "number"
+          },
+          "volumefrom": {
+            "description": "Volume in base coin",
+            "type": "number"
+          },
+          "volumeto": {
+            "description": "Volume in target coin",
+            "type": "number"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "Response": {
+      "description": "Response status",
+      "type": "string"
+    },
+    "TimeFrom": {
+      "description": "Start timestamp of data",
+      "type": "number"
+    },
+    "TimeTo": {
+      "description": "End timestamp of data",
+      "type": "number"
+    },
+    "Type": {
+      "description": "Data type",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety profile is clear. Description adds that data comes from 'major exchanges' and is historical, which is consistent but not significantly augmentative.

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?

Two efficient sentences. Front-loaded with key information (granularity, data type, use cases). No wasted words.

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?

Output schema exists, so return format is covered. Purpose and safety are clear. However, lack of parameter documentation leaves a gap for a 6-parameter tool, requiring agent to rely on examples or external knowledge.

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

Parameters2/5

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

Schema description coverage is 0%, yet description provides no explicit parameter explanations. Only hints from examples (fsym, tsym, limit, aggregate). Parameters like 'e' and 'toTs' remain unexplained, forcing inference.

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?

Description clearly states it provides minute-granularity historical OHLC + volume for crypto pairs, with specific examples (BTC/USD, ETH/USDT). Differentiates from sibling tools histo_day and histo_hour by specifying minute granularity.

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?

States to use for 'short-timeframe charting, intraday backtests, and tick-level analysis,' which provides clear context. Does not explicitly mention alternatives or when not to use, but sibling names (histo_day, histo_hour) imply longer timeframes.

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

All Cryptocompare toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.1/5.0
Disambiguation3/5

Several tool families overlap heavily: ask_pipeworx, its beta, and grounded variants, the six polymarket_* tools, and the three price endpoints (price, price_full, price_multi) can be confused despite distinct purposes. Long descriptions provide some disambiguation, but an agent must read carefully to select the correct tool.

Naming Consistency4/5

Tool names mostly follow snake_case with verb_noun or noun_noun patterns (all_coins, compare_entities, top_market_cap), and related families share clear prefixes (histo_*, polymarket_*). Minor deviations exist (bare verbs like remember/forget, brand names like ask_pipeworx), but the overall pattern is readable and consistent.

Tool Count2/5

With 46 tools, the server is far beyond the 3-15 well-scoped range and nearly double the 25-tool threshold for 'too many'. Many tools are unrelated to the server's apparent crypto purpose (generate_llms_txt, scan_dependency, memory helpers), making it feel like a general-purpose utility rather than a focused data service.

Completeness3/5

The crypto data surface is fairly complete (spot, historical, top lists, news, social stats, exchange metadata), and the Pipeworx meta-tools (ask_pipeworx, deep_research, entity_profile) cover a broad range of factual queries. However, there are notable gaps: no direct way to fetch pipeworx:// citation URIs, and no advanced crypto order-book/trade endpoints, leaving some workflows as dead ends.

Resources