What can you do with this server?

Ephemeris MCP server lets an AI agent forecast numeric time series with prediction intervals using a panel of zero-shot time-series foundation models, and check model availability and credit usage. * forecast — predict/project 1–64 numeric series in one call (sales, demand, traffic, load, prices, sensors, metrics), each univariate or multivariate, all sharing one horizon and quantile set. * Three modes: route (Ephemeris picks the best model, falls back to a small ensemble), ensemble (run all compatible models and blend — most accurate, highest cost), explicit (run one model named in model, must come from list_models). * ensemble options: top_k (cap participating models, ≤16) and combine (mixture distribution average, or vincentize quantile average). * Optional covariates with past and future channels; only models advertising covariates: true can use them (narrows the panel in route/ensemble, errors in explicit). * Controls: horizon 1–4096 steps (README says up to 512 — treat this as a doc/schema discrepancy), quantiles up to 21 levels strictly in (0,1), context_len 1–16384 points per variate (billed, truncated at the model's cap), freq (e.g. "H", "D", "15min") to improve routing/seasonality. * idempotency_key (8–128 chars) replays a stored result on retry without charging again. * Returns structured JSON: forecasts (one entry per input series, quantile-keyed arrays, null for values a model couldn't produce) and meta (request ids, models_used, per-model weight revisions, per-model latency, and billing: settled_mc charged / balance_mc remaining). * Spends credits on every successful call; not read-only or idempotent. * list_models — discover the live panel: health, capabilities (multivariate, covariates, max_horizon, auto_max_horizon), ensemble weight per horizon, pinned vs actually served weight revision (Hugging Face commit), price per thousand series-slots in millicredits, and billing context cap. Intended as the prerequisite before explicit mode, since the deployed panel can differ from docs. * get_balance — spendable credit balance in millicredits (1000 mc = 1 credit), excluding credits held by in-flight forecasts, plus active_holds_mc. * get_usage — paginated request log (newest first, 1–200 rows per page via limit/offset) showing mode, models used, series count, horizon, credits estimated and settled, HTTP status and latency, with pagination.next_offset for paging.

Which integrations are available for this server?

Provides access to Amazon's Chronos-2 zero-shot forecasting foundation model via the chronos2 model name, enabling time-series forecasting with prediction intervals. Provides access to Datadog's Toto 2 zero-shot forecasting foundation model via the toto2-313m model name, enabling time-series forecasting with prediction intervals. Provides access to Google Research's TimesFM 2.5 zero-shot forecasting foundation model via the timesfm25 model name, enabling time-series forecasting with prediction intervals.

How do I use Ephemeris MCP server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Ephemeris MCP server Forecast next 6 months of sales from this data with 80% intervals." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Ephemeris MCP server

Official

by TensorLink-AI

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Ephemeris MCP server lets an AI agent forecast numeric time series with prediction intervals using a panel of zero-shot time-series foundation models, and check model availability and credit usage.

