Skip to main content
Glama

estimate_vec

Estimate and adopt a VEC model at a chosen rank, using Hessian standard errors and requiring a finished rank test or theory-based justification for non-proposed ranks.

Instructions

C2 — The adopted VEC at rank r (drvec.fit with -fdhess: the standard errors from the Hessian at the optimum). REFUSES without a FINISHED rank_test for the same specification (p, q, case, drifts, files), unless the analyst adopts r on THEORY: theory says why, and it is written in the guion as such, with the bootstrap's numbers beside it when they exist. A rank other than the bootstrap's proposal needs theory too. r = 0 is the VARMA in differences (drvarma, N2); r = M is not a VEC.

THE ROLES are asked for: normalise_on names the r series beta is normalised on (the Y1 block); drvec's order is the others in the session's order, then these. That order is also the Cholesky order of the level responses, so another normalisation is ANOTHER FIT (this tool again), never a reorder. Default: the last r of prepare_vec's order (the I(0) series in the mixed case).

Reports drvec's .out blocks verbatim (parameters, the VEC's matrices, the normalisation share, the residual diagnostics), alpha read from the matrix (Johansen's sign), the canonical weights beside beta-hat, and the optimiser's stopping criterion: a fit that stopped on a ridge (E1's 2 1 1 -case 2) is declared NOT A DEMONSTRATED MAXIMUM, with multistart and a lower q offered. The .out's Wald tests are not citable (they depend on the normalisation): restrictions go by LR (test_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>",
      "r": "<r>"
    },
    "name": "estimate_vec"
  }
}

Input Schema

NameRequiredDescriptionDefault
rYes
nameYes
theoryNo
multistartNo
normalise_onNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: it discloses refusal conditions, writes theory into the guion, treats another normalisation as another fit, reports drvec's .out blocks, flags ridge-stopped fits as not demonstrated maxima, and notes that Wald tests are not citable. This is unusually complete disclosure of prerequisites, side effects, and interpretation caveats.

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 content is valuable, but the structure is dense with run-on parentheticals, all-caps emphasis, and domain shorthand. It is front-loaded with the core meaning, yet readability suffers and some sentences carry multiple clauses that could be separated.

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?

Given a complex tool with no annotations, 0% schema description coverage, and an output schema, the description is largely complete on prerequisites, normalization behavior, and return interpretation. It still leaves the name parameter and multistart's exact integer semantics to inference.

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; it explains r's meaning, theory's role, normalise_on's ordering/default semantics, and multistart's availability after ridge stops. It does not explain the name parameter or fully define the integer meaning of multistart, so it falls short of complete 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 identifies the resource as the VEC at rank r and ties it to drvec.fit with -fdhess, which is specific enough to distinguish this estimation step from siblings such as rank_test and prepare_vec. The purpose is clear to a domain-aware agent, though the dense C2/drvec jargon prevents a fully plain-language statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states the prerequisite (a FINISHED rank_test for the same specification), the exception (theory-based adoption of r), and when theory is required for non-bootstrap ranks. It also notes r=0 as VARMA in differences, r=M as not a VEC, and routes restriction testing to test_restriction via LR.

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