Skip to main content
Glama

estimate

Fit a joint VARMA candidate with specified cross orders, optional linked pairs, and full/diagonal covariance, then report parameters, LR tests, innovation correlations, and optimizer diagnostics.

Instructions

N3/N4 — Estimate a candidate: cross orders p, q; full or diagonal covariance.

Each series keeps its univariate model on the diagonal (its ARMA factors are re-estimated jointly, its deterministic terms stay as in its file). Reports the parameters, the LR test against the univariates (in sample: necessary, not sufficient), the innovation correlations, the residual portmanteau and how the optimiser stopped. reason is recorded in the guion: say why this candidate.

links restricts the cross dynamics to the pairs the evidence points at: "A<-B, C<-A" (B enters the equation of A, AR and MA, every lag up to p and q; names as in identify_cross). Empty (default): every pair. identify_cross proposes it as option (d) when only some pairs showed anything.

start: where the cross terms start — "zero" (the default for the VARMA) or "preliminary", Jenkins and Alavi's preliminary estimates (the cross MA from the univariate residuals' cross covariances, the cross AR from Yule-Walker). Usually the same optimum in fewer iterations; on an ill-defined estimation (the MA wall) a second path worth comparing. The echelon form starts at Lutkepohl and Poskitt's least-squares estimates ("echelon", its default).

cross: how the cross MA enters — "additive" (default: a cross polynomial beside the univariate operators) or "residual", Jenkins and Alavi's form (3.22): a model for the univariate residuals, multiplied by each series' univariate MA. The same when the univariate models have no MA factors; when they have (an airline), the two are different candidates — on m6 the residual form converged inside where the additive one stopped on the MA wall. identify_matrices' method 2 proposes it.

zeros: coefficients held at zero, by their printed names — Tiao and Box's simplification (simplify proposes them): cross ones "AR3[A<-B], MA1[B<-A]" on either route; a series' own "phi_A[B^4], theta_A[B^1]" on route V, and on route U in the echelon form (with indices), whose own AR(n_i)/MA(n_i) is sima's; otherwise route U's diagonal is the univariate model, art's. A fit already made with the same arguments is reused, not refitted.

indices: the ECHELON FORM with these Kronecker indices, one per series in the files' order, e.g. "1, 2, 1" (identify_echelon proposes them). Series i gets a free AR(n_i)/MA(n_i) of its own, the cross terms follow Lutkepohl and Poskitt's (1996) table, and the contemporaneous AR0[i<-j] terms make A_0 lower triangular: the order of the series is part of the model. p and q are then max(n_i); leave them at 0. links and zeros restrict it further. On route U the free AR(n_i)/MA(n_i) replaces the univariate model's regular ARMA, and its seasonal and fixed-frequency factors multiply the whole row (the row FACTOR), checked by an LR test against the same rows with the factor's restriction dropped.

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

Input Schema

NameRequiredDescriptionDefault
pNo
qNo
nameYes
crossNoadditive
linksNo
startNo
zerosNo
reasonNo
diagcovNo
indicesNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the load and does well: it discloses what is reported (LR test, innovation correlations, portmanteau, optimiser stopping), that a fit with identical arguments is reused rather than refitted, and that `reason` is persisted into the guion. It does not state cost/runtime or that estimation can fail at the MA wall in a way needing retry beyond the start hint.

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 first sentence front-loads the core, but the remainder is a dense wall of jargon with anecdotal asides ('on m6 the residual form converged inside where the additive one stopped on the MA wall') that add length without much selection value. It is justified in size by 10 undocumented parameters, but the prose could be tightened substantially.

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?

For a complex model-specification tool with an output schema and no annotations, the description covers the modelling alternatives thoroughly and need not explain return values. Remaining gaps are prerequisites (data loaded, univariate models built) and what `name` refers to, plus no note on runtime.

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 0% and titles are bare, so the description must compensate — and it largely does, explaining semantics for links, start, cross, zeros, indices, and the p/q interplay under the echelon form. Only `name` and `diagcov` (mentioned only obliquely as 'full or diagonal covariance') go without explicit definition.

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 opening line names a specific verb and object ('Estimate a candidate: cross orders p, q; full or diagonal covariance'), and the body makes clear this fits a multivariate/cross-dynamics model on top of existing univariate models. It is clearly distinct from estimate_vec only by inference (the 'cross', 'links', 'indices' vocabulary), not by an explicit sibling contrast.

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?

Guidance is embedded per option rather than stated as a decision rule, but it is concrete: 'preliminary' is for ill-defined estimation / the MA wall, 'residual' cross form is proposed by identify_matrices method 2, 'zeros' comes from simplify, 'indices' from identify_echelon. An agent can infer which lever to pull and which sibling supplies it, though there is no explicit 'use estimate instead of X when...' statement.

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