AI-ML-Lab-MCP

Overview Schema Source Related Servers Discussions Admin

Train Test Split

train_test_split

Splits a dataset into training and test sets before preprocessing to prevent data leakage, and registers the split for use in encoding, scaling, and model training.

Instructions

Split a dataset into training and test sets and register them as a split. Do this BEFORE encoding, scaling or imputing, then pass the returned split_id to those tools so they are fit on the training data only (no data leakage). The original dataset is not changed. Args: dataset_id (str): ID of the dataset. target_column (str): Name of the target column. test_size (float): Fraction of rows used for testing (0 to 1). Default is 0.2. random_state (int): Seed for a reproducible split. Default is 42. stratify (bool): Keep the target class proportions in both sets (classification). Default is False. shuffle (bool): Shuffle the rows before splitting. Default is True. Returns: dict: split_id, row counts, feature columns and the inferred task.

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": {
      "dataset_id": "<dataset_id>",
      "target_column": "<target_column>"
    },
    "name": "train_test_split"
  }
}

Input Schema

Name	Required	Description	Default
`shuffle`	No
`stratify`	No
`test_size`	No
`dataset_id`	Yes
`random_state`	No
`target_column`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden and does well: it discloses the data-leakage rationale, that the original dataset is unmodified, that a split is registered and addressed by split_id, and roughly what the return dict contains. It omits failure behavior (e.g., a missing target_column) and whether re-splitting overwrites an existing split, which are the remaining behavioral 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?

The workflow constraint and the non-mutation guarantee are front-loaded before the argument list, so the most important context arrives first. The Args/Returns block is clean and scannable, though slightly docstring-flavored where parameter names restate the schema, costing a bit of density.

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 six-parameter mutation-style tool with no annotations and no output schema, the description covers ordering, side effects, and return contents adequately. The residual gaps are error conditions and the lifecycle of the registered split_id, which matter but are secondary for selecting and invoking the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 carry all six parameters, and it does: it documents each one with type, default, and meaning. It adds semantics beyond the raw schema, such as test_size being a fraction in the 0-to-1 range, stratify preserving target class proportions for classification, and random_state controlling reproducibility.

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 description gives a specific verb and resource: split a dataset into training and test sets and register the split. It clearly states the effect ('register them as a split') and what is untouched ('original dataset is not changed'). It does not distinguish itself from the sibling 'split_features_target', leaving an agent to infer which split tool to use, so it falls short of a 5.

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?

It gives strong ordering guidance: run this BEFORE encoding, scaling or imputing, then pass the returned split_id to those tools so they fit on training data only. That tells the agent both when to use it and how it chains to siblings. It stops short of naming a specific alternative tool to use instead or stating when a split is not needed.

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

Deploy Server