Skip to main content
Glama

test_restriction

Tests restrictions on alpha, beta, or Gamma of a VEC using likelihood ratio, reporting LR, degrees of freedom, chi-square p-value, and both log-likelihoods.

Instructions

C3 — A restriction on alpha, beta or Gamma of the current VEC, tested by LIKELIHOOD RATIO (never by the .out's Wald, which depends on the normalisation): LR, its degrees of freedom and chi2 p-value, both logLs.

weakex: a series' name — weak exogeneity, its row of alpha at zero ("who corrects": it does not adjust to the equilibrium). alpha: alpha = A psi, A as a JSON matrix (rows in drvec's order, as estimate_vec prints it) or a file in drvec's format ("M sa", then M rows) — jointly for several series. fixb2: every entry of B2 held at this VALUE (required: without one drvec holds B2 at its static OLS value, which is not a test); fixb2=0 in the mixed case is the ladder's model. fixb2row: rows of B2 held, "NAME=value, NAME2=value". weakex/alpha combine with fixb2row (the joint LR). gamma: NO FEEDBACK in the short run, "R30,R3 <- R0T" (the equations, then the regressors; "A <- B; C <- D" for several): Gamma_k[eq][reg] = 0 at every lag (drvec -gzero; p >= 2, q = 0). With weakex/alpha on the same inputs it is the CONDITIONAL model's joint test (weak exogeneity and no feedback, Johansen 1992): when it holds, the report offers mtram with the same files and the roles. gamma does not combine with fixb2/fixb2row.

drvec fits the free model of these LRs as the C does (one est() from a cold start for alpha and weakex; no ladder for fixb2row), so its free logL can be below the adopted VEC's and the LR understated: sima takes the BEST FREE FIT it knows, says which, and shows both when they differ. adopt: the restricted VEC becomes the current model. Not available (drvec): restrictions on one cointegrating vector, a bootstrap of this LR, a rank under a restriction.

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

Input Schema

NameRequiredDescriptionDefault
nameYes
adoptNo
alphaNo
fixb2No
gammaNo
weakexNo
fixb2rowNo

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 behavioral burden and discloses important traits: LR-based testing rather than Wald, the possibility that drvec's free logL understates the LR, and that adopt makes the restricted VEC the current model. It does not fully specify permissions or failure behavior, but it is unusually transparent for a complex statistical test.

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 core purpose is front-loaded, and most sentences carry necessary domain detail, but the description is a dense run-on paragraph with heavy parentheticals and semicolons. It is information-rich but poorly structured for quick agent parsing.

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 restriction-testing tool with no annotations and an output schema, the description covers the test method, parameter combinations, side effects of adopt, and drvec limitations. The main missing piece is an explicit definition of the required name parameter.

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%, so the description must explain the seven parameters, and it does so for alpha, fixb2, fixb2row, gamma, weakex, and adopt with format and combination details. The required name parameter is not explicitly defined, which is a notable gap but not enough to erase the otherwise strong compensation.

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 operation: test a restriction on alpha, beta, or gamma of the current VEC using a likelihood-ratio test. It also distinguishes the method from the .out Wald test, but it does not explicitly differentiate this tool from sibling tools such as rank_test or estimate_vec.

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?

It gives clear conditions for using each restriction type, including that weakex/alpha combine with fixb2row and that gamma does not combine with fixb2/fixb2row. It also lists cases not available under drvec, though it does not explicitly route the agent among sibling tools.

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