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

AI-ML-Lab-MCP

by SyedHassan904
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Create Feature

create_feature

Create a new dataset column by evaluating a row-wise arithmetic expression over existing columns, optionally on a split to prevent target leakage. Supports math functions and overwrite behavior.

Instructions

Create a new column from a row-wise arithmetic expression over existing columns. Examples: "selling_price / km_driven", "log(km_driven + 1)", "(year - 2000) * 2", "engine cc * power". Use backticks around column names that contain spaces. Available functions: log, log10, log1p, sqrt, exp, abs, sin, cos, tanh, floor, ceil. Method calls (x.mean()) and assignments are rejected because they would compute statistics per split and leak test data. Recommended: pass a split_id so the target column cannot be used in the expression by accident. Args: dataset_id (str): ID of a dataset or of a split. name (str): Name of the new column. expression (str): The expression to evaluate for every row. overwrite (bool): Replace the column if the name already exists. Default is False. Returns: dict: The new column, its dtype, missing count and a short preview.

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

Input Schema

NameRequiredDescriptionDefault
nameYes
overwriteNo
dataset_idYes
expressionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does most of it: it discloses the restricted grammar, the mutating nature of the operation (a new column is added), the overwrite default of False, and the shape of the response. The leakage rationale for rejected syntax is genuinely useful context an agent could not infer. What it omits is whether the change persists in place on the dataset or is return-only.

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 core statement is front-loaded, and the example expressions and function list earn their space because expression syntax is the main failure mode for this tool. The Args/Returns block mirrors the schema rather than adding much, but overall the prose stays tight with no filler.

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 four-parameter mutation tool with no annotations and no output schema, the definition covers accepted syntax, rejection rules, the overwrite default, and even a summary of the return value. The only genuine gap is the phantom split_id reference, which leaves the agent guessing how split scoping is actually expressed.

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 Args block is the only source of parameter meaning, and it covers all four: dataset_id may be a dataset or a split, name is the new column name, expression is the per-row arithmetic, overwrite replaces an existing column and defaults to False. The weakness is the stray "pass a split_id" recommendation for a parameter that does not exist in the schema, which makes the dataset_id/split distinction ambiguous.

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?

"Create a new column from a row-wise arithmetic expression over existing columns" gives a specific verb (create), a specific resource (column), and the mechanism (row-wise expression). This is enough to separate it from siblings like bin_feature or transform_feature without opening either schema.

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?

The description states what expressions are accepted, gives four concrete syntax examples, enumerates the allowed function set, and explicitly rejects method calls and assignments with the reason (per-split statistics would leak test data). It also recommends passing a split_id. It never names a sibling tool as the alternative for the other feature-engineering paths, so it stops short of full when-to-use routing.

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