Skip to main content
Glama

impulse_response

Compute orthogonalised impulse responses from the last estimated VAR/VEC model, using Cholesky order and Monte Carlo bands to flag effects that differ from zero.

Instructions

N6 — Orthogonalised impulse responses of the last estimated model.

Cholesky in the ORDER OF THE FILES: an identifying assumption, stated in the output. With a strong contemporaneous correlation, reload the files in another order and compare before reading a response as a finding. With bands (default): 95% Monte-Carlo bands from the covariance of the estimates, redrawing the whole model through the ladder's cast; a response whose band covers zero is not a finding. On a VEC: the responses of the LEVELS (drvec), in drvec's order — the VEC's normalisation order — and their permanent effect; the bands come only from the parametric bootstrap (irf_bands, a job), never from the covariance.

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

Input Schema

NameRequiredDescriptionDefault
nameYes
bandsNo
ndrawsNo
horizonNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.4/5.0
Behavior4/5

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

No annotations, so the description carries the full burden, and it does substantial work: it discloses the Cholesky ordering assumption tied to file order, that bands are 95% Monte-Carlo draws from the estimate covariance redrawing the whole model, and that a band covering zero is not a finding. It also discloses VEC-specific behavior (levels in drvec order, permanent effect, bootstrap-only bands via a separate job). It stops short of stating cost/side effects of the 800 default draws or whether anything is cached.

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?

Front-loaded with the core statement and broken into short paragraphs, one per concern (ordering, bands, VEC). Dense but nearly every sentence carries behavioral information; the 'N6' label and some econometric shorthand are the only waste.

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?

Output schema exists, so return values needn't be explained, and the hard interpretive context (ordering, band meaning, VEC path) is covered. However, three of four parameters remain opaque and the description never clarifies what `name` refers to or how `horizon`/`ndraws` change the output, which is a real gap for a 4-parameter tool with zero schema coverage.

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 compensate, but it only explains `bands` (its default and the 95% covariance-based construction). `name` (required), `ndraws` (default 800), and `horizon` (default 12) are left entirely unexplained in both schema and description.

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?

States a specific verb+resource: 'orthogonalised impulse responses of the last estimated model', which is a distinct output from forecast or variance_decomposition. It also names irf_bands as the alternative for VEC band estimation, so an agent can separate the two. The opaque 'N6' prefix adds nothing but does not obscure the purpose.

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?

Gives a real interpretive precondition (with strong contemporaneous correlation, reload files in another order and compare) and routes VEC band work to irf_bands. But it never says when to call this rather than forecast, variance_decomposition, or plot_impulse_response, and no explicit exclusions are given. Usage is implied by context rather than stated.

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