hidim

Overview Schema Source Related Servers Discussions Admin

make_synthetic

Generate synthetic datasets for demos and sanity checks, including clustered blobs, 2-D manifolds, Gaussian noise, low-rank matrices, and options surfaces.

Instructions

Create a synthetic dataset for demos and sanity checks.

kinds: blobs (k Gaussian clusters in d dims, label column), swiss_roll / s_curve (2-D manifold embedded in d dims, colour column t), gaussian (iid noise: the null model for the diagnostics), lowrank (rank-k matrix plus noise), options_surface (long table date x strike x maturity_days -> iv, spot, volume; for tensorize demos).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "make_synthetic"
  }
}

Input Schema

Name	Required	Default
`d`	No
`k`	No
`n`	No
`kind`	No	blobs
`name`	No
`seed`	No
`noise`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Nov 9, 2026

TDQS

B3.2/5.0

Behavior2/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 it only partly does so: it discloses the shape of each generated kind (label column, colour column t, long table with iv/spot/volume). It never says whether the result is persisted, registered under the `name` parameter, or visible to list_datasets/save_dataset, which is the key side-effect question for a suite where datasets are first-class objects.

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 purpose sentence followed by a compact per-kind list; nearly every clause conveys distinct information. The kind lines are dense but earn their space by differentiating five behaviors.

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?

An output schema exists, so return structure need not be explained, and the kind semantics are well covered. But for a creation tool in a suite with list/save/drop_dataset siblings, the missing explanation of `name` and of whether creation registers or persists anything is a real completeness gap.

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 coverage is 0% across 7 parameters, so the description must compensate. It does explain `kind` values well and ties `k` (clusters) and `d` (dims) to the blobs and swiss_roll kinds, but `n`, `seed`, `noise`, and especially `name` are left undefined, so half the parameters remain opaque.

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?

States a specific verb and resource ('Create a synthetic dataset') and immediately scopes it to demos and sanity checks. The enumerated kinds (blobs, swiss_roll/s_curve, gaussian, lowrank, options_surface) make it unmistakable versus load_dataset or list_datasets, though no sibling is named directly.

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?

Use is implied rather than prescribed: 'for demos and sanity checks' plus per-kind hints ('the null model for the diagnostics', 'for tensorize demos') point at downstream tools without saying when to prefer this over load_dataset. No explicit when-not or alternative routing.

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