Skip to main content
Glama

identify_echelon

Identifies the ECHELON VARMA form and Kronecker indices from time-series data, searching candidate row degrees by SC/HQ to reveal which AR/MA cross terms are free.

Instructions

N2 — the third form, the ECHELON VARMA of Lutkepohl and Poskitt (1996), and its Kronecker indices from the data.

The indices n_i are the row degrees of the system's unique echelon form: series i gets its own AR(n_i)/MA(n_i), and their table says which cross terms are free, the contemporaneous ones included. Unlike the VARMA(p, q), the form is identified: no common factors, no MA driven to the wall by spare parameters. The univariate orders do NOT give the indices (every component's marginal is ARMA(N, N), N = the sum of the indices), so they are searched on the stationary vector: a long VAR (its residuals stand for the innovations), then least squares on each candidate's echelon form with one round of Hannan and Kavalieris' correction, and a criterion. SC (default) or HQ, which overfits. Every candidate with each index in 0..max_index while there are at most 256, Hannan and Kavalieris' two steps beyond.

The ORDER of the series is part of the echelon form (A_0 is lower triangular): the indices are those of the files' order. Measured on simulated systems (drvarma docs/STUDY-echelon-search.md): the true indices in 80-97 % of the replications, more with more data; weak cross dynamics are missed (the search underfits), which check_residuals then shows.

On ROUTE U each univariate model's seasonal and fixed-frequency factors are its row's FACTOR (they multiply the whole row; drvarma's echelon stage 4) and the search runs on each row filtered by them; the univariate regular ARMA is replaced by the row's own AR(n_i)/MA(n_i).

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": "identify_echelon"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
criterionNoSC
max_indexNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and discloses important traits: the search procedure, candidate cap of 256, SC default versus HQ overfitting, the 80-97% simulated recovery rate, underfitting of weak cross dynamics, and order sensitivity. It still does not explicitly state side effects or read-only nature, but the algorithmic behavior is unusually well described.

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 dense but front-loads the tool's identity and method, and most details earn their place given the complexity. Some parenthetical reference material is extraneous for an agent, but overall it is structured and purposeful.

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?

The output schema exists, so return values need not be described, and the behavioral/method context is rich. However, completeness is weakened by the unexplained required `name` parameter and the absence of explicit routing versus sibling identification tools.

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 0%, so the description must compensate. It explains `criterion` (SC default, HQ overfits) and gives meaning to `max_index` (indices searched in 0..max_index, candidate cap), but the required `name` parameter is never explained.

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 specific technical purpose: identifying the ECHELON VARMA form and its Kronecker indices from data. It clearly distinguishes this from the ordinary VARMA(p,q), but does not explicitly distinguish it from sibling tools such as identify_cross or identify_matrices.

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 context is implied through discussion of identification, overfitting, and weak cross dynamics, and it points to check_residuals for underfitting symptoms. However, it gives no explicit when-to-use/when-not-to-use guidance versus the many sibling identification tools.

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