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

AI-ML-Lab-MCP

by SyedHassan904
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Suggest Features

suggest_features

Analyzes a dataset or training split and proposes prioritized feature-engineering steps, naming the tool and ready-to-use arguments to fix ID-like, date, skew, outlier, and categorical issues.

Instructions

Inspect a dataset (or the training part of a split) and propose feature-engineering steps. Nothing is changed. Every suggestion names the tool to call and ready-to-use arguments. Checks: constant and ID-like columns, date columns, skewed columns, outlier-heavy columns, categorical columns, and (when the target is numeric or binary) non-linear and interaction effects. Args: dataset_id (str): ID of a dataset or of a split. target_column (str, optional): Needed for target-aware suggestions when dataset_id is a dataset (a split already knows it). max_suggestions (int): Maximum number of suggestions returned. Default is 15. Returns: dict: Suggestions sorted by priority (tool, arguments, reason) plus general notes.

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

Input Schema

NameRequiredDescriptionDefault
dataset_idYes
target_columnNo
max_suggestionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/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 safety burden well: "Nothing is changed" declares read-only behavior, and it enumerates the exact analyses performed (constant/ID columns, dates, skew, outliers, categoricals, non-linear and interaction effects). It also discloses result ordering (by priority) and the general-notes payload; only performance/cost characteristics are unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and the no-side-effects guarantee, then a compact bullet list of checks, then Args/Returns blocks. Every line carries information an agent can act on; there is no filler or repetition of the tool name.

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

Completeness5/5

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

With no output schema, the description still explains the return payload (tool, arguments, reason, sorted by priority, plus general notes). Combined with full parameter documentation and the enumerated checks, an agent has everything needed to decide when to call it and how to read the result.

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 description must compensate and largely does: dataset_id is documented as accepting either a dataset or a split, target_column's conditional necessity is explained (a split already knows its target), and max_suggestions is described as a cap with default 15. Minor gap: no format/validity hints for the string IDs or the target column's type constraints.

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?

"Inspect a dataset (or the training part of a split) and propose feature-engineering steps" gives a specific verb (inspect + propose) and resource (dataset/split), and "Nothing is changed" plus "names the tool to call" distinguishes it from the actionable siblings like scale_features or normalize_features. An agent can tell this is an advisory/planning tool without consulting any sibling 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?

Usage is clearly implied: the tool returns the sibling tool to call with ready-to-use arguments, which frames it as the discovery step ahead of the individual feature tools. It also specifies the condition for target-aware suggestions (target_column needed for a dataset, not a split). It stops short of explicit when-not guidance or naming alternatives to skip.

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