forecast — predict/project 1–64 numeric series in one call (sales, demand, traffic, load, prices, sensors, metrics), each univariate or multivariate, all sharing one horizon and quantile set.
- Three modes: route (Ephemeris picks the best model, falls back to a small ensemble), ensemble (run all compatible models and blend — most accurate, highest cost), explicit (run one model named in model, must come from list_models).
- ensemble options: top_k (cap participating models, ≤16) and combine (mixture distribution average, or vincentize quantile average).
- Optional covariates with past and future channels; only models advertising covariates: true can use them (narrows the panel in route/ensemble, errors in explicit).
- Controls: horizon 1–4096 steps (README says up to 512 — treat this as a doc/schema discrepancy), quantiles up to 21 levels strictly in (0,1), context_len 1–16384 points per variate (billed, truncated at the model's cap), freq (e.g. "H", "D", "15min") to improve routing/seasonality.
- idempotency_key (8–128 chars) replays a stored result on retry without charging again.
- Returns structured JSON: forecasts (one entry per input series, quantile-keyed arrays, null for values a model couldn't produce) and meta (request ids, models_used, per-model weight revisions, per-model latency, and billing: settled_mc charged / balance_mc remaining).
- Spends credits on every successful call; not read-only or idempotent.
list_models — discover the live panel: health, capabilities (multivariate, covariates, max_horizon, auto_max_horizon), ensemble weight per horizon, pinned vs actually served weight revision (Hugging Face commit), price per thousand series-slots in millicredits, and billing context cap. Intended as the prerequisite before explicit mode, since the deployed panel can differ from docs.
get_balance — spendable credit balance in millicredits (1000 mc = 1 credit), excluding credits held by in-flight forecasts, plus active_holds_mc.
get_usage — paginated request log (newest first, 1–200 rows per page via limit/offset) showing mode, models used, series count, horizon, credits estimated and settled, HTTP status and latency, with pagination.next_offset for paging.

Ephemeris MCP server: time-series foundation model (TSFM) forecasting for AI agents

npm

Add Ephemeris to Cursor

Give Claude, Cursor, ChatGPT or any MCP client the ability to forecast numeric time series with prediction intervals: sales, demand, inventory, web traffic, signups, revenue, energy load, prices, sensor readings, infrastructure metrics.

Ephemeris runs a panel of open-weights, zero-shot time-series foundation models (TSFMs) behind one API key, plus an accuracy-weighted ensemble of them:

Model	Publisher	Use by name
Chronos-2	Amazon	`chronos2`
TimesFM 2.5	Google Research	`timesfm25`
Toto 2	Datadog	`toto2-313m`
TiRex-2	NXAI	`tirex2`
PatchTST-FM r2	IBM Granite	`patchtst-fm-r2`
FlowState r1	IBM Granite	`flowstate-r1`

Send history, get quantile forecasts back. No training, no feature engineering, no GPU. Name a model, let Ephemeris route to the best fit for your data, or use the ensemble, an accuracy-weighted blend of the panel:

TIME: level with the top of the leaderboard (MASE 0.639 vs 0.638 for the leader), with the best average MASE rank of 31 models
GIFT-Eval: CRPS 0.4662 against seasonal naive, better than every model it blends (a few leaderboard entries, including TimesFM-3, score better)

Scored with each benchmark's own harness. Details: ephemeris.cascade.industries/benchmarks.

Tools

Tool	What it does
`get_version`	Public hosted server version, nullable build commit and supported artifact schemas; no key or inference
`forecast`	Forecast 1 to 64 series in one call: `route`, `ensemble` or `explicit` mode, any quantiles, optional covariates, horizons up to 4096 sampling steps (subject to live model limits and the 120,000 output-value budget)
`describe_forecast`	Deterministic interpretation of a saved artifact; no new inference
`plot_forecast`	Inline PNG by default, optional SVG, from a saved artifact; no new inference
`list_models`	The live panel: health, capabilities, horizon limits, ensemble weights, prices
`get_balance`	Spendable credits
`get_usage`	Recent requests and what each cost

Related MCP server: Nixtla MCP Server

Get an API key

Quickest, from a terminal:

npx ephemeris-mcp login

It opens Ephemeris in your browser. Sign in (or sign up), check the page shows the same code as your terminal, and approve. The key is saved to ~/.config/ephemeris/credentials, readable by you only, and the stdio bridge below uses it, with no key in your MCP config. The Ephemeris CLI (ephemeris auth login) and savetokens share the same file. npx ephemeris-mcp logout deletes it; revoke the key itself on the dashboard's API keys page.

Or sign up at ephemeris.cascade.industries and create a key (pc_live_...) in the dashboard. Pay per forecast, no subscription: pricing.

Connect

Remote server (Streamable HTTP): https://ephemeris.cascade.industries/api/mcp, header Authorization: Bearer pc_live_...

Claude Code (plugin: MCP server plus a forecasting skill)

/plugin marketplace add TensorLink-AI/ephemeris-mcp
/plugin install ephemeris@ephemeris

You are asked for your API key once; it is stored in your system's secure credential store.

Claude Code (server only)

claude mcp add --transport http ephemeris https://ephemeris.cascade.industries/api/mcp \
  --header "Authorization: Bearer pc_live_your_key"

Cursor: one click with Add to Cursor , then replace YOUR_EPHEMERIS_API_KEY with your key in Cursor's MCP settings. Or add it by hand:

Cursor (.cursor/mcp.json) and most clients

{
  "mcpServers": {
    "ephemeris": {
      "url": "https://ephemeris.cascade.industries/api/mcp",
      "headers": { "Authorization": "Bearer pc_live_your_key" }
    }
  }
}

VS Code (.vscode/mcp.json)

{
  "servers": {
    "ephemeris": {
      "type": "http",
      "url": "https://ephemeris.cascade.industries/api/mcp",
      "headers": { "Authorization": "Bearer pc_live_your_key" }
    }
  }
}

Claude Desktop and other clients that only run local (stdio) servers

After npx ephemeris-mcp login, no key goes in the config:

{
  "mcpServers": {
    "ephemeris": {
      "command": "npx",
      "args": ["-y", "ephemeris-mcp"]
    }
  }
}

Or pass a key explicitly with "env": { "EPHEMERIS_API_KEY": "pc_live_your_key" }; it wins over the saved one.

Claude Code, with the saved key: claude mcp add ephemeris -- npx -y ephemeris-mcp

OpenAI Responses API, Anthropic Messages API, Codex, Gemini CLI: see the docs.

Try it

Once connected, ask:

"Here are my last 18 months of sales: … Forecast the next 6 months with an 80% interval."
"Forecast next week's hourly traffic from this CSV and identify the highest median forecast step, without claiming the actual peak distribution."
"Use the ensemble to project daily signups for 90 days; plot the median and the 10th to 90th percentile band."

More in examples/prompts.md. Without MCP, the same forecast is one REST call: examples/rest_forecast.py.

Guides

Reference

Full reference for LLMs: llms-full.txt
API docs: ephemeris.cascade.industries/docs
OpenAPI: openapi-m1.json
Status: ephemeris.cascade.industries/status

The code in this repository (the plugin manifest, skill and stdio bridge) is MIT-licensed. The models keep their own licences, listed on each model page.

Saved forecasts and updates

Retain an idempotency_key before a paid MCP forecast submission. If the outcome is uncertain, retry identical inputs with that key within the server's retention period; a fresh or expired key may incur another charge. Forecasts include an ephemeris.forecast v1 artifact by default. It contains the submitted input history, response, billing information and supplied local context. Save it privately in the client; embedded URNs are not permanent download links or hosted storage.

Pass the complete saved object as artifact to describe_forecast or plot_forecast; neither accepts a local path or URL. Plotting defaults to PNG; use format: "svg" for SVG. These authenticated tools do not run inference or charge for a new forecast. Correcting supplied local labels or plotting a result does not require another forecast. Artifact input is limited to 1 MiB; use the CLI for larger local artifacts. If artifact_status is unavailable, preserve the raw successful result and original request rather than paying to rerun it.

Supply units, timezone, target definition and measurement semantics in context when known. Context reaches the hosted service but is not sent as model input. Ask for missing definitions; do not guess. A horizon counts sampling steps. Quantile bands are nominal marginal intervals: they do not establish calibrated coverage, cumulative intervals, path probabilities or the actual peak distribution. Distinguish observed sales from underlying demand and known future inputs from scenario assumptions. Billing amounts ending in _mc are millicredits (1000 mc = 1 credit).

Hosted MCP updates are deployed centrally. Reconnect or start a new conversation if the client caches its tool list. Existing npm bridges forward the new tools; updating the bridge package is only necessary for changes to the bridge itself. Client transport support and image/attachment rendering vary. The hosted endpoint uses Streamable HTTP; SSE-only clients need compatible transport support.

Version diagnostics: MCP get_version with {} reports the hosted server version, nullable build commit and supported forecast schemas without an API key or inference charge. ephemeris-mcp --version reports this installed npm bridge version offline, not the remote server version. For the standalone CLI, use ephemeris --version or ephemeris version --json. These versions are independent.

Available Tools

4 tools

forecastForecast a time seriesAInspect

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.

ParametersJSON 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

ParametersJSON Schema

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

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.

get_balanceGet credit balanceA

Read-onlyIdempotent

Inspect

Return the account's spendable credit balance in millicredits, excluding credits reserved by in-progress forecasts. 1000 millicredits equal one credit.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`balance_mc`	No	Spendable millicredits (ledger minus active holds).
`active_holds_mc`	No	Millicredits reserved by in-flight forecasts.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare the operation read-only, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the balance excludes credits reserved by in-progress forecasts, and the millicredit conversion is spelled out. It does not mention caching or refresh semantics, which keeps it short of a 5.

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 tight sentences with zero waste; the resource and its qualifying scope come first, and the unit conversion follows. Nothing is repeated from annotations or schema.

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 a full output schema present, the description need not explain return values, and the annotations carry the safety profile. The remaining ambiguity a caller would care about – what 'spendable' excludes and the unit – is explicitly resolved.

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

Parameters4/5

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

The tool takes no parameters, so there is nothing for the description to document; the baseline for a zero-parameter tool is 4. The millicredit definition is a useful unit clarification rather than a parameter explanation.

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 and resource ('Return the account's spendable credit balance') and pins down scope with 'spendable' and the millicredit unit. This cleanly separates it from siblings like get_usage and forecast, which report consumption or projections rather than current available funds.

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?

Usage is implied by the name and the 'spendable balance' framing, but there is no explicit statement of when to call this versus get_usage or forecast. An agent can infer it, yet the definition never routes the caller or names exclusions.

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

get_usageGet recent usageB

Read-onlyIdempotent

Inspect

Return the account's forecast request log, newest first, with the mode, models used, series count, horizon, credits estimated and settled, HTTP status and latency of each request.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Rows per page, 1 to 200. Defaults to 50.
`offset`	No	Rows to skip. Use `pagination.next_offset` from the previous page.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	No	Request log rows, newest first.
`limit`	No
`offset`	No
`pagination`	No

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context by stating the log is returned newest first and listing settled/estimated credits plus HTTP status and latency, but it does not contradict the annotations. With annotations carrying the safety profile and an output schema present, this is adequate but not rich.

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 description is a single front-loaded sentence that states the resource first and then enumerates returned fields efficiently. The field list is long but every element adds informative value, with no filler.

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?

For a simple read-only listing tool with rich annotations, full schema coverage, and an output schema, the description supplies what is needed to understand the return ordering and content. The primary missing piece is guidance on when to select this tool over its siblings.

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?

The input schema fully documents both parameters (limit and offset) with ranges and pagination guidance, giving 100% schema coverage. The description adds no parameter information, which is acceptable because the schema does the heavy lifting; 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?

The description uses a specific verb and resource ('Return the account's forecast request log') and specifies ordering ('newest first'). It does not explicitly distinguish this tool from siblings like forecast or get_balance, so it is clear but lacks sibling differentiation.

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 gives no indication of when to use this tool versus alternatives such as forecast, get_balance, or list_models. It also omits any prerequisites or exclusions, leaving usage entirely to inference.

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

list_modelsList forecasting modelsA

Read-onlyIdempotent

Inspect

Discover the model panel: each model's availability right now (healthy), capabilities (multivariate, covariates, max_horizon, auto_max_horizon), its weight in an ensemble at each horizon, pinned and actually served weight revision, price per thousand series-slots in millicredits and maximum billable context. Call this before using forecast in explicit mode; the deployed panel can differ from any documentation.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`models`	No

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about dynamic availability ('right now (healthy)') and documentation divergence, but does not mention permissions, rate limits, or pagination.

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?

It is front-loaded with the core purpose and efficiently enumerates the rich output in a single sentence, followed by a direct usage note. It is dense but every clause appears to earn its place.

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 and annotations covering safety, the description supplies the remaining context an agent needs: what the tool reveals, why it matters before forecasting, and that the panel is dynamic. Nothing essential is missing.

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

Parameters4/5

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

The tool has zero parameters, so parameter semantics are inherently trivial. The description lists returned fields rather than input parameters, which is appropriate but adds no parameter-level guidance.

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 states a specific verb+resource ('Discover the model panel') and enumerates exactly what is returned: availability, capabilities, ensemble weight, revision, price, and billable context. It also distinguishes the tool from sibling 'forecast' by positioning it as a prerequisite for explicit mode.

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?

It gives explicit when-to-use guidance: 'Call this before using forecast in explicit mode' and explains why: 'the deployed panel can differ from any documentation.' It does not discuss when not to use it, but no relevant alternative is omitted.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Oct 7, 2026
- First observedforecast
- First observedget_balance
- First observedget_usage
- First observedlist_models

Deploy Server

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

TDQS

A3.9/5.0

Scored 2026-10-07 17:20 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: forecasting, checking balance, viewing usage, and discovering models. No overlap or ambiguity between them.

Naming Consistency4/5

get_balance, get_usage, and list_models follow a consistent verb_noun pattern, while forecast is a verb-only outlier. Still readable and predictable overall.

Tool Count5/5

Four tools are well-scoped for a forecasting service: one core action plus supporting introspection for credits, usage, and model metadata. Each tool earns its place.

Completeness4/5

Core forecast lifecycle is covered, but there is no way to retrieve a past forecast by request id or cancel an in-progress forecast, which the balance tool hints can exist. Minor gaps an agent can mostly work around.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

predictoracle C
io.tooloracle
PredictOracle - 12 forecasting tools: time-series, scenario analysis, risk projections.
AI & Machine Learning Research & Data
122
Demand Forecasting AOAuth
ai.saifs
Forecast product demand using historical sales and market signals.
CRM E-commerce & Retail Marketing
21
PolyBridge A
io.github.crowdvector
Calibrated probabilistic foresight for AI agents, powered by live prediction-market signal.
Search Finance
22
Kunkafa A
com.kunkafa
Market forecasts with their own track record, inside Claude, ChatGPT and other MCP apps.
AI & Machine Learning Finance Research & Data
91

Related MCP Servers

forecast-mcp
AI & Machine Learning Research & Data
ramdhavepreetam
A
license
B
quality
D
maintenance
Enable any AI agent to forecast time-series data (e.g., sales, traffic) using Google's TimesFM or a zero-dependency statistical baseline.
Updated 5 months ago (2026-06-02 00:50 UTC)
3
Apache 2.0
Nixtla MCP Server
AI & Machine Learning Research & Data
VaclavRut
A
license
Not graded
quality
D
maintenance
Enables multitenant time series forecasting and anomaly detection using Nixtla's TimeGPT, with support for fine-tuning, rolling backtests, and usage tracking.
Updated 10 months ago (2026-01-02 11:06 UTC)
MIT
data-science-mcp
LiChenStuttgart
A
license
Not graded
quality
D
maintenance
Enables time-series analysis and forecasting through a structured tool catalogue, including data loading, quality repair, diagnostics, and forecasting with ARIMA, exponential smoothing, Chronos-2, Toto 2.0, and AutoML.
Updated 3 months ago (2026-07-20 14:48 UTC)
1
MIT
MCP Zero Shot Agentic
AI & Machine Learning Autonomous Agents
arashnicoomanesh
A
license
Not graded
quality
B
maintenance
Enables zero-shot demand forecasting for supply-chain decisions, returning mean predictions, quantile bands, and confidence scores via a strictly-typed MCP tool.
Updated 2 months ago (2026-08-28 12:52 UTC)
MIT