AI-ML-Lab-MCP

Overview Schema Source Related Servers Discussions Admin

Random Forest Classifier

random_forest_classifier

Train a random forest classifier on numerical, complete tabular data to produce a model and train/test performance metrics including accuracy, F1, and ROC-AUC.

Instructions

Train a random forest classifier: many decorrelated trees that vote. A strong default for tabular data. The split must have only numerical, complete features (no scaling is needed). Args: split_id (str): ID of a split made by train_test_split. n_estimators (int): Number of trees. Default is 100. max_depth (int, optional): Maximum tree depth. Default is None (unlimited). min_samples_split (int): Minimum rows needed to split a node. Default is 2. min_samples_leaf (int): Minimum rows in a leaf. Default is 1. max_features (str): Features considered per split: "sqrt", "log2" or "all". Default is "sqrt". class_weight (str, optional): "balanced" or "balanced_subsample" to counter imbalanced classes. Default is None. random_state (int): Seed. Default is 42. Returns: dict: model_id, train/test metrics (accuracy, precision, recall, F1, ROC-AUC), top features and warnings.

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": {
      "split_id": "<split_id>"
    },
    "name": "random_forest_classifier"
  }
}

Input Schema

Name	Required	Default
`split_id`	Yes
`max_depth`	No
`class_weight`	No
`max_features`	No	sqrt
`n_estimators`	No
`random_state`	No
`min_samples_leaf`	No
`min_samples_split`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A4/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 substantial work: it discloses the data precondition (fully numerical, no scaling required) and the return payload (model_id, train/test metrics, top features, warnings). It leaves unclear whether the trained model is persisted for later use via model_id and offers no sense of training cost for large n_estimators.

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 purpose and data precondition are front-loaded, then an Args block and a Returns block follow a conventional, scannable structure. It is long but dense with information, with no filler sentences; the only mild redundancy is restating default values that also appear in the schema.

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 an eight-parameter training tool with no annotations and no output schema, the definition covers the essentials: preconditions, every parameter, and the shape of the returned metrics. The remaining gap is the lifecycle after return — what model_id is for and which sibling consumes it — which an agent would need to call it correctly in a pipeline.

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 compensate, and it does: every one of the eight parameters gets a plain-language meaning, its default, and the accepted values for max_features and class_weight (enumerations absent from the schema). It also explains the non-obvious semantics of max_depth=None ("unlimited") and how class_weight counters imbalanced classes.

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 model ("Train a random forest classifier") plus a one-line mental model of the algorithm, and "a strong default for tabular data" implicitly positions it against the other classifiers in the sibling set. It stops short of naming an alternative such as gradient_boosting_classifier or xgboost_classifier, so differentiation is implied rather than explicit.

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 a usable precondition ("the split must have only numerical, complete features") and implies when to pick it (default for tabular data), which is genuine context. However, it never states when NOT to use it or which sibling to choose for categorical features, non-tabular data, or faster baselines, leaving the routing decision to inference.

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

Deploy Server