sima

Overview Schema Source Related Servers Discussions Admin

reorder

Compares impulse responses under an alternative Cholesky ordering to reveal whether results depend on variable order; refuses VEC models where ordering changes the fit.

Instructions

N6 — The impulse responses under ANOTHER Cholesky order, against the files'.

The reduced-form model (Phi, Theta, Sigma) does not depend on the order of the series; only the orthogonalisation does. So nothing is re-estimated: the model is permuted, the responses recomputed, and put back in the files' order to compare cell by cell. A response that changes sign or size with the order is an assumption, not a finding. With a diagonal covariance the order does not matter at all, and the tool says so. order_json: the series names in the new order, e.g. '["WTI", "IPC_ES"]'. On a VEC it REFUSES: there the order is also the normalisation, so another order is another fit (estimate_vec with normalise_on).

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>",
      "order_json": "<order_json>"
    },
    "name": "reorder"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`horizon`	No
`order_json`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 30, 2026

TDQS

A4/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 well: it discloses that no re-estimation occurs, that the model is permuted and responses recomputed, that outputs are returned in the files' order, and that VEC input is rejected. It stops short of stating permission/auth needs or the exact shape of the refusal/error, which keeps it at a 4 rather than a 5.

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 behavioral content is dense and front-loaded with the correct concept, but the prose is sprawling, contains awkward line-wrapping and a malformed first sentence, and mixes rationale, refusal behavior, and parameter guidance without clean separation. Every idea earns its place, but the packaging is loose.

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?

An output schema exists, so return-value explanation is correctly omitted, and the description covers the refusal case, the invariance rationale, and the comparison semantics thoroughly. The remaining gap is the unexplained `name` and `horizon` parameters, which leaves the definition slightly incomplete for invocation.

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?

Schema description coverage is 0%, so the description must compensate. It fully explains `order_json` including an example format ('["WTI", "IPC_ES"]'), but says nothing about `name` (presumably the model/file identifier) or `horizon` (default 12), leaving two of three parameters undocumented in both schema and prose.

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 opening lines state a specific operation: recompute impulse responses under a different Cholesky ordering and compare them cell by cell against the files' ordering, with the key reassurance that nothing is re-estimated. The generic name 'reorder' is rescued by the prose, which makes the domain operation unambiguous, though the jargon-heavy phrasing and dangling first sentence ('against the files'') cost it a clean 5.

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 gives explicit when-to-use framing ('A response that changes sign or size with the order is an assumption, not a finding') and clear when-not guidance: it REFUSES on a VEC and directs the agent to estimate_vec with normalise_on instead. It also flags the degenerate case where a diagonal covariance makes ordering irrelevant and the tool says so.

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