Skip to main content
Glama

irf_bands

Generate parametric bootstrap confidence bands for VEC level impulse responses and FEVD by refitting simulated models, so response and decomposition plots show percentile intervals.

Instructions

C6 — Bands for the level responses and the FEVD of the current VEC, by PARAMETRIC BOOTSTRAP (drvec -irfboot N): N simulations of the fitted model, each REFITTED as the data were — same r, same restrictions, same ladder — and Efron's percentiles (90 % and 95 %). No delta method and no covariance Monte Carlo: the level responses are a long non-linear chain to the permanent effect, and a linearisation is what not to trust here.

A JOB, like rank_test: detached, cached by content, on drvec C when its binary is there (the engine in the provenance); a short wait (wait seconds), then the job id. Once finished, impulse_response, variance_decomposition and their plots draw the bands. The bands are conditional on r, the restrictions and the orthogonalisation order (drvec's file order): reordering is a refit and a new job. The horizon is drvec's (10 lags when n < 40, else 20). seed: 0 is the C's; another is a Monte Carlo check (Python engine).

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

Input Schema

NameRequiredDescriptionDefault
NNo
nameYes
seedNo
waitNo

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 provided, the description carries the full behavioral burden and does well: it discloses that this is a detached, content-cached job, how `wait` behaves, that a job id is returned, and that results depend on r, restrictions, orthogonalization order, and horizon. It does not cover failure modes or permissions, but it gives unusually rich job semantics for an unannotated tool.

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?

The purpose is front-loaded, and most sentences add method or workflow value. The text is dense and jargon-heavy, but appropriately sized for a complex statistical job and not padded with repetition.

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 bootstrap job with no annotations, the description covers method, job behavior, dependencies, horizon, and next steps. An output schema exists, so return values need not be explained, but the unexplained required `name` parameter and lack of failure behavior leave minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must explain parameters. It explains N as the number of simulations, `wait` as seconds to wait, and `seed` as either the C's seed or a Python-engine Monte Carlo check. It does not explain the required `name` parameter or state defaults, leaving a meaningful gap.

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

Purpose5/5

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

The description states a specific operation on a specific statistical object: bootstrap bands for the level responses and FEVD of the current VEC. It also distinguishes this from point estimate/drawing siblings by saying impulse_response, variance_decomposition, and their plots draw the bands once this job is finished.

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?

The workflow is implied: run this job, then use impulse_response, variance_decomposition, and their plots to draw the bands. It also says it is a job like rank_test and contrasts the method with delta method/covariance Monte Carlo. However, it does not explicitly say when an agent should choose this versus alternatives or when not to use it.

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