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

Name	Required	Description	Default
`asset`	No	Asset symbol. Only the pre-computed universe is available for free.	BTC
`interval`	No	Candle interval: 4h looks ~32h ahead, 1d ~7d, 1w ~4w, 1M ~4mo.	1d

Output Schema

TableJSON Schema

Name	Required	Description
`asset`	No	Asset the forecast covers (BTC, ETH, SOL or BNB).
`reason`	No	Why the payload is absent, when `available` is false.
`source`	No	Which store the cached run came from.
`driftPct`	No	Projected percentage drift over the interval.
`interval`	No	Candle interval: 4h, 1d, 1w or 1M.
`available`	No	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.
`consensus`	No	True when TimesFM and Kronos agree. False means the models DISAGREE and the signal is weak; null means agreement was not recorded.
`direction`	No	Projected direction — bullish, bearish or neutral.
`fetchedAt`	No	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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 3, 2026

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"
+}

AddedAug 17, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral detail: the forecast is pre-computed every 4 hours and returns a cached run rather than triggering new inference. This goes beyond the annotations and meaningfully shapes agent expectations.

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 tightly written sentences with no filler. The core purpose is first, followed by the model detail and the critical caching caveat. Every sentence contributes distinct value.

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?

With an output schema present, return-value documentation is already handled. The description states scope, asset universe, model composition, output characteristics, freshness cadence, and the no-new-inference behavior. An agent has everything needed to invoke this tool correctly.

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%, and each parameter has a useful description, including the lookahead horizon per interval. The description adds asset names but no extra parameter-level semantics. Baseline 3 is appropriate because the schema carries the full parameter burden.

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?

The description names a specific verb (get), resource (price forecast), and the exact assets covered (BTC, ETH, SOL, BNB). It also adds distinguishing content: dual-model ML, agreement between models, and direction/drift projections. This clearly differentiates it from accuracy or chart-related sibling forecast tools.

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?

The description explains the tool's cached nature but provides no guidance on when to choose this over alternatives like get_forecast_accuracy or forecast_chart. It neither states conditions for use nor points to sibling tools for other purposes.

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

All Agent Einstein — Crypto & Market Intelligence tools Inspect

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.