Ephemeris MCP server

Official

Overview Schema Source Related Servers Discussions Admin

Forecast a time series

forecast

Predict numeric time series with prediction intervals using zero-shot models; returns quantiles and metadata for sales, demand, traffic, or sensor data.

Instructions

Forecast, predict or project one or more numeric time series (sales, demand, traffic, load, prices, metrics, sensor data) with prediction intervals, using Ephemeris' panel of zero-shot foundation models. Mode ensemble is the most accurate: it is level with the top of the TIME benchmark and scores better on GIFT-Eval than any single model in the panel. Returns structured JSON: forecasts (one entry per input series, quantile-keyed arrays) and meta with the request id, models used, the served weight revision per model, and the credits charged and remaining. Spends credits on every successful call.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes	"route": Ephemeris picks the best model for the data, falling back to a small ensemble if it fails. "ensemble": run all compatible models and blend them; best calibration, highest cost. "explicit": run the single model named in `model`.
`model`	No	Required when mode is "explicit". Must be a name returned by list_models.
`top_k`	No	Ensemble only: cap on how many models participate.
`series`	Yes	One to 64 series forecast in one request. All share horizon and quantiles.
`combine`	No	Ensemble only. "mixture" averages the predictive distributions (default); "vincentize" averages the quantiles.
`horizon`	No	Number of future steps to forecast, 1 to 4096. Defaults to 64. Some models stop short of this (max_horizon in list_models): route and ensemble skip them, explicit mode rejects the request.
`quantiles`	No	Up to 21 quantile levels strictly between 0 and 1, for example [0.1, 0.5, 0.9]. The response keys forecasts by these as decimal strings.
`context_len`	No	Most recent points per variate to feed the model and bill for, 1 to 16384. Defaults to 256. Values beyond the model's context cap are truncated at the cap.
`idempotency_key`	No	Client-chosen key, 8 to 128 characters of letters, numbers, dot, underscore, colon or hyphen. A retry with the same key and identical body replays the stored result without charging again.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`meta`	No
`forecasts`	No	One entry per input series, aligned with the request.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 7, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare openWorldHint=true, readOnlyHint=false and idempotentHint=false, so the mutation/external-call profile is covered. The description adds genuinely non-derivable behavior: credits are charged on every successful call, and the exact return shape (forecasts plus meta with request id, models used, per-model served weight revision, credits charged and remaining). It does not note rate limits or what happens on partial failures, so a 4 rather than 5.

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?

A tight single paragraph that front-loads the core action and ends with the credit warning, so every sentence is at least oriented to a decision. The benchmark bragging (level with the top of TIME, better on GIFT-Eval than any single model) is mildly promotional and costs a point on strict conciseness.

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?

An output schema exists, so return values need not be spelled out, yet the description still sketches forecasts/meta, and it covers cost, mode tradeoffs and the zero-shot nature of the call. Combined with 100% schema coverage and the annotation set, an agent has nearly everything needed; only failure handling and pre-call prerequisites are unaddressed.

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%, so the schema already documents every parameter including mode semantics, quantiles, covariates and idempotency. The description adds almost no parameter-level detail beyond implying quantile/prediction-interval output and multi-series batching; baseline 3 is correct when the schema carries this load.

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 (forecast/predict/project) plus the resource (one or more numeric time series) and gives concrete domains (sales, demand, traffic, load, prices, metrics, sensor data). It is instantly distinguishable from the unrelated siblings get_balance, get_usage and list_models, and it names the mechanism (Ephemeris' zero-shot foundation model panel).

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?

Gives clear context for mode selection by recommending ensemble as the most accurate with a benchmark-supported rationale, and warns that every successful call spends credits, which is the key cost consideration before invoking. It does not explicitly say when not to use it or point at a prerequisite such as list_models for explicit mode, so it stops short of full when/when-not guidance.

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

Deploy Server