skforecast-ai

Official

Overview Schema Source Related Servers Discussions Admin

plan

Build a forecasting configuration from a profile and horizon, specifying lags, window features, metric, preprocessing, and prediction interval; returns its ID.

Instructions

Build a forecasting plan (lags, window features, metric, preprocessing, interval) from a profile and a horizon. Returns a plan id.

Input Schema

TableJSON Schema

Name	Required	Description
`lags`	No	Lags: an integer n for 1..n, or a list of distinct positive integers. Null for the selection from the partial autocorrelation.
`steps`	Yes	Forecast horizon: number of steps ahead to predict, from 1 to the length of the longest series (12 for a year of monthly data).
`metric`	No	Metric, or list of metrics whose first one is the primary metric (the one that ranks); only the ones given are computed. Null for the metric selected from the data (MAE for one series, MASE for several) and its default panel.
`interval`	No	Prediction interval as two quantiles [lower, upper] with 0 < lower < upper < 1, e.g. [0.1, 0.9] for 80 %. The baseline and ForecasterStats only take symmetric ones (lower + upper = 1). Null for no interval.
`use_exog`	No	Whether to use the exogenous columns of the data: false leaves them out (forecast then takes no exog_path); true fails when the data has none or the forecaster cannot use them. Null uses them whenever the forecaster can.
`estimator`	No	Estimator: one of ['CatBoostRegressor', 'HistGradientBoostingRegressor', 'LGBMRegressor', 'RandomForestRegressor', 'Ridge', 'XGBRegressor'] for the machine learning forecasters, 'Arima' for ForecasterStats, or the Hugging Face model id of a foundation model for ForecasterFoundation (default 'autogluon/chronos-2-small'; model id prefixes: ['amazon/chronos-2', 'autogluon/chronos-2', 'google/timesfm-2.5', 'google/timesfm-3.0', 'Salesforce/moirai-2', 'soda-inria/tabicl', 'priorlabs/tabpfn', 'theforecastingcompany/t0', 'Synthefy/Nori', 'taharnbl/TS-ICL']). ForecasterEquivalentDate takes none. Null for the recommendation.
`forecaster`	No	skforecast forecaster class: ForecasterRecursive or ForecasterDirect (one series, machine learning), ForecasterRecursiveMultiSeries (several series), ForecasterDirectMultiVariate (one series predicted from several), ForecasterStats (Auto-ARIMA), ForecasterFoundation (pre-trained foundation model, no training) or ForecasterEquivalentDate (seasonal naive baseline). Null for the recommendation of the profile.
`profile_id`	Yes	Id returned by `profile`.
`differentiation`	No	Order of differencing of the target before training (an integer of at least 1, usually 1 for a trend); predictions are integrated back. Machine learning forecasters only. Null for none.
`window_features`	No	Rolling features, one entry per window size: {'stats': [...], 'window_size': n}, with stats among ['mean', 'std', 'min', 'max', 'sum', 'median', 'ratio_min_max', 'coef_variation', 'ewm'], e.g. [{'stats': ['mean', 'std'], 'window_size': 7}]. Null for the deterministic selection.
`estimator_kwargs`	No	Keyword arguments of the estimator, e.g. {'n_estimators': 200}. A foundation model only takes context_length, cross_learning, point_estimate, max_horizon, add_calendar_features and n_fourier_terms. Null for the defaults.
`calendar_features`	No	Calendar features generated from the dates (an empty list for none); the encoding follows the estimator. A feature whose column is already an exogenous column used by the plan is rejected. Machine learning forecasters with a datetime index only. Null for those selected from the frequency.
`dropna_from_series`	No	Whether to drop the training rows with missing values; false fails when the data has missing values and the estimator does not accept them. Machine learning forecasters only. Null for the rule.
`target_transformer`	No	Scaler of the target: 'StandardScaler', or 'none' for no scaling. Machine learning forecasters only. Null for the rule.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`cost`	No
`kind`	Yes
`files`	No
`links`	No
`notices`	No
`summary`	Yes
`changeable`	No
`notices_omitted`	No
`values_included`	No
`summary_truncated`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 15, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations indicate it is not read-only and not destructive, so the agent knows it creates a persistent artifact. The description adds that it returns a plan id, which is useful for chaining. However, it does not disclose any side effects, storage behavior, or whether the plan is mutable later, leaving gaps for a state-changing operation.

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?

Extremely concise: one sentence for the action and one for the return value. It is front-loaded with the key verb and purpose, with zero wasted words.

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 the complexity (14 parameters, many optional with defaults, and an output schema for the return), the description is nearly complete. It states the required inputs (profile and horizon) and the output (plan id), and the schema covers all parameter details. The only missing piece is the relationship to sibling tools (e.g., that 'forecast' takes the plan id), but the core information for invocation is present.

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 extensive per-parameter documentation in the schema already provides deep semantics (defaults, allowed values, constraints). The description only lists categories of configuration at a high level; it adds no new meaning beyond the schema, which is acceptable given full coverage but offers no extra value.

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 ('Build a forecasting plan') and enumerates exactly what the plan captures (lags, window features, metric, preprocessing, interval) from its inputs (a profile and a horizon). It clearly distinguishes the tool from siblings like 'forecast', 'backtest', and 'refine_plan' by naming the building activity and its artifact.

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 explicit guidance on when to use this tool versus alternatives like 'refine_plan' or directly invoking 'forecast'. The description implies its role as a setup step but does not state prerequisites (e.g., must call 'profile' first) or dependencies (e.g., 'forecast' consumes the returned plan id).

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

Deploy Server