Skip to main content
Glama

long_run

Computes the long-run relation of a VEC model, including theta, textbook and model half-lives, plus Gonzalo–Ng permanent/transitory decomposition and common-trend variance shares.

Instructions

C5 — The long run of the current VEC, read: theta (beta normalised, with its sign: Y1 = theta' Y2 + a stationary error), and two half-lives, both computed by sima because drvec computes neither — the TEXTBOOK one, ln 0.5 / ln(1 - |alpha|) on the variable the relation is solved for (orientation: exact only for one relation with no short-run dynamics), and the MODEL's, the half-life of the equilibrium error beta'Y in the fitted model's own response (the same weights as the level IRF; its norm over the shocks, which does not depend on the Cholesky order). Then Gonzalo and Ng's permanent/transitory decomposition: alpha_perp (the common trends), the share of each level's forecast-error variance due to the permanent shocks, and the self-check that a transitory shock has no long-run effect. Point values: bands only through the bootstrap (irf_bands). horizon: how far the responses go (0: 60 periods, or 8 years of seasonal data).

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

Input Schema

NameRequiredDescriptionDefault
nameYes
horizonNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.1/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the behavioral burden. It discloses that bands require a separate bootstrap tool and includes a self-check for transitory shocks, but it does not explicitly state that the operation is read-only or non-destructive. The description is rich in output details but lacks explicit safety or permission context.

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 a single dense paragraph with no front-loaded summary. It starts with cryptic notation ('C5 —') and uses heavy econometric jargon. The content is relevant but could be better structured with bullet points or a clear opening sentence to improve readability.

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 fully explained. However, the description omits the required name parameter and does not mention prerequisites (e.g., needing a fitted VEC model). For a complex tool with no annotations and zero schema coverage, it provides substantial output detail but falls short on input clarity and safety context.

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 description coverage is 0%, so the description must explain both parameters. It explains horizon well (default 0, 60 periods or 8 years), but the required name parameter is not described at all. The agent is left guessing what name refers to (likely a model identifier), which is a significant gap for a required parameter.

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 specifically states that it computes the long-run relations of a VEC model: theta, two half-lives, Gonzalo-Ng decomposition, and related outputs. It distinguishes itself from irf_bands for bands, though it does not explicitly contrast with siblings like impulse_response or variance_decomposition. The dense jargon may obscure the purpose for non-experts, but an agent familiar with econometrics can identify what the tool does.

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 mentions that bands are only available via irf_bands, which is a useful usage constraint. However, it does not state when to use this tool versus other long-run related tools, nor does it specify prerequisites such as having an estimated VEC model. Usage is implied but not fully explicit.

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