Skip to main content
Glama

Ephemeris Time-Series Forecasting

by industries.cascade
OverviewDiscussionsAdmin

Server Details

Probabilistic time-series forecasts from zero-shot foundation models: routed, single or ensembled.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
97.4% over 21 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
TensorLink-AI/ephemeris-mcp
GitHub Stars
0
Server Listing
Ephemeris MCP server

TDQS

A4.1/5.0

Scored across 7 tools

Disambiguation4/5

Each tool has a distinct action: forecast submits inference, describe_forecast and plot_forecast both consume saved artifacts but produce clearly different outputs (text/basis vs PNG/SVG), and the four metadata tools (balance, usage, version, models) are non-overlapping. The only mild friction is that describe_forecast and plot_forecast operate on the same artifact input and could momentarily be confused.

Naming Consistency4/5

Six of seven names follow a clean verb_noun snake_case pattern (get_balance, get_usage, get_version, list_models, describe_forecast, plot_forecast). The bare 'forecast' verb is the single deviation, though it is intuitive as the primary action.

Tool Count5/5

Seven tools is well within the ideal 3-15 range and each earns its place: one inference call, two artifact consumers, and four account/panel/diagnostic reads. Nothing feels padded or missing for the stated service scope.

Completeness4/5

The surface covers the forecast lifecycle (submit, describe, plot) plus billing, usage history, model discovery, and version introspection, which is strong CRUD-adjacent coverage for a stateless forecasting API. Minor gaps exist around job status/cancellation and retrieving a prior forecast by key, but the documented 'resubmit with same idempotency_key and no hosted storage' model makes these largely unnecessary.

Available Tools

7 tools
describe_forecastDescribe a saved forecastA
Read-onlyIdempotent
Inspect

Deterministic calculations from a complete ephemeris.forecast v1 artifact object, including CLI artifacts. No inference or forecast charge; this hosted tool still receives data over the network. Returns scope, result, basis, limitations and source pointers: last-observed baseline, median endpoint/change, marginal-median aggregates, and exact saved billing units. Missing medians/context remain unknown. Sum of medians only for period_total; it is not a cumulative-distribution interval or median. No calibrated coverage, causal explanation, path/peak probability, or business action is inferred. Example: pass {artifact: }; choose series_index/variate_index for multiple results. Maximum 1 MiB; malformed/version/shape errors are recoverable by fixing the artifact or using CLI, never rerunning inference. Missing labels may be corrected in a COPY of context without changing request/response. No filesystem access, URL fetches, persistent storage, Gnomon import, or scoring.

NameRequiredDescriptionDefault
artifactYesComplete ephemeris.forecast schema_version 1 JSON object returned by forecast or saved by Ephemeris CLI. Pass the object, not a filename, URL, resource URI, request ID, or bearer token. Maximum 1 MiB UTF-8 JSON. Contains submitted history; send only data you are authorized to process on this hosted server.
series_indexNoZero-based series index; required when the artifact has multiple series, otherwise 0.
variate_indexNoZero-based variate index; required for multivariate results, otherwise 0.

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial context beyond them: the 1 MiB cap, that data travels over the network to a hosted server, which errors are recoverable and how, and an explicit list of what is NOT inferred (calibrated coverage, causal explanation, path/peak probability). That is a rich, honest behavioral profile.

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?

Front-loaded with the core operation and no filler sentences; each clause conveys substantive scope or limit information. However, it is a long unbroken block of semicolon-separated caveats with no structural grouping, which makes it slower to scan than a 3-parameter readback tool warrants.

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?

For a tool with a nested artifact object, three parameters, and an output schema, the description covers invocation, input limits, error handling, and expectation boundaries. Even though the output schema exists, the added framing on what the result does and does not mean prevents misreading medians as intervals.

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?

