sima

Overview Schema Source Related Servers Discussions Admin

check_residuals

Diagnose a fitted VARMA model by checking residual autocorrelation, cross-correlation, and portmanteau statistics; report large residuals, matrix structure, conclusions, and diagnostic figures.

Instructions

N4 — Check the last estimated model as Jenkins and Alavi (1981, §5.2) do, and show it as art's diagnosis: the report, then the figures.

The report: 1 · TABLE — (1) the large residuals, judged on the UNCORRELATED transformed residuals (the a_it correlate at lag 0, so one by one they cannot be judged), with their dates — a known cause goes to intervention analysis, in art, before anything else is read; (2) the residual correlation matrices R_k(a), with what is beyond the band; (3) the portmanteau matrix Q_ij, as a summary. 2 · WHAT IT SHOWS, 3 · CONCLUSIONS, 4 · DECISION. If the matrices show structure, a model for the residuals is entertained and combined with the fitted one, as at identification.

The figures, as drvus drew the diagnosis and their figure 7: fue's panel for each residual series (the residuals with +-2 bands, the acf with its Q, the pacf), and the residual ccf of each pair (GraphMaker's, with Hosking's P). nlags (the matrices) defaults to max(6, frequency). The portmanteaus keep at least 2 lags beyond the parameters: the legacy lags move up when a long model in annual data would leave none.

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

Input Schema

Name	Required	Description	Default
`name`	Yes
`nlags`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 30, 2026

TDQS

C2.7/5.0

Behavior3/5

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

No annotations exist, so the description carries the whole burden, and it does disclose the return shape in unusual detail (four-part report: table, what it shows, conclusions, decision; plus panels for each residual series and pairwise ccf). It also discloses the precondition that a model must already be estimated. Missing: whether figures are written to disk or returned, and no error or failure behavior for a tool that appears to compute many matrices.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is substantive but badly ordered for a tool definition: literary references, section numbering that describes the tool's output rather than the tool, and opaque shorthand compete with the two facts an agent needs (what it computes, what `name` is). Several sentences earn their place; many others are citation-flavoured noise that a caller cannot resolve.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description must cover setup, effects, and returns alone. It covers the report contents well, but leaves the required `name` parameter undefined, gives no indication of cost or failure modes, and relies on vocabulary (`art`, `drvus`, `fue`, `guion`) that is not defined anywhere in the tool surface.

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%, so the description must document both parameters in full. It handles `nlags` well – its meaning (matrix lag count), its default of max(6, frequency), and a minimum-lag rule that overrides legacy behaviour – though this actively conflicts with the schema's `default: 0`. The required `name` parameter is never explained at all; an agent must guess whether it names the model, the session, or the dataset.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description does name a verb and object – check the residuals of the last estimated model – and promises a report plus figures. But the framing is drowned in unexplained proper nouns and in-jokes ("N4", "art's diagnosis", "drvus drew the diagnosis", "fue's panel", "GraphMaker's"), so an agent must strip vocabulary to recover the actual purpose. It also never distinguishes itself from the close sibling plot_residual_ccf, which appears to produce overlapping output.

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?

There is real sequencing guidance: known-cause large residuals go to intervention analysis "before anything else is read", and structure in the matrices means entertaining a combined residual model. That tells an agent what to do with the output, but nothing states when to call this instead of `evaluate`, `plot_residual_ccf`, or `study_estimation`, and there is no prerequisite statement beyond the implicit "must have estimated a model".

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