tabular-ds-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
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.
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.
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.
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.