Schema coverage is 100%, so the schema documents artifact, series_index and variate_index in detail; per the rubric the baseline is 3. The description adds marginally beyond that — the 'pass {artifact: <forecast result artifact>}' example and the version/shape error-recovery note — but repeats the 1 MiB and multi-series guidance already in the schema.

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 (deterministic calculations over a saved ephemeris.forecast v1 artifact) and the framing 'No inference or forecast charge' cleanly separates it from the sibling `forecast` tool that generates artifacts. An agent can tell it is a readback/describe operation, not a compute operation, without opening the schema.

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 a concrete invocation example plus selection guidance for series_index/variate_index when multiple results exist, and a clear failure path ('fixing the artifact or using CLI, never rerunning inference'). It does not explicitly state when to prefer it over `forecast`/`plot_forecast`, but the context is unambiguous.

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

forecastForecast a time seriesAInspect

Submit numeric observations to forecast future sampling steps. Spends credits on successful calls. Choose and retain idempotency_key before submitting; no automatic retries, replay depends on server retention. Minimal example: {mode: route, series: [{values: [10,12,11], freq: D}], horizon: 2, quantiles: [0.1,0.5,0.9]}. Returns forecasts and meta as before, plus artifact by default for describe_forecast/plot_forecast. Save the embedded JSON attachment: it includes full input history and local context; no hosted storage is created. Context never becomes a model input. Billing is at meta.billing in millicredit strings (100 mc = 0.1 credits). Missing future inputs mean not supplied, not no events. Quantile bands do not establish coverage, cumulative intervals or peak probabilities. After uncertain completion, reuse the same key and API request; an expired key may cause a new charge.

NameRequiredDescriptionDefault
modeYes"route": automatically select a model. "ensemble": blend compatible models and may cost more. Neither guarantees accuracy or calibration. "explicit": run the single model named in `model`.
modelNoRequired when mode is "explicit". Must be a name returned by list_models.
top_kNoEnsemble only: cap on how many models participate.
seriesYesOne to 64 series forecast in one request. All share horizon and quantiles.
combineNoEnsemble only. "mixture" averages the predictive distributions (default); "vincentize" averages the quantiles.
contextNoLocal artifact metadata, never sent as model inputs. series aligns with input series; timestamps align with history and future_timestamps with horizon. Units/target/measurement/timezone must come from the user; unknowns stay null. Future-input labels are caller assertions; narrative assumptions do not change inference.
horizonNoNumber 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.
quantilesNoUp 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_lenNoMost recent points per variate to feed the model (history length does not affect pricing), 1 to 16384. Defaults to 256. Values beyond the model's context cap are truncated at the cap.
idempotency_keyNoClient-chosen key, 8 to 128 characters of letters, numbers, dot, underscore, colon or hyphen. A retry with the same key and identical API body replays while retained by the server. Retain the key before submission; expired keys may cause a new charge.
include_artifactNoDefault true: include a portable ephemeris.forecast v1 artifact and embedded JSON attachment (up to 1 MiB), with full input history. Save it client-side for describe_forecast/plot_forecast or the CLI. false returns the existing API response only. No persistent hosted storage is created.

Output Schema

NameRequiredDescription
metaNo
artifactNoPortable ephemeris.forecast v1 JSON including full history and local context. Save client-side and pass the object to describe_forecast/plot_forecast. Not a hosted URL.
forecastsNoOne entry per input series, aligned with the request.
artifact_errorNo
artifact_statusNoincluded or unavailable. A packaging/size failure never discards the paid forecasts/meta response.

TDQS

A4.6/5.0
Behavior5/5

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

Substantially exceeds the annotations: it discloses credit spend on successful calls, replay/retention semantics, that no hosted storage is created, that context never becomes a model input, billing units (millicredits), and interpretive caveats about missing future inputs and quantile bands. This is exactly the kind of behavior annotations cannot convey.

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?

Front-loaded with purpose and the minimal example, then organized around operational warnings. Dense but each sentence carries actionable content, though a few points (idempotency retention) echo the schema descriptions.

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?

