hidim

Overview Schema Source Related Servers Discussions Admin

tensor_transform

Preprocess tensors by applying elementwise or dimension-wise operations such as log, sqrt, z-score, anomaly removal, and area weighting to prepare data for analysis.

Instructions

Preprocess a tensor into a new tensor. Elementwise: log1p, log (params offset), sqrt, abs, fillna (params value, or dim for a mean fill). Along dim: demean, zscore, diff / pct_change / log_return (params periods; the axis shrinks), cumsum, normalize (params target). anomaly (dim = a datetime axis, params period=month|dayofyear|dayofweek|hour|quarter, baseline=[start,end]) subtracts the per-period climatology -> anomalies. area_weight (dim = latitude axis in degrees, params power: 0.5 for PCA/EOF, 1 for means) multiplies by cos(lat)^power. Typical EOF chain: tensor_transform(op='anomaly', dim='time') -> tensor_transform(op='area_weight', dim='lat') -> tensor_to_table(row_dim='time') -> project(pca, standardize=False).

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>",
      "op": "<op>"
    },
    "name": "tensor_transform"
  }
}

Input Schema

Name	Required	Description	Default
`op`	Yes
`dim`	No
`name`	Yes
`params`	No
`new_name`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Nov 9, 2026

TDQS

A4.3/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 a fair job: it discloses that the axis shrinks for diff/pct_change/log_return, that anomaly subtracts per-period climatology, that area_weight multiplies by cos(lat)^power, and that the result is a new tensor (non-destructive). It does not cover failure modes such as a dim that doesn't exist, wrong dim type, or missing params keys, which leaves some behavioral risk undisclosed.

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?

Purpose is front-loaded and every clause carries information, including the end-to-end chain example that would otherwise be undocumented. The telegraphic, run-on phrasing ("params value, or dim for a mean fill") is dense to the point of ambiguity and costs some parseability.

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 five-parameter, multi-mode preprocessing tool the description covers op semantics, dim constraints, and params vocabulary well, and the presence of an output schema removes the need to describe return values. The remaining shortfall is that name/new_name are undocumented and error behavior is unstated.

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 largely does: it explains valid op values, the dual meaning of dim (datetime axis vs latitude axis in degrees), and the per-op params keys (offset, value, periods, target, period, baseline, power) with their accepted values. However, the two most fundamental parameters, name (input tensor) and new_name (output tensor), are never explained anywhere, leaving a real gap at 0% schema coverage.

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?

States a specific verb and resource ("Preprocess a tensor into a new tensor") and then enumerates the operation families it covers (elementwise, along-dim, anomaly, area_weight), which makes it clearly distinguishable from siblings like slice_tensor, tensor_to_table, and project. An agent can identify what this tool does without opening the schema.

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?

Strong in-tool guidance: it maps goals to ops (e.g. power=0.5 for PCA/EOF vs 1 for means, dim must be a datetime axis for anomaly) and closes with a concrete typical EOF chain that shows how this tool composes with tensor_to_table and project. It stops short of saying when NOT to use it versus siblings such as transform or slice_tensor, so the alternative-selection guidance is implicit rather than explicit.

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