Skip to main content
Glama

add_exogenous

Add exogenous inputs to a VEC model by integration order, using named series or linked input files, and optionally adopt the resulting fit.

Instructions

C4 — Exogenous inputs to the current VEC, dispatched by their order of integration, as in drtran. The VEC without inputs is the base, and the LR against it is the test.

An input of the SAME order (I(1), a series of the system): series names it; it stays in the system with its alpha row at zero and none of the others' short run (drvec -xsys: STRONG exogeneity, the LR against the free VEC). It cannot be in the Y1 block, and drvec needs q = 0.

An input of ANOTHER order (an I(0) input on I(1) outputs): inputs are its fue files (a JSON list or comma-separated; their .pre stays frozen) and links the network, "OUT <- IN b r s; OUT2 <- IN b r s" (r <= 2): it is subtracted in levels (drvec -xpre/-xlink). drvec fits the VEC without the inputs first; with omega = 0 the bridge must reproduce it. Refused by drvec (inherited): a rank test with inputs (the rank is C1's, without them), -xlink with forecasts or bootstraps, -xsys with q > 0 or with a restriction on alpha. adopt makes the fit with inputs current.

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

Input Schema

NameRequiredDescriptionDefault
nameYes
adoptNo
linksNo
inputsNo
seriesNo

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 full burden and does so: it discloses the state mutation (`adopt` makes the fit with inputs current), preconditions (input cannot be in the Y1 block, drvec needs q = 0, inputs are subtracted in levels, .pre stays frozen), and inherited failure modes. What it leaves unclear is what happens to the current fit when `adopt` is false, and the meaning of the `name` argument.

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?

Every sentence carries real information and the two-mode split is front-loaded after the opening line, but the prose is dense with unexplained flags (-xsys, -xlink, -xpre) and capitalized classifiers, making it slow to parse. The core action could have been stated in one plain sentence before the flag-level detail.

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 high-complexity econometric mutation tool with no annotations, the description covers behavior, preconditions, refusals and argument formats, and an output schema exists so return values need no explanation. The remaining gap is the undefined `name` parameter and the ambiguous state when `adopt` is omitted.

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 description coverage is 0%, so the description must compensate, and it does for four of five parameters: `series` (same-order series, alpha row zeroed, strong exogeneity), `inputs` (JSON list or comma-separated fue files), `links` ("OUT <- IN b r s" with r <= 2), and `adopt` (promotes the fit with inputs to current). Only `name` is left completely undefined.

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?

Identifies the resource precisely (exogenous inputs to the current VEC) and splits it into two clearly distinguished modes, same-order `series` vs other-order `inputs`/`links`, which lets an agent tell it apart from siblings like estimate_vec or long_run. The verb is only implicit (the name supplies 'add'), and the opening is a noun phrase rather than a statement of action, so it stops short of a 5.

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?

Gives concrete routing rules: use `series` when the input has the same order as the system, use `inputs`/`links` when it has another order, and use `adopt` to make the resulting fit current. It also enumerates the configurations drvec refuses (rank test with inputs, -xlink with forecasts/bootstraps, -xsys with q > 0 or an alpha restriction), which functions as when-not guidance. No sibling alternative is named for the non-exogenous case, so it is not a full 5.

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