hidim

Overview Schema Source Related Servers Discussions Admin

project

Reduce high-dimensional numeric table features into a lower-dimensional embedding stored as a new table, preserving label, datetime and cluster columns for colouring; returns quality metrics.

Instructions

Reduce a table's numeric features to n_components and store the embedding as a new table (name__method) with label, datetime and cluster columns carried over for colouring. Returns quality metrics, not coordinates.

methods: pca (explained variance, top loadings; full vectors via loadings()), svd, ica, random (Gaussian random projection), kpca, tsne, umap (needs umap-learn), isomap, lle, mds, spectral. Non-linear methods run on a random sample (default caps: tsne 5000, umap 50000, isomap/lle/spectral 5000, mds 2000; override with sample) and get an automatic PCA to 50 dims first when there are more than 50 features (pre_pca). params passes method-specific keywords (perplexity, n_neighbors, min_dist, kernel, metric, ...). standardize: 'auto' (default; raw scales for pixel/count/[0,1] data, z-scores otherwise), True or False. clip_z=10 clips z-scores so near-constant or sparse features cannot dominate. Every method reports trustworthiness (1.0 = neighbourhoods perfectly preserved). ascii=True adds a coarse text density map.

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

Input Schema

Name	Required	Default
`name`	Yes
`seed`	No
`ascii`	No
`clip_z`	No
`method`	No	pca
`params`	No
`sample`	No
`pre_pca`	No
`features`	No
`new_name`	No
`standardize`	No	auto
`n_components`	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/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 a new table is created, that it returns quality metrics rather than coordinates, that trustworthiness is reported, and how standardize/clip_z defaults change numeric behavior. It omits failure modes and what happens if the target table name already exists, which are the main remaining gaps.

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?

Front-loaded with the core action and output, then dense parameter guidance with no filler. The long run-on method enumeration and parenthetical asides are justified by information density but could be tightened into a list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, annotation-free tool, the description covers most behavior well and an output schema exists so return values need not be explained. Still, three parameters (notably features, which columns get reduced, and new_name) are undocumented anywhere, leaving an agent guessing on a key input.

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 coverage is 0%, so this text does real work: it explains method options, params pass-through keywords, sample and pre_pca defaults, the three-way standardize semantics ('auto' rules included), clip_z rationale, and ascii. It leaves features, new_name, and seed entirely unexplained, which is a meaningful hole given 12 parameters.

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?

Names a concrete verb and resource ('Reduce a table's numeric features to n_components and store the embedding as a new table'), and describes the exact output artifact (name__method<k> with label/datetime/cluster carried over). This clearly separates it from siblings like transform, cluster, and loadings, which only extract derived info or operate on labels.

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?

Gives useful in-tool guidance such as the method menu, sampling caps for non-linear methods, and the automatic PCA pre-reduction above 50 features. However, it never states when to pick this tool over a sibling (e.g. transform for applying an existing reduction, or cluster for grouping), so selection against the broader toolset 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.