Skip to main content
Glama

train

Generate a predictive pricing model from your local CSV with automatic leakage prevention and log-target recommendation. Runs locally, keeps data on your machine.

Instructions

Train a new P2Predict model from a local CSV file.

Prefer calling `propose_training_plan` first and confirming with the user
— this tool is the execution step. The CSV must have spec columns and a
price/cost target column. Training runs locally; no data leaves the
machine. The trained model is saved and immediately available.

Safe defaults (always surfaced in the returned `warnings` list):
  - When features are auto-selected (features=None), columns that look
    like target leakage — a near-duplicate of the price being predicted —
    are excluded automatically.
  - For a strictly-positive (price/cost) target where the automatic skew
    test leaves the log-target off, the result recommends log_target="on".

algorithm: "auto" (default), "ridge", "random_forest", or "xgboost".
budget: "fast" (default) or "thorough".
log_target: "auto" (default), "on", or "off". Use "on" for prices.
allow_leaky_features: set True only to override the leakage guard and
    train on an explicitly-requested feature that looks like leakage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
budgetNofast
targetYes
csv_pathYes
featuresNo
algorithmNoauto
log_targetNoauto
max_featuresNo
outlier_policyNowarn
allow_leaky_featuresNo
feature_outlier_policyNowarn

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses that training runs locally, that no data leaves the machine, that the trained model is saved and immediately available, and that safety defaults like leakage exclusion and log-target recommendation are surfaced in warnings.

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?

The description is front-loaded with the core action, then moves through workflow, constraints, behavioral defaults, and parameter values in a logically organized way. The bulleted safe-defaults section makes the leakage and log-target behavior easy to parse without excessive length.

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?

An output schema exists, so return values need not be repeated in the description. The description covers workflow, prerequisites, privacy, persistence, safety defaults, and several key parameters, but a few policy parameters such as outlier_policy and feature_outlier_policy still lack explicit semantics, leaving a minor gap for a 10-parameter training tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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. It does document algorithm, budget, log_target, and allow_leaky_features with concrete values and guidance, but it leaves max_features, outlier_policy, feature_outlier_policy, csv_path, and target mostly to be inferred from their names rather than explained.

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 opens with a specific verb and resource: 'Train a new P2Predict model from a local CSV file.' It also differentiates this tool from its sibling by positioning it as the execution step after propose_training_plan, so an agent can clearly tell what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to prefer calling propose_training_plan first and to confirm with the user before using this execution tool. It also states the required CSV shape and the privacy property that training runs locally, giving the agent concrete guidance on when this tool is appropriate.

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