Skip to main content
Glama
tabular-ds-mcp
by YusufErem

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
inspect_competitionA

Start here. Read a competition or project folder and say what kind of problem it is: train / test / sample-submission files, target and ID columns, task, submission format and a likely metric, whether the test rows lie later in time or belong to new groups (customers, stores...), extra tables that need a join, image / text content, and the exact tool calls to make next.

Args: folder: directory holding the competition files (for example /kaggle/input/).

profile_datasetA

Profile a CSV/Parquet table: shape, column types, missing values, cardinality, duplicate rows, target balance and warnings (constant or ID-like columns, possible target leakage, date columns, repeated keys, free-text and file-path columns).

Args: path: file path of the table. target: name of the target column, if the table has one. id_col: name of the ID column, which is excluded from the feature checks. max_rows: profile a random sample of this many rows (default: all rows).

compare_train_testA

Check whether the test set looks like the training set: column and dtype mismatches, unseen categories, PSI and KS per feature, an adversarial-validation AUC (0.5 = indistinguishable), whether the test rows come after the training period, and how many test rows belong to keys never seen in train.

Args: train_path: training table. test_path: test table (no target column needed). target: target column in the training table, excluded from the comparison. id_col: ID column, excluded from the comparison. time_col: time column to check (default: date columns are found automatically). group_col: key column to check, such as customer_id (default: found automatically). max_rows: sample size per table for the heavier checks.

cv_baselineA

Cross-validated gradient-boosting baseline reported next to a no-skill baseline. Encoders are fitted inside each training fold, so the scores are free of preprocessing leakage. With time_col the folds follow time; with group_col no group is split across folds. In both cases the same model is also scored with random folds, and the tool says whether random validation would overstate the score.

Args: train_path: training table. target: target column. id_col: ID column, excluded from the features. task: 'auto', 'binary', 'multiclass' or 'regression'. metric: the competition metric. Binary: roc_auc, pr_auc, log_loss, accuracy, f1, mcc. Multiclass: log_loss, accuracy, macro_f1, roc_auc_ovr, qwk, map@3 (any k). Regression: rmse, rmsle, mae, mape, r2, qwk. Default: roc_auc / log_loss / rmse. time_col: date or time-index column; folds train on the past and score the next time block. group_col: key column (customer, store, patient...); a group never sits in both parts of a fold. n_splits: number of folds. max_rows: train on a random sample of this many rows. oof_path: optional CSV path to save out-of-fold predictions.

explain_modelA

Which features matter? Permutation importance of a gradient-boosting model on a hold-out split (the latest 20% in time with time_col, 20% of the groups with group_col, else a random 20%).

Args: train_path: training table. target: target column. id_col: ID column, excluded from the features. task: 'auto', 'binary', 'multiclass' or 'regression'. time_col: hold out the latest rows by this column. group_col: hold out whole groups of this column. top_k: number of features to return. max_rows: use a random sample of this many rows.

fit_predictA

Fit the baseline model on all training rows and write a submission file in the sample submission's format: one probability or value per row, a label, space-separated top-k labels (MAP@k) or one probability column per class. Run check_submission on the result before uploading.

Args: train_path: training table. test_path: test table. target: target column. id_col: ID column, copied to the submission. out_path: where to write the submission CSV. sample_submission_path: the competition's sample submission (sets the output format). task: 'auto', 'binary', 'multiclass' or 'regression'. metric: the competition metric (rmsle trains on log1p(target); map@k writes k labels). group_col: key column to leave out of the features, as in cv_baseline.

check_submissionA

Check a submission file against the sample submission before uploading it: columns, row count, duplicated or missing IDs, missing values, constant predictions, the [0, 1] range for probabilities, per-row probability sums and the number of labels per row for top-k (MAP@k) submissions.

Args: submission_path: the file to upload. sample_submission_path: the competition's sample submission. test_path: optional test table, to check that every test ID is predicted. id_col: ID column (default: first column of the sample submission).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 7 tools

Disambiguation4/5

The tools cover distinct stages of a tabular ML workflow, and descriptions clarify boundaries. Minor overlap exists between profile_dataset and inspect_competition (both inspect data) and among cv_baseline, explain_model, and fit_predict (all fit models), but each targets a different output.

Naming Consistency4/5

All names are snake_case and mostly follow a verb_noun pattern (profile_dataset, compare_train_test, explain_model, check_submission). cv_baseline is a noun phrase and fit_predict contains two verbs, but the overall style remains consistent and readable.

Tool Count5/5

Seven tools form a tight workflow from competition inspection to submission validation. Every tool has a clear role and none feels redundant or missing for the intended scope.

Completeness4/5

The surface covers inspection, profiling, train/test comparison, cross-validation, model explanation, prediction, and submission validation—the core lifecycle for tabular competitions. Minor gaps remain: no explicit tool for joining extra tables or handling multi-table relations, and no tuning or feature-engineering beyond a baseline.

Maintenance

ActivityMaintained
ResponsivenessNo issues