Skip to main content
Glama

Random Forest Regressor

random_forest_regressor

Train a random forest regression model on a prepared train/test split with numerical, complete features to predict numerical targets and return R2, MAE, MSE, RMSE, MAPE, top features, and warnings.

Instructions

Train a random forest regressor: many decorrelated trees averaged together. 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 (float): Fraction of features considered at each split, between 0 and 1. Default is 1.0. random_state (int): Seed. Default is 42. Returns: dict: model_id, train/test metrics (R2, MAE, MSE, RMSE, MAPE), 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_regressor"
  }
}

Input Schema

NameRequiredDescriptionDefault
split_idYes
max_depthNo
max_featuresNo
n_estimatorsNo
random_stateNo
min_samples_leafNo
min_samples_splitNo

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, the description carries the burden and does reasonably well: it discloses preprocessing constraints, default hyperparameters, and that the return includes model_id, train/test metrics, top features, and warnings. It still omits things like expected training cost, whether the model persists for later prediction, and what happens when data violates the numerical/complete requirement.

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?

Front-loaded summary sentence followed by a clean Args/Returns block; nothing is buried. Minor waste comes from restating defaults that already exist in the schema, but the structure is easy to scan.

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 seven-parameter training tool with no output schema and no annotations, the description covers inputs, preconditions, and the exact contents of the returned dict. It could be more complete about model lifecycle (reuse for prediction) and error conditions, but the essentials for a correct call are present.

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 it does document all seven parameters with types and meaning. Beyond restating names, it clarifies semantics such as max_features being a fraction between 0 and 1 and min_samples_split being rows needed to split a node, though several entries mostly repeat schema defaults.

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?

The description gives a specific verb ('Train') and resource ('random forest regressor') and immediately frames it against alternatives with 'A strong default for tabular data'. The 'regressor' framing plus the requirement for numerical, complete features makes it distinguishable from random_forest_classifier and decision_tree_regressor.

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?

'A strong default for tabular data' gives a clear when-to-use signal, and the precondition 'split must have only numerical, complete features (no scaling is needed)' tells the agent what must be true first. No explicit exclusion rules or named alternatives (e.g., use xgboost_regressor when…) are given, so it stops short of a full routing guide.

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