hidim

Overview Schema Source Related Servers Discussions Admin

tensorize

Converts long, tidy tables into labelled N-d tensors: selected columns become dimensions, value columns fill cells, duplicate axes aggregate, and missing combinations become NaN.

Instructions

Condense a long/tidy table into a labelled N-d tensor: each column in axes becomes a dimension and each value column fills the cells; several value columns add a trailing 'variable' dimension. Coordinates: numeric/datetime axes sort numerically, text axes sort naturally (b2 before b10); sort=False keeps first-appearance order; order={'tenor': ['1m','3m','1y']} pins an explicit order per axis. Duplicate axis combinations are aggregated with agg (mean|sum|first|last|max|min|median|count); missing combinations become NaN. Note that a later reduce 'mean' over a dim averages cells, not underlying rows: to get a row-weighted mean, tensorize agg='sum' and agg='count' and divide. Example: tensorize('opts', axes=['date','strike','maturity_days'], values=['iv']) -> a date x strike x maturity volatility cube.

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>",
      "axes": "<axes>"
    },
    "name": "tensorize"
  }
}

Input Schema

Name	Required	Default
`agg`	No	mean
`axes`	Yes
`name`	Yes
`sort`	No
`order`	No
`values`	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

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 most of it well: it discloses duplicate-combination aggregation, NaN filling for missing combinations, three distinct ordering regimes, and the trailing 'variable' dimension created by multi-column values. It does not say whether the source dataset is modified or a new object is produced, nor anything about cost/laziness on large tables.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but fully front-loaded: purpose first, then coordinates/ordering, then aggregation, then the important caveat, then a concrete example. Every clause carries operational meaning and nothing is restated from the schema.

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 7-parameter reshaping tool, this covers ordering, aggregation, missing data, and multi-value semantics thoroughly, and an output schema exists so return shape needs no explanation here. The only real gap is the unexplained name/new_name pair, which governs where the result lands.

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 5 of 7 params: it enumerates the agg values (mean|sum|first|last|max|min|median|count) that the schema leaves as an unconstrained string, and explains axes, values, sort, and order semantics. The 'name' and 'new_name' parameters are never mentioned, leaving the most basic identity/output-naming behavior undocumented.

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?

Opens with a specific verb+resource: 'Condense a long/tidy table into a labelled N-d tensor', and the concrete example ('date x strike x maturity volatility cube') makes the output shape unambiguous. It implicitly contrasts with the wide-format sibling (tensor_from_wide) by naming 'long/tidy' input, but it never names a sibling outright, so it falls short of the 5 bar.

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 description gives strong conditional guidance for option choices ('sort=False keeps first-appearance order', when to use each agg, and the row-weighted-mean workaround), which is genuinely actionable. However, it never states when to reach for tensorize versus tensor_from_wide, transform, or stack_datasets, so tool selection against siblings is left to inference.

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