Skip to main content
Glama
Sign In
AI-ML-Lab-MCP

AI-ML-Lab-MCP

by SyedHassan904
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Polynomial Features

polynomial_features

Creates polynomial and interaction features (x², x*y) from numerical columns for model training. Replaces selected columns with the expanded set, keeping originals; impute missing values first.

Instructions

Create polynomial and interaction features (e.g. x^2 and x*y) from numerical columns. The selected columns are replaced by the expanded set, which still contains the originals. Missing values must be imputed first. Args: dataset_id (str): ID of a dataset or of a split. columns (list[str], optional): Numerical columns to expand (max 8). If omitted, all numerical columns. degree (int): Polynomial degree, 2 to 4. Default is 2. interaction_only (bool): Only create interactions between columns (no squares). Default is False. include_bias (bool): Add a constant column of ones named "bias". Default is False. Returns: dict: Columns used and the new feature names.

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

Input Schema

NameRequiredDescriptionDefault
degreeNo
columnsNo
dataset_idYes
include_biasNo
interaction_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/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 disclose real behavior: it mutates the column set in place (expansion replaces the selected columns), enforces a max of 8 columns and a degree of 2–4, and names the generated bias column. Gaps remain for a mutation tool — it does not say whether the original dataset is modified or a new one produced, whether the operation is reversible, or what happens on invalid column names.

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 behavior is front-loaded in the first two sentences, with parameters and return value in a compact docstring block that is easy to scan. The phrasing "replaced by the expanded set, which still contains the originals" is slightly redundant and could be tightened, but nothing is wasted.

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 5-parameter mutation tool with no annotations and no output schema, the description does cover the Returns value and most parameter behavior. It falls short on the two things an agent most needs to know: whether the source dataset is mutated in place (the 'replaced... still contains the originals' wording is actually ambiguous about this) and what failure modes to expect.

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%, yet the description documents all five parameters with types, defaults, and domain constraints (degree 2–4, columns max 8, interaction_only suppresses squares, include_bias adds a column named "bias", dataset_id may be a dataset or a split). Only minor gaps remain, such as column-name validation rules or what a 'split' ID means precisely.

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 polynomial and interaction features") with concrete examples (x^2, x*y) and names the input domain (numerical columns). It does not, however, distinguish itself from the closely related sibling interaction_features, which an agent could reasonably mistake for the same operation given the 'interaction features' phrase appears in both.

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?

It gives one real prerequisite ("Missing values must be imputed first") and explains the default scope (all numerical columns when omitted), which is genuine usage context. It never says when to prefer this over interaction_features or create_feature, nor what to do if no numerical columns exist, so the when-to-use layer is only implied.

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

Deploy Server

Other Tools