Given 11 parameters, an output schema, and rich annotations, the description still covers the non-obvious operational and interpretive dimensions (billing, idempotency, artifact handling, output interpretation) that an agent needs before invoking this costly, open-world tool.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantic interpretation beyond the schema — missing future inputs mean 'not supplied' rather than 'no events,' quantile bands do not establish coverage/peak probabilities, and idempotency/artifact behavior is restated with operational framing.

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: 'Submit numeric observations to forecast future sampling steps.' It also implicitly distinguishes itself from describe_forecast/plot_forecast, which are positioned as consumers of the artifact produced here.

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 strong operational guidance (retain idempotency_key before submitting, reuse the same key and request after uncertain completion, no automatic retries) and clarifies how the artifact feeds describe_forecast/plot_forecast. However it does not explicitly frame when to prefer forecast over list_models or the other siblings beyond artifact consumption.

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.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
balance_mcNoSpendable millicredits (ledger minus active holds).
active_holds_mcNoMillicredits reserved by in-flight forecasts.

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world semantics, so the safety profile is covered. The description still adds real value beyond that by defining the unit ('1000 millicredits equal one credit') and the precise semantic of 'spendable' (excluding credits reserved by in-progress forecasts), which prevents misreading the returned number.

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 short sentences, front-loaded with the scope qualifier before the unit definition. Every clause earns its place: the exclusion rule and the millicredit conversion are both needed to interpret the result.

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?

For a zero-parameter read tool with a declared output schema, nothing further is required: safety is covered by annotations, return shape by the output schema, and the description supplies the unit and exclusion semantics an agent needs to interpret the number correctly.

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 zero parameters, so the baseline is 4; there is nothing parameter-related left to document. The unit explanation in the description pertains to the return value rather than inputs.

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?

States a specific verb and resource ('Return the account's spendable credit balance') and sharpens the scope with 'excluding credits reserved by in-progress forecasts'. It does not explicitly name or differentiate itself from the sibling get_usage, so an agent must infer the boundary between balance and usage.

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?

No explicit when-to-use statement or named alternatives (e.g., get_usage vs. get_balance) are given. Usage is implied by the purpose and the zero-parameter, no-argument nature of the call, which makes selection largely self-evident but not spelled out.

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

get_usageGet recent usageA
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.

NameRequiredDescriptionDefault
limitNoRows per page, 1 to 200. Defaults to 50.
offsetNoRows to skip. Use `pagination.next_offset` from the previous page.

Output Schema

NameRequiredDescription
dataNoRequest log rows, newest first.
limitNo
offsetNo
paginationNo

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral context ('newest first') but says nothing about rate limits, auth, or retention window; a 3 is appropriate given the lower bar set by annotations.

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 single front-loaded sentence with no filler, opening with the verb and resource. The trailing field enumeration is dense but partly duplicates the output schema, keeping it just short of ideal.

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?

With a full output schema, complete parameter descriptions, and rich annotations, the description only needs to convey purpose and ordering, which it does. The only gap is any guidance on when to reach for this tool versus 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?

Schema coverage is 100% and both parameters carry their own descriptions (range, default, and the next_offset pagination hint). The description adds no parameter meaning beyond that, 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?

Names a specific verb and resource ('Return the account's forecast request log') and enumerates the exact per-row content, which cleanly separates it from siblings like get_balance and forecast. An agent can tell what it retrieves without opening the schema.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_balance for credit totals. Usage is only implied by the resource name.

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

get_versionInspect the hosted Ephemeris versionA
Read-onlyIdempotent
Inspect

Read this deployed MCP server's version, nullable build commit and supported saved forecast schema versions. Call with {}. No API key, account access, inference, charges or writes; network access to this server only. Returns component, version, build_commit (full source SHA or null when unavailable), artifact_schema_versions, and runtime_tls (Node release and certificate-trust status; metadata only, no probe connections). Unknown commit stays null. Server, CLI, npm bridge and artifact schema versions are independent; this tool cannot inspect local installations, check the latest registry release or establish model quality. Use list_models for live model capabilities. After a connection failure reconnect and retry; no forecast could have been submitted by this tool.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
versionYes
componentYes
runtime_tlsYes
build_commitYes
artifact_schema_versionsYes

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, but the description adds substantial context: no inference, charges, writes, or account access; network access only to this server; runtime_tls is metadata only with no probe connections; unknown commits stay null; and no forecast could have been submitted. This is rich behavioral disclosure beyond the structured hints.

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 front-loaded with the core purpose and then adds operational caveats. It is information-dense and mostly earns its sentences, though it is somewhat long and could be tightened because several clarifications overlap with annotation and output-schema information.

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?

The tool has no parameters, rich annotations, and an output schema, yet the description still provides enough context about return fields, null behavior, independence of version types, and failure handling. An agent has everything needed to call it correctly and interpret its scope.

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?

There are zero parameters, so the baseline is 4. The description reinforces this by saying to call with {}, which is useful but not necessary beyond the empty schema.

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 read operation: this deployed MCP server's version, build commit, and supported saved forecast schema versions. It clearly distinguishes the tool from sibling concerns by saying it cannot inspect local installations, check registry releases, or establish model quality, and it routes live model capability checks to list_models.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to call with {}, notes that no API key or account access is needed, and gives an alternative for live model capabilities via list_models. It also provides a recovery instruction after connection failures, so the agent knows both when to use it and what not to expect from it.

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 in millicredits per series-slot per 64 forecast steps. History length has no billing multiplier. Call this before using forecast in explicit mode; the deployed panel can differ from any documentation.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
modelsNo

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety behavior is covered. The description adds useful context beyond the annotations: the panel reflects current health, includes pricing units and a billing multiplier nuance, and can differ from documentation. It does not contradict the annotations.

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 front-loaded with the core purpose and every clause adds relevant information (capabilities, pricing, usage caveat). However, the single dense sentence is harder to scan than a bulleted list, slightly reducing readability.

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?

Given zero parameters and an existing output schema, the description need not explain return values in detail, yet it covers what is listed and when to call the tool. It is complete enough for correct invocation, with only a minor gap in not explicitly routing to describe_forecast for single-model details.

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 there is nothing for the description to clarify beyond the empty schema. The baseline for zero parameters is 4; the description appropriately focuses on output content rather than parameter semantics.

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 states a clear verb ('Discover') and resource ('the model panel') and enumerates the model attributes returned (availability, capabilities, ensemble weights, price). It does not explicitly differentiate itself from the sibling describe_forecast tool, so it falls short of a 5.

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 a clear usage context: 'Call this before using forecast in explicit mode' and warns that the deployed panel can differ from documentation. It does not state when NOT to use it or name describe_forecast as an alternative, leaving some guidance implicit.

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

plot_forecastPlot a saved forecastA
Read-onlyIdempotent
Inspect

Render a complete ephemeris.forecast v1 artifact object as PNG (default inline preview) or SVG (embedded resource to save). No inference or forecast charge; hosted processing receives the artifact over the network. Example: {artifact: , format: png}. Requires returned q0.5; never invents a median. Observed history, forecast boundary, median and nominal quantile bands are labeled. Default history view is most recent max(24, 2*horizon) points, capped by available history; history: all shows all. Dates only when supported by recorded metadata, otherwise sampling steps. Bands do not establish calibrated coverage; missing/crossed points are omitted and counted. Maximum 1 MiB input. Select series_index/variate_index for multiple results. Fix argument/shape errors without rerunning inference. User-supplied labels can be corrected in a COPY of artifact context offline; no new forecast needed. Client decides preview/download UI. URNs identify attached bytes, not hosted URLs; no filesystem access, URL fetching or persistent storage.

NameRequiredDescriptionDefault
lowerNoExisting lower quantile. Supply together with upper. Default pairs complementary available levels.
upperNoExisting upper quantile, greater than lower. Supply together with lower.
formatNopng returns an inline image preview; svg returns an embedded text resource to save as .svg. Neither creates a hosted download URL.png
historyNoObserved points to show: default min(available, max(24, 2*horizon)). all shows full history. View changes never change the artifact or inference.
artifactYesComplete ephemeris.forecast schema_version 1 JSON object returned by forecast or saved by Ephemeris CLI. Pass the object, not a filename, URL, resource URI, request ID, or bearer token. Maximum 1 MiB UTF-8 JSON. Contains submitted history; send only data you are authorized to process on this hosted server.
series_indexNoZero-based series index; required when the artifact has multiple series, otherwise 0.
variate_indexNoZero-based variate index; required for multivariate results, otherwise 0.

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds substantial beyond-annotation behavior: 1 MiB input cap, hosted processing receiving the artifact over the network, no filesystem/URL fetching/persistent storage, URNs identifying attached bytes rather than URLs, no hosted download URL, and the guarantee that it never invents a median (requires returned q0.5).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and no sentence is pure filler, but it is a dense semicolon-chained paragraph mixing plotting behavior, data-policy caveats, and client-UI notes. Splitting edge cases (omitted/crossed points, band coverage) from the core contract would improve scanability.

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-format explanation is unnecessary, and the description still covers limits (1 MiB), edge cases (crossed/missing points omitted and counted), labeling behavior, history defaulting, and privacy constraints. An agent has everything needed to call it correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: series_index/variate_index are for multiple or multivariate results, q0.5 must be present and is never synthesized, and 'history: all' vs the max(24, 2*horizon) default changes only the view. This goes beyond restating the schema.

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 first sentence gives a precise verb+resource: render a complete ephemeris.forecast v1 artifact as PNG (inline) or SVG (embedded resource). It is immediately distinguishable from the sibling 'forecast' (which produces a forecast) and 'describe_forecast' (which describes one).

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 establishes when the tool applies: plotting an already-saved artifact, with no inference or forecast charge, and notes that argument/shape errors can be fixed without rerunning inference, and that label corrections happen offline on a COPY. It never explicitly routes the agent between this and 'describe_forecast'/'forecast', so it stops short of full when-not guidance.

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.

  1. 1 tool update
    • Changedget_version2 fields changed
      • addedOutput schema / properties / runtime_tls
        Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "certificate_verification": {
+      "type": "boolean"
+    },
+    "distrusted_roots": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "effective_store_inspected": {
+      "type": "boolean"
+    },
+    "node_version": {
+      "type": "string"
+    },
+    "patched_node": {
+      "type": "boolean"
+    },
+    "safe": {
+      "type": "boolean"
+    },
+    "trust_store_replaced": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "node_version",
+    "patched_node",
+    "trust_store_replaced",
+    "effective_store_inspected",
+    "distrusted_roots",
+    "certificate_verification",
+    "safe"
+  ],
+  "type": "object"
+}
      • changedOutput schema / required
        Previous value: -[
-  "component",
-  "version",
-  "build_commit",
-  "artifact_schema_versions"
-]New value: +[
+  "component",
+  "version",
+  "build_commit",
+  "runtime_tls",
+  "artifact_schema_versions"
+]
  2. 2 tool updates
    • Changedforecast1 field changed
      • changedInput schema / properties / context_len / description
        Previous value: -"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."New value: +"Most recent points per variate to feed the model (history length does not affect pricing), 1 to 16384. Defaults to 256. Values beyond the model's context cap are truncated at the cap."
    • Changedlist_models4 fields changed
      • changedOutput schema / properties / models / items / properties / billing_context_cap / description
        Previous value: -"Most context points billed per variate; longer inputs are billed at the cap."New value: +"Legacy compatibility field, now null. History length does not affect billing; model input limits still apply."
      • addedOutput schema / properties / models / items / properties / billing_horizon_steps
        Added value: +{
+  "const": 64,
+  "type": "number"
+}
      • addedOutput schema / properties / models / items / properties / billing_unit
        Added value: +{
+  "const": "millicredits_per_series_slot_per_horizon_block",
+  "type": "string"
+}
      • changedOutput schema / properties / models / items / properties / price_per_kslot_mc / description
        Previous value: -"Millicredits per thousand series-slots; null when the model is not billable."New value: +"Millicredits per target series-slot per 64 forecast steps; no history multiplier. Null when unpriced."
  3. 4 tool updates
    • Addeddescribe_forecast
    • Changedforecast8 fields changed
      • addedInput schema / properties / context
        Added value: +{
+  "additionalProperties": false,
+  "description": "Local artifact metadata, never sent as model inputs. series aligns with input series; timestamps align with history and future_timestamps with horizon. Units/target/measurement/timezone must come from the user; unknowns stay null. Future-input labels are caller assertions; narrative assumptions do not change inference.",
+  "properties": {
+    "scenario_assumptions": {
+      "items": {
+        "maxLength": 2000,
+        "type": "string"
+      },
+      "maxItems": 100,
+      "type": "array"
+    },
+    "series": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "future_covariate_roles": {
+            "additionalProperties": {
+              "enum": [
+                "known_future",
+                "scenario_assumption",
+                "unspecified"
+              ],
+              "type": "string"
+            },
+            "propertyNames": {
+              "type": "string"
+            },
+            "type": "object"
+          },
+          "future_timestamps": {
+            "anyOf": [
+              {
+                "items": {
+                  "maxLength": 100,
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "measurement": {
+            "anyOf": [
+              {
+                "enum": [
+                  "period_total",
+                  "period_average",
+                  "point_in_time"
+                ],
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "recorded_as_of": {
+            "anyOf": [
+              {
+                "maxLength": 2000,
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "series_id": {
+            "anyOf": [
+              {
+                "maxLength": 2000,
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "source_available_at": {
+            "anyOf": [
+              {
+                "maxLength": 2000,
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "target_description": {
+            "anyOf": [
+              {
+                "maxLength": 2000,
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "timestamps": {
+            "anyOf": [
+              {
+                "items": {
+                  "maxLength": 100,
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "timezone": {
+            "anyOf": [
+              {
+                "maxLength": 2000,
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "unit": {
+            "anyOf": [
+              {
+                "maxLength": 2000,
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
+        },
+        "type": "object"
+      },
+      "maxItems": 64,
+      "type": "array"
+    }
+  },
+  "required": [
+    "series"
+  ],
+  "type": "object"
+}
      • changedInput schema / properties / idempotency_key / description
        Previous value: -"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."New value: +"Client-chosen key, 8 to 128 characters of letters, numbers, dot, underscore, colon or hyphen. A retry with the same key and identical API body replays while retained by the server. Retain the key before submission; expired keys may cause a new charge."
      • addedInput schema / properties / include_artifact
        Added value: +{
+  "description": "Default true: include a portable ephemeris.forecast v1 artifact and embedded JSON attachment (up to 1 MiB), with full input history. Save it client-side for describe_forecast/plot_forecast or the CLI. false returns the existing API response only. No persistent hosted storage is created.",
+  "type": "boolean"
+}
      • changedInput schema / properties / mode / description
        Previous value: -"\"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`."New value: +"\"route\": automatically select a model. \"ensemble\": blend compatible models and may cost more. Neither guarantees accuracy or calibration. \"explicit\": run the single model named in `model`."
      • changedInput schema / properties / series / items / properties / covariates / properties / future / description
        Previous value: -"Known-future channels, each exactly `horizon` long. Every future channel must also appear in `past`."New value: +"Future numeric channels (known future or explicit scenario assumptions), each exactly `horizon` long. Every future channel must also appear in `past`."
      • addedOutput schema / properties / artifact
        Added value: +{
+  "additionalProperties": {},
+  "description": "Portable ephemeris.forecast v1 JSON including full history and local context. Save client-side and pass the object to describe_forecast/plot_forecast. Not a hosted URL.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
      • addedOutput schema / properties / artifact_error
        Added value: +{
+  "type": "string"
+}
      • addedOutput schema / properties / artifact_status
        Added value: +{
+  "description": "included or unavailable. A packaging/size failure never discards the paid forecasts/meta response.",
+  "type": "string"
+}
    • Addedget_version
    • Addedplot_forecast
  4. 4 tool updates
    • First observedforecast
    • First observedget_balance
    • First observedget_usage
    • First observedlist_models

Related MCP Connectors

Related MCP Servers

  • tslab-mcp

    pedrobtz
    A
    license
    A
    quality
    B
    maintenance
    Enables users to perform deterministic time series forecasting through Claude by running reproducible Python statistical and foundation models, providing tools for loading data, cross-validation, forecasting, anomaly detection, and exporting re-runnable manifests without any LLM involvement.
    8
    MIT

  • aurora-mcp

    FantasyLab-ai
    A
    license
    A
    quality
    A
    maintenance
    Glass-box statistical analysis for time series and business data: 19 research-grade methods, cited findings, and measured detector false-fire rates shipped as a calibration corpus. Agents cite real math instead of inventing it.
    7
    31 PyPI
    5
    Apache 2.0
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.

Resources