Skip to main content
Glama

predict

Apply a saved model to score new data and obtain predictions, with class probabilities and confidence. Works with inline records or CSV files.

Instructions

Score new data with a previously trained model (from train_model).

Provide the rows to score in ONE of two ways:
  * `records`: a list of row dicts, e.g.
    [{"Pclass": 3, "Sex": "male", "Age": 22, "Fare": 7.25, "Embarked": "S"}]
  * `filename`: a CSV inside datasets/ to score every row of (e.g. a Kaggle
    "test.csv").

The saved model is a full pipeline, so missing values and categoricals are
handled automatically; you only need to supply the feature columns used in
training. For classifiers, per-class probabilities and a confidence score
are included.

Args:
    model: Saved model name (see list_models), with or without ".joblib".
    records: Inline rows to score.
    filename: CSV in datasets/ to score instead of `records`.
    id_column: Optional identifier column to echo alongside each prediction
        (e.g. "PassengerId") — handy for building a submission file.
    save_csv: If true, also write the predictions to outputs/ as a CSV.
    top_n: Max number of prediction rows to include in the response.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYes
top_nNo
recordsNo
filenameNo
save_csvNo
id_columnNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations exist, so the description carries full responsibility. It discloses that the model is a full pipeline (automatic missing value/categorical handling), provides per-class probabilities and confidence for classifiers, notes the save_csv side effect (writes to outputs/), and specifies top_n limits the response size. This goes well beyond a bare 'predict' description.

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 well-organized: starts with a one-sentence purpose, then explains input options, pipeline behavior, classifier output, and ends with a concise Args list. Each sentence carries useful information without fluff, and the structure makes it easy to scan.

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?

Given the tool's complexity (6 params, two input paths, side effects), the description covers all essential aspects: how to specify the model, how to provide data inline or via file, what happens with preprocessing, output contents (probabilities/confidence), optional CSV saving, and response limiting. The existence of an output schema reduces the need to describe return values, but the description still mentions extras like confidence scores.

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%, and the description compensates fully by explaining each parameter's purpose and format: model (with/without .joblib), records (list of dicts with example), filename (CSV in datasets/), id_column (echo row IDs), save_csv (write to outputs/), and top_n (max rows). This adds significant meaning beyond the schema.

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 'Score new data with a previously trained model (from train_model)', clearly stating a specific verb, resource, and origin. It distinguishes itself from siblings like list_models and train_model by focusing on the inference step.

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?

It references 'train_model' and 'list_models' to place the tool in the workflow, and explains the two mutually exclusive input methods (records vs filename). However, it does not explicitly state when not to use it or compare it with alternative tools for similar tasks.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bert305/kaggle_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server