Zero-shot time series forecasting server using Google's TimesFM-3 model. Supports univariate and multivariate forecasting with optional covariates and calendar labels.
Two tools with complete input schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. The `forecast` tool has a complex, well-documented interface with 9 parameters covering univariate/multivariate forecasting, covariates, and calendar labeling. The `forecast_demand` tool is a deprecated alias with minimal parameters. Both descriptions exceed 100 chars and explain the TimesFM-3 non-commercial license constraint. However, parameter descriptions are sparse (many lack detail on format/constraints), output schemas are not formally documented, and error handling guidance is absent. No tool annotations (readOnlyHint, destructiveHint) despite both being read-only operations.
Zero-shot forecast with Google TimesFM-3. Pass one series (univariate) or several related series (joint multivariate). Optional past_covariates must be length T. Optional future_covariates (known ahead, e.g. promo flags) must be length T + horizon. Optional start + freq (or a history timestamp list) labels the forecast with ISO dates. Irregular timestamp lists are rejected; gaps are not filled. Returns a median point forecast plus nine quantile bands (q10 through q90) per series. TimesFM-3 weights are licensed for non-commercial, non-production use only.
Deprecated alias of `forecast` for a single series. Prefer `forecast`. Same TimesFM-3 non-commercial license limit.
Output schema not documented. Tool descriptions mention 'Returns a median point forecast plus nine quantile bands (q10 through q90) per series' but no formal schema (field names, types, structure) is provided. LLMs cannot plan downstream operations or extract results reliably.
Parameter descriptions lack format/constraint details. E.g., 'freq' accepts 'H, D, W, or M' but description does not state this is an enum or what each letter means. 'timestamps' must be 'strictly regular' but no guidance on ISO 8601 format or tolerance for irregularity. LLMs will guess and pass invalid values.
No error handling guidance. Tool descriptions do not explain what happens if series lengths mismatch, covariates are wrong length, timestamps are irregular, or horizon is invalid. No recovery hints (e.g., 'If horizon is too large, reduce it to 30'). Agents cannot self-correct on failure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Missing tool annotations. Both tools are read-only (forecast operations do not modify state), but neither declares readOnlyHint=true. This prevents agents from optimizing caching and retry logic.
Deprecated alias without clear migration path. `forecast_demand` is marked 'Deprecated alias of `forecast`' but no guidance on when/how to migrate. If agents still call it, they bypass the richer interface. Consider removing or adding a deprecation warning in the response.