Skip to main content
Glama

evaluate

Compares candidate VARMA forecasts with univariate yardstick models across rolling origins to verify gains in RMSE and MAPE, flagging models that do not improve forecast accuracy.

Instructions

N5 — The yardstick: does the candidate forecast better than the univariates?

Estimates the candidate AND the diagonal system (the univariate models) on the first estwin observations, holds the parameters fixed, and forecasts from every origin to the end of the data, horizon steps ahead. Compares RMSE and MAPE series by series and horizon by horizon. A VARMA that does not gain here has no reason to exist, whatever its in-sample significance.

estwin counts observations of the FIRST series; leave enough data after it (at least a few dozen origins) or the comparison says little. links, zeros and indices: as in estimate, the same candidate.

ON A VEC (the current model is one, estimate_vec): the VEC's rolling-origin forecasts (drvec's -estwin/-f: the fit on the first rows, parameters held, errors in each series' own units) against the univariates on the same origins, and against the VARMA in differences when one was estimated. THE RULE depends on the purpose recorded at N1c: a VETO when it is "forecast", a CAVEAT (always reported) for a "long run" claim. p, q and the VARMA arguments are then ignored.

yardstick (route V): the analyst's univariate models, one fue file per series (a JSON list or comma-separated paths), e.g. their .pre from art. Without it the yardstick is route U's light builder, which takes the first of a tie in art's ranking; the report names the models either way. Once given it stays for the session (forecast_uncertainty and structure use it). On route U the yardstick is already the loaded files.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "evaluate"
  }
}

Input Schema

NameRequiredDescriptionDefault
pNo
qNo
nameYes
crossNoadditive
linksNo
zerosNo
estwinNo
diagcovNo
horizonNo
indicesNo
yardstickNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.3/5.0
Behavior4/5

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

The description discloses the core behavior in detail: estimate on the first `estwin` observations, hold parameters fixed, forecast from every origin, and compare RMSE/MAPE by series and horizon. It also notes VEC-specific behavior, veto/caveat semantics, and that `yardstick` persists for the session. It does not clarify permissions, side effects, or computational expectations, but the procedure is unusually well specified.

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 description is front-loaded with the main purpose and forecasting procedure, but it is dense, jargon-heavy, and includes rhetorical lines that do not help invocation. The VEC and yardstick details are useful but could be structured more cleanly for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 described. Still, for a complex 11-parameter tool with no annotations and no schema descriptions, the definition leaves important parameter meanings and side-effect details under-specified, even though the core evaluation workflow is explained.

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

Parameters2/5

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

Schema coverage is 0% for 11 parameters, so the description must carry the full burden. It meaningfully explains `estwin`, `horizon`, and `yardstick`, and partially covers `p`, `q`, `links`, `zeros`, and `indices`, but leaves `name`, `cross`, and `diagcov` unexplained.

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 opens with a clear goal: compare the candidate forecast against univariate models using RMSE and MAPE. It distinguishes this from in-sample significance and mentions the VEC variant, but relies on jargon like N5 and route V/U rather than naming sibling alternatives.

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?

It implies when this matters ('A VARMA that does not gain here has no reason to exist') and explains that VEC evaluation depends on the purpose recorded at N1c. However, it does not explicitly state when to use this versus forecast, forecast_uncertainty, or structure, nor does it give clear preconditions beyond `estwin`.

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