Skip to main content
Glama

Agent Einstein — Crypto & Market Intelligence

AI Price Forecast

get_price_forecast
Read-onlyIdempotent

Einstein's dual-model machine-learning price forecast (Google TimesFM 3.0 + Kronos) for BTC, ETH, SOL or BNB, including whether the two models agree and the direction/drift each projects. Pre-computed every 4 hours; returns the cached run rather than triggering new inference.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
assetNoAsset symbol. Only the pre-computed universe is available for free.BTC
intervalNoCandle interval: 4h looks ~32h ahead, 1d ~7d, 1w ~4w, 1M ~4mo.1d

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
assetNoAsset the forecast covers (BTC, ETH, SOL or BNB).
reasonNoWhy the payload is absent, when `available` is false.
sourceNoWhich store the cached run came from.
driftPctNoProjected percentage drift over the interval.
intervalNoCandle interval: 4h, 1d, 1w or 1M.
availableNoFalse when this call has no data — a snapshot that is not warm yet, a domain switched off, or an argument that was rejected. NOT an error, and NOT a statement about the market.
consensusNoTrue when TimesFM and Kronos agree. False means the models DISAGREE and the signal is weak; null means agreement was not recorded.
directionNoProjected direction — bullish, bearish or neutral.
fetchedAtNoWhen the underlying snapshot was refreshed (epoch ms or ISO-8601). Age matters: these are cached reads, not live queries.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / fetchedAt / description
      Previous value: -"When the underlying snapshot was refreshed (epoch ms, or ISO-8601 for the Bitcoin cycle feed). Age matters: these are cached reads, not live queries."New value: +"When the underlying snapshot was refreshed (epoch ms or ISO-8601). Age matters: these are cached reads, not live queries."
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "asset": {
      +      "description": "Asset the forecast covers (BTC, ETH, SOL or BNB)."
      +    },
      +    "available": {
      +      "description": "False when this call has no data — a snapshot that is not warm yet, a domain switched off, or an argument that was rejected. NOT an error, and NOT a statement about the market.",
      +      "type": "boolean"
      +    },
      +    "consensus": {
      +      "description": "True when TimesFM and Kronos agree. False means the models DISAGREE and the signal is weak; null means agreement was not recorded."
      +    },
      +    "direction": {
      +      "description": "Projected direction — bullish, bearish or neutral."
      +    },
      +    "driftPct": {
      +      "description": "Projected percentage drift over the interval."
      +    },
      +    "fetchedAt": {
      +      "description": "When the underlying snapshot was refreshed (epoch ms, or ISO-8601 for the Bitcoin cycle feed). Age matters: these are cached reads, not live queries."
      +    },
      +    "interval": {
      +      "description": "Candle interval: 4h, 1d, 1w or 1M."
      +    },
      +    "reason": {
      +      "description": "Why the payload is absent, when `available` is false.",
      +      "type": "string"
      +    },
      +    "source": {
      +      "description": "Which store the cached run came from."
      +    }
      +  },
      +  "type": "object"
      +}
  3. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false and a closed-world scope, so the safety profile is covered. The description still adds real behavioral context beyond that: 4-hour pre-computation cadence, cache-only return semantics (no new inference), and the fact that the response reports model agreement plus direction/drift per model.

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 dense sentences with no filler: the first front-loads what the tool produces and for which assets, the second immediately follows with the caching/freshness constraint. Nothing is repeated or padded.

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?

An output schema exists, so return-value structure need not be explained, and annotations cover the safety/idempotency profile. What remains — which assets, which models, freshness cadence, and cache-only behavior — is all present, leaving no gap an agent would need to guess at.

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 coverage is 100%, with enums and per-parameter descriptions already specifying the asset universe, the free-tier restriction, and the look-ahead horizon for each interval. The description only restates the asset list, adding no syntax or format meaning beyond the schema, so the baseline 3 applies.

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 verb+resource (dual-model ML price forecast) and names the exact asset universe (BTC, ETH, SOL, BNB) plus the models used (TimesFM 3.0 + Kronos). This clearly separates it from siblings like forecast_chart and get_forecast_accuracy, which address chart rendering and historical accuracy rather than the forecast itself.

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?

The description informs the agent that results are pre-computed every 4 hours and that the call returns the cached run rather than triggering new inference, which implicitly frames when it is cheap/safe to call. However, it never explicitly says when to prefer this over forecast_chart, get_forecast_accuracy, or ask_einstein, so the routing decision is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.