Skip to main content
Glama

Decision Tree Classifier

decision_tree_classifier

Train a classification tree on a prepared numerical train/test split and return performance metrics, top features, and overfitting warnings.

Instructions

Train a decision tree classifier. Easy to interpret and needs no scaling, but overfits easily when max_depth is not limited. The split must have only numerical, complete features. Args: split_id (str): ID of a split made by train_test_split. criterion (str): Split quality measure: "gini", "entropy" or "log_loss". Default is "gini". max_depth (int, optional): Maximum tree depth. Default is None (unlimited); 3-10 is a common range. 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. class_weight (str, optional): "balanced" 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": "decision_tree_classifier"
  }
}

Input Schema

NameRequiredDescriptionDefault
split_idYes
criterionNogini
max_depthNo
class_weightNo
random_stateNo
min_samples_leafNo
min_samples_splitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does reasonably well: it warns about overfitting when max_depth is unlimited, states a data precondition (numerical, complete features only), and enumerates the returned metrics and warnings. It omits what happens on failure, e.g. whether a categorical split_id raises an error or what warnings are emitted.

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 purpose and the key caveat before the argument list, and each argument line carries concrete information rather than restating the name. No filler sentences.

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?

For a seven-parameter training tool with no output schema, the description covers inputs, data prerequisites, return contents, and the main modeling pitfall. What remains (how split_id is resolved, exact warning text) is minor for correct invocation.

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 coverage is 0%, so the description must compensate, and it largely does: all seven parameters get meaning, type, and defaults, criterion's enum values are spelled out, and a practical max_depth range (3-10) is offered. It does not explain interactions (e.g. min_samples_leaf vs. min_samples_split) or invalid-value behavior, leaving some semantics implicit.

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?

Opens with a specific verb+resource ('Train a decision tree classifier') and adds distinguishing traits (interpretable, no scaling needed, prone to overfitting) that separate it from the tree/boosting siblings. It stops short of explicitly contrasting with decision_tree_regressor or random_forest_classifier, so an agent must infer the choice.

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?

Implies usage context by requiring a split_id produced by train_test_split and by stating the data must be numeric and complete, which effectively tells the agent when this tool is applicable. However, no explicit when-to-use vs. when-not guidance or comparison to alternative classifiers is given.

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