Skip to main content
Glama
Bert305

Kaggle Dataset Analyst

by Bert305
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Kaggle Dataset Analyst — MCP Server

An MCP server that exposes tools, resources, and prompts for exploratory data analysis (EDA) and machine learning on Kaggle-style CSV datasets. Built with Python, Pandas, scikit-learn, matplotlib, and the MCP Python SDK.

A capstone-level project that touches most of the data skills employers look for: MCP, Python, Pandas, statistics, EDA, scikit-learn, prompt engineering, data visualization, feature engineering, and model evaluation.

What it does

Tools (model-invoked actions)

Tool

Purpose

list_datasets

List CSV files available under datasets/

profile_dataset

Shape, dtypes, summary stats, sample rows

detect_missing_values

Per-column missing counts & percentages

plot_distribution

Save a histogram / bar chart PNG to outputs/

train_model

Train & evaluate a scikit-learn model, save it to models/

list_models

List saved models with their target column and task type

predict

Score new rows with a saved model — supply any feature values, get the predicted target

download_kaggle_dataset

Pull a dataset via kagglehub (needs Kaggle auth)

Resources (read-only context)

  • datasets://list — newline list of available datasets

  • dataset://{filename}/schema — JSON schema (columns, dtypes, missing counts)

Prompts (reusable workflows)

  • eda_walkthrough — a guided EDA plan for a dataset

  • ml_pipeline — an end-to-end modelling plan for a target column

Related MCP server: Vibe Preprocessing and Analysis MCP Server

Project structure

kaggle_mcp/
├── mcp_server.py        # the MCP server (tools, resources, prompts)
├── smoke_test.py        # calls every tool in-process (logic check)
├── client_test.py       # full MCP client <-> server round-trip (protocol check)
├── main.py              # convenience launcher (same as `uv run mcp_server.py`)
├── run_web.ps1          # starts the web app (API + UI) in one command
├── .env.example         # copy to .env and add your Claude key
├── backend/             # FastAPI app — HTTP for the browser, MCP for the server
│   ├── mcp_bridge.py    #   long-lived MCP stdio session
│   ├── agent.py         #   Claude agent loop + Python/SQL codegen
│   └── main.py          #   the HTTP routes
├── frontend/            # React + Vite + Recharts UI
│   └── src/
│       ├── charts.tsx   #   chart forms (sequential bars, diverging heatmap)
│       ├── exporting.ts #   CSV / JPEG / clipboard export
│       ├── api.ts       #   typed client, incl. SSE reader
│       └── panels/      #   Overview · Explore · Model · Ask · Generate code
├── datasets/            # CSVs — the web app uploads here; every tool reads here
│   └── train.csv        # Titanic dataset (891 rows)
├── models/              # saved trained models (.joblib)
├── outputs/             # generated plots (.png)
├── prompts/             # (room for saved prompt templates)
├── pyproject.toml
└── README.md

Setup

# from the kaggle_mcp/ directory
uv sync          # installs dependencies into .venv

Mental model. The server never runs on its own — it speaks the MCP protocol over stdio and waits for a client to drive it. There are two ways to be that client:

  • Level 1 — MCP Inspector: a web UI where you click tools by hand. Best for learning and debugging the server.

  • Level 2 — Claude (Desktop or Code): the AI is the client and calls the tools for you from a normal chat. This is the real, day-to-day way to use it.

  • Level 3 — the bundled React app: a FastAPI backend is the MCP client, and the browser talks to that backend over HTTP. Point-and-click charts and ML, plus a Claude-powered "ask anything" tab.

Get comfortable in the Inspector first, then graduate to Claude.

Level 1 — Drive the server with the MCP Inspector

The Inspector is a browser UI that connects to your server and lets you invoke each tool by hand.

One-time prerequisites (already installed if you ran uv sync):

  • The cli extra of the MCP SDK — uv add "mcp[cli]" (provides the mcp dev command). It is declared in pyproject.toml, so uv sync installs it.

  • Node.js — the Inspector UI is a Node app launched via npx.

Tool Inspection to verify the tools are connected and work:

uv run mcp dev mcp_server.py

It prints a token-prefilled URL like http://localhost:6274/?MCP_PROXY_AUTH_TOKEN=.... Open that link (use the one with the token — the Inspector requires it). The first launch may pause while npx downloads the Inspector. A green ● Connected dot means you're live. Press Ctrl+C in the terminal to stop.

Workflow — run a tool:

  1. Click the Tools tab → List Tools (you should see all 10 tools).

  2. Click a tool, e.g. profile_dataset.

  3. Fill in its arguments — for profile_dataset, set filename = train.csv.

  4. Click Run Tool. The JSON result appears on the right.

A good first session (Titanic):

Step

Tool

Arguments

What you learn

1

list_datasets

—

confirms train.csv is visible

2

profile_dataset

filename=train.csv

shape, dtypes, sample rows

3

detect_missing_values

filename=train.csv

Cabin 77%, Age 20% missing

4

plot_distribution

filename=train.csv, column=Age

writes a PNG to outputs/

5

train_model

filename=train.csv, target=Survived

~0.82 accuracy + top features

6

list_models

—

confirms the model was saved

7

predict

model=train_Survived_classification, records=[{"Pclass":1,"Sex":"female","Age":38,"Fare":71.3,"Embarked":"C"}]

predicted Survived + confidence

train_model actually fits a RandomForest — give it a few seconds.

Other tabs:

  • Resources → List Resources shows datasets://list; resource templates like dataset://{filename}/schema are filled in with a filename.

  • Prompts are reusable instruction templates — clicking Get Prompt returns text (e.g. eda_walkthrough) meant to be handed to an AI. They don't execute anything themselves; the real work is in Tools.

The red "Error output from MCP server" panel is not errors — the Inspector labels everything the server prints to stderr that way. Lines like INFO Processing request of type ... are normal activity logs.

Level 2 — Use the server through Claude (real usage)

Here Claude is the client: you chat normally and it decides which tools to call.

Claude Code (CLI)

On bash / macOS / Linux:

claude mcp add kaggle-analyst -- uv --directory c:/dev/kaggle_mcp_project/kaggle_mcp run mcp_server.py

On Windows PowerShell, use add-json instead. PowerShell mangles the -- separator and eats the unquoted backslash path, which silently registers the server with an empty args list — it then fails to start:

claude mcp add-json kaggle-analyst '{"command":"uv","args":["--directory","c:\\dev\\kaggle_mcp_project\\kaggle_mcp","run","mcp_server.py"]}'

Verify with /mcp in a Claude Code session, or claude mcp get kaggle-analyst — args must be non-empty.

Claude Desktop

Add this to your claude_desktop_config.json (Settings → Developer → Edit Config), then restart Claude Desktop:

{
  "mcpServers": {
    "kaggle-analyst": {
      "command": "uv",
      "args": [
        "--directory",
        "c:\\dev\\kaggle_mcp_project\\kaggle_mcp",
        "run",
        "mcp_server.py"
      ]
    }
  }
}

Config file location on Windows depends on which build you installed:

  • Microsoft Store build: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json

  • Standalone installer: %APPDATA%\Claude\claude_desktop_config.json

Settings → Developer → Edit Config opens the right one either way.

Then just ask

"Profile train.csv, tell me which columns have missing data, then train a model to predict Survived and report the most important features."

Claude will call profile_dataset → detect_missing_values → train_model on its own and summarize the results — the same tools you clicked in the Inspector, now driven by the AI.

Level 3 — The React web app

A browser cannot speak MCP: the transport is stdio, which needs a spawned child process and a pipe. So a FastAPI backend plays the role Claude Desktop plays — it launches mcp_server.py once, speaks real MCP over stdio, and exposes the results over HTTP:

React (browser) ──HTTP/SSE──▶ FastAPI ──MCP stdio──▶ mcp_server.py
                                  └──────────────────▶ Claude API

Run it:

.\run_web.ps1          # installs frontend deps on first run, starts both

Then open http://localhost:5173. Or start the halves yourself:

uv run uvicorn backend.main:app --reload --port 8000   # terminal 1
cd frontend; npm run dev                               # terminal 2

The API key

Only the Ask Claude and Generate code tabs need a Claude key. Datasets, charts, model training and prediction all work without one.

Two ways to supply it — either works, and a shell variable wins over the file so an exported key is never silently shadowed by a stale .env:

# 1. A .env file (gitignored). Put it in kaggle_mcp/ — the project root, NOT
#    backend/, though backend/.env is also read as a fallback.
cp .env.example .env      # then edit in your key

# 2. Or an environment variable
$env:ANTHROPIC_API_KEY = "sk-ant-..."                                            # this shell
[Environment]::SetEnvironmentVariable("ANTHROPIC_API_KEY","sk-ant-...","User")   # persistent

The backend resolves .env against the project root rather than the current directory, so it loads no matter where you launch uvicorn from. Restart the backend after changing the key — it is read once when the client is built.

Check what actually resolved without printing the secret:

curl http://127.0.0.1:8000/api/health     # -> "claude_key_loaded": true

What the tabs do

Tab

What it does

Path

Overview

Row/column/gap tiles, missing-data chart, schema, sample rows

profile_dataset, detect_missing_values

Model

Train a model, read its metrics and drivers, score a new record

train_model, list_models, predict

Ask Claude

Free-text question → Claude picks tools, runs them, charts every real result, then writes the findings

any tool, chosen by the model

Generate code

Written against this dataset's real schema: a pandas script (EDA + analysis + charts saved to outputs/), a portable ANSI SQL query against a table named after the CSV, or an end-to-end scikit-learn script

Claude + profile_dataset

Ask Claude is the main analysis surface, and it visualises in two ways.

Tool cards — each call becomes its own card with the real payload charted: shape tiles and a quantile line for profile_dataset, a ranked bar for detect_missing_values, the saved PNG inline for plot_distribution, metric tiles plus feature importance for train_model.

Charts Claude draws itself — it can place a chart anywhere in its write-up by emitting a fenced ```chart block, which renders in place, beside the claim it supports:

```chart
{"chart":"pie","title":"Survival by class","insight":"3rd class carried the losses.",
 "series":[{"name":"passengers","points":[{"x":"1st","y":216},{"x":"3rd","y":491}]}]}
```

chart

For

bar / column

magnitude across named categories

line / area

change across an ordered scale

pie / donut

parts of one whole (capped at 6 slices, tail folded into "Other")

scatter

relationship between two numeric measures

stat

two to four headline numbers

Taking the analysis out of the app

Nothing is trapped in the browser. Every result carries its own export control, and the Ask tab has a bar that takes the whole session at once.

Control

Where

What you get

CSV / Copy

under any View as table

that one table as a .csv, or as a markdown table on the clipboard

JPEG / Copy

above any chart

that chart as a titled .jpg, or as an image on the clipboard

Data (CSV)

Ask tab, above the results

every table in the session in one .csv, each under a # section line

Charts (JPEG)

Ask tab

every chart in the session, one .jpg each

Copy all

Ask tab

question + tool results + findings as one markdown document

The CSVs open cleanly in Excel: they carry a UTF-8 BOM, and a cell starting = or @ is prefixed so a spreadsheet can never execute exported text (a plain negative number is left alone).

Two details make the image export work. Chart colours are CSS custom properties (fill="var(--seq-450)"), and a serialized SVG renders in an isolated document where those variables do not exist — so every paint property is resolved onto a detached clone before rasterizing, or the chart would come out black. And Recharts draws the legend as HTML outside the SVG, so it is read back out of the DOM and redrawn onto the canvas under the chart. See frontend/src/exporting.ts.

Specs are parsed defensively — a malformed one degrades to a code block rather than breaking the answer — and the model is instructed never to plot a number it did not get from a tool. The prose itself is rendered markdown (headings, tables, bold, inline code) by a small dependency-free renderer that builds React elements, so model output can never inject markup.

Uploads land in datasets/, so a CSV you drop in the sidebar is immediately visible to Claude Desktop and the Inspector too — one dataset directory, three front doors.

Notes on the implementation

  • Charts are data, not images. The backend returns JSON and React renders it with Recharts, so charts are hoverable and theme-aware. The existing matplotlib plot_distribution tool still works for report-ready PNGs.

  • Chart form is chosen by the data's job, not by taste: magnitude → bar, shape across an ordered scale → line, each in a single-hue sequential ramp. (Part-to-whole is deliberately not a pie chart — pies misread at a glance, so a stacked bar is the substitute if one is ever needed.) The palette was checked with a colour-vision-deficiency validator, and every chart ships a table view, so meaning never rides on colour alone.

  • Two path guards. The upload route rejects anything that is not a plain .csv name, and mcp_server.py independently refuses paths outside datasets/.

  • The agent loop is the SDK's tool runner with the MCP tools converted via anthropic.lib.tools.mcp, so Claude calls the same tools the buttons call. Progress streams to the browser as Server-Sent Events.

Making predictions with a trained model

Once train_model has saved a model, the predict tool scores new rows — you supply whatever feature values you want and it returns the predicted target (plus a confidence for classifiers). The saved model is a full pipeline, so it handles missing values and categorical columns for you; you only provide the feature columns used in training.

Two input modes:

  • Ad-hoc rows — pass records, a list of feature dicts you make up:

    predict(
  model="train_Survived_classification",
  records=[{"Pclass": 1, "Sex": "female", "Age": 38, "Fare": 71.3, "Embarked": "C"}]
)
# -> {"Survived": 1, "confidence": 1.0}

  • A whole CSV (e.g. a Kaggle test.csv) — pass filename, optionally echo an id column and write a submission CSV:

    predict(
  model="train_Survived_classification",
  filename="test.csv",
  id_column="PassengerId",
  save_csv=True   # writes outputs/<model>_predictions.csv
)

In Claude, just describe the case — it fills in the records for you:

"Predict survival for a 28-year-old man in 3rd class who paid £8 and boarded at Southampton."

Use list_models to see which saved models are available and what each predicts.

Automated checks (no UI)

Two scripts verify the server without the Inspector — handy for a quick sanity check or CI:

uv run python smoke_test.py     # calls every tool in-process (logic check)
uv run python client_test.py    # full MCP client <-> server round-trip (protocol check)

client_test.py exercises the exact stdio path a real client uses, so prefer it when confirming the server actually works end-to-end.

Using your own Kaggle data

  1. Drop any .csv into datasets/, or

  2. Configure Kaggle credentials (KAGGLE_USERNAME / KAGGLE_KEY, or ~/.kaggle/kaggle.json) and call the download_kaggle_dataset tool with a slug like yasserh/titanic-dataset.

Every tool takes a filename argument, so the server works with any dataset you add — not just Titanic.

Troubleshooting

Invalid JSON / EOF while parsing after running uv run mcp_server.py. Expected. The server is waiting for MCP protocol messages on stdin; anything you type by hand is rejected as malformed. Press Ctrl+C and use client_test.py or an MCP client instead.

Error: typer is required. Install with 'pip install mcp[cli]' from uv run mcp dev. The MCP SDK was installed without its cli extra. Fix:

uv add "mcp[cli]"

(You do not need to activate .venv — uv run/uv add already use it.)

Failed to spawn mcp / os error 4551 from uv run mcp dev. Windows Smart App Control is blocking the unsigned mcp.exe helper. The mcp dev Inspector is optional. Use uv run python client_test.py to verify the server without it, or disable Smart App Control (Settings → Privacy & security → Windows Security → App & browser control → Smart App Control).

The Inspector's red "Error output from MCP server" panel is full of lines. Not an error — the Inspector shows everything the server logs to stderr there. INFO Processing request of type ... lines are normal.

Implementation notes

  • Heavy imports are at module scope, not lazy. FastMCP runs synchronous tool functions in a worker thread, and a first-time import sklearn from a non-main thread can deadlock on CPython's import lock on Windows. So scikit-learn / joblib / kagglehub are imported once at startup on the main thread. (A purely in-process test like smoke_test.py won't catch this — only the real stdio path in client_test.py does.)

  • train_model uses n_jobs=1. As a stdio server this process has its stdin/stdout redirected to pipes; parallel joblib/loky workers would inherit those handles and can deadlock on Windows. RandomForest on tutorial-sized data is fast enough single-threaded.

  • Path-traversal guard. Every dataset access is resolved safely inside datasets/, so a filename like ../../secret.csv is refused.

Available Tools

8 tools
detect_missing_valuesA

Report missing-value counts and percentages per column, sorted by the most-missing first.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It does explain the output behavior (counts, percentages, sorting by most-missing), which is useful. However, it does not disclose any side effects, limitations, or assumptions (e.g., whether all columns are included, handling of empty files), leaving some behavioral aspects unexplored.

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 a single, concise sentence that starts with the action verb 'Report' and includes the key details (counts, percentages, sorting). Every word earns its place, and there is no fluff or redundancy.

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?

For a simple one-parameter tool with an output schema, the description provides sufficient information about what it does and what it returns. It is reasonably complete despite the lack of parameter explanation, because the parameter is self-evident from the context. Slightly higher than mid-tier because the output behavior is clearly specified.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one required parameter 'filename' with 0% description coverage, and the tool description does not mention it at all. While the parameter's purpose is inferable from the tool name, the description does not add any extra meaning, such as accepted file formats or how the filename is used, which is a gap given the low schema coverage.

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 clearly states the tool's purpose: 'Report missing-value counts and percentages per column, sorted by the most-missing first.' This is a specific verb ('report') with a clear resource (missing-value stats per column) and unique sorting behavior, distinguishing it from sibling tools like profile_dataset or plot_distribution.

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?

The description implies when to use the tool (when you need missing-value insights per column) but does not explicitly mention when not to use it or suggest alternatives. There is no comparison to sibling tools, so usage guidance is inferred rather than explicit.

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

download_kaggle_datasetA

Download a dataset from Kaggle via kagglehub and copy any CSVs into datasets/.

Requires Kaggle authentication (KAGGLE_USERNAME / KAGGLE_KEY env vars or
~/.kaggle/kaggle.json). Example dataset slug: "yasserh/titanic-dataset".
ParametersJSON Schema
NameRequiredDescriptionDefault
datasetYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/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 disclose key behavioral traits: use of kagglehub, copying CSVs into datasets/, and authentication requirements. It does not mention overwrite behavior or error handling, but the main side effects are clearly stated.

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 two concise sentences, front-loading the main action and then adding necessary prerequisites and an example. Every sentence serves a purpose with no fluff.

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 simplicity (one parameter) and the presence of an output schema, the description covers everything essential: purpose, side effect, authentication, and input format. Minor details like non-CSV handling are implicit in the phrase 'copy any CSVs', so no critical gaps remain.

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?

The input schema has no descriptions for the single 'dataset' parameter, so the description compensates by providing an example slug ('yasserh/titanic-dataset'), which clarifies the expected format. This gives meaningful guidance beyond the schema's bare parameter name.

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 clearly states the tool downloads a dataset from Kaggle via kagglehub and copies CSVs into datasets/, using a specific verb and resource. It implicitly distinguishes from siblings like list_datasets and profile_dataset by focusing on the actual download and file-copy action.

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 provides clear context that Kaggle authentication is required and gives an example dataset slug format, helping the agent understand prerequisites and input format. However, it does not explicitly mention when to use this tool versus alternatives, though the purpose is obvious.

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

list_datasetsA

List the CSV datasets available under the datasets/ directory.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of explaining behavior. It discloses the location and file type (CSV under datasets/) but does not mention whether listing is recursive, how results are ordered, or error behavior. The presence of an output schema mitigates the lack of return-value details, but other behavioral aspects remain undisclosed.

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 a single, efficient sentence that front-loads the action. Every word contributes meaning, with no redundancy or filler.

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?

For a simple zero-parameter tool with an output schema, the description is largely complete. It specifies the source directory and file type. It could add a note about when to use it (e.g., before profiling), but that gap is more relevant to usage guidelines.

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?

There are zero parameters, so the schema coverage is vacuously 100%. The description adds nothing beyond the schema, but the baseline for zero-parameter tools is 4, and no additional parameter semantics are needed.

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 clearly states the action ('List') and the precise resource ('CSV datasets available under the datasets/ directory'). It distinguishes itself from sibling tools like list_models and download_kaggle_dataset by focusing on local datasets.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool or how it relates to alternatives. The description only states what it does, leaving the agent to infer that it is a preliminary step before other dataset operations.

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

list_modelsA

List the trained models saved under models/, with the target column and task type each one predicts.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are present, so the description carries the full burden. The verb 'List' indicates a read-only operation, and 'saved under models/' gives behavioral context about the data source. It also discloses that the output includes target column and task type, but does not explicitly mention side-effect-free behavior or error cases.

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 a single, front-loaded sentence that conveys all necessary information without redundancy. Every word earns its place.

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 parameterless listing tool with an output schema, the description is sufficient. It states the action, the resource location, and the specific fields returned, leaving no significant gaps for the agent to resolve.

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?

The input schema has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning (none needed) and correctly focuses on what the tool returns.

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 uses the specific verb 'List' with the resource 'trained models' and provides clear scope ('saved under models/') and output content ('target column and task type'). This clearly differentiates it from sibling tools like list_datasets, which lists datasets.

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?

The description implies usage for viewing existing trained models before prediction or training, but does not explicitly state when to use it or mention alternatives. The contrast with list_datasets is clear from the name alone but not articulated in the description.

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

plot_distributionA

Render a distribution chart for a column and save it as a PNG in outputs/. Numeric columns get a histogram; categorical columns get a bar chart. Returns the saved file path.

ParametersJSON Schema
NameRequiredDescriptionDefault
binsNo
columnYes
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/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 a good job: it discloses the side effect of saving a PNG to outputs/, conditional behavior for numeric vs categorical columns, and the return of the saved file path. It could add overwrite behavior or failure modes, but the main behavioral traits are covered.

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 three sentences, each earning its place: purpose, behavior, and return value. It is front-loaded with the primary action and contains no fluff or repetition.

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?

Given the tool's simplicity and the existence of an output schema, the description covers the main functionality, side effects, and return value well. However, the lack of explanation for the 'bins' parameter and the ambiguity around the 'filename' parameter slightly reduce completeness. Overall, it is adequate for typical use cases.

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

Parameters2/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 implicitly defines 'column' (the target column) but does not mention 'bins' at all, and 'filename' is only implied via 'save it as a PNG in outputs/'. The description fails to explain the meaning of two of three parameters, which is a significant gap.

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 uses a specific verb ('Render') and resource ('distribution chart for a column'), and clearly distinguishes itself from siblings by focusing on single-column distribution visualization. It also states the output (PNG in outputs/) and the return value (file path), leaving no ambiguity about what the 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 Guidelines4/5

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

The description clearly implies usage: plotting a column's distribution. However, it does not explicitly mention alternatives or state when NOT to use this tool versus siblings like profile_dataset. The context is clear enough to differentiate, but lacks explicit exclusions.

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

predictA

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.
ParametersJSON Schema
NameRequiredDescriptionDefault
modelYes
top_nNo
recordsNo
filenameNo
save_csvNo
id_columnNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
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.

profile_datasetA

Profile a dataset: shape, column dtypes, numeric summary stats, and a sample of rows.

Args:
    filename: CSV file inside datasets/ (e.g. "train.csv").
    sample_rows: How many head rows to include in the preview.
ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
sample_rowsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the transparency burden. It explicitly specifies the outputs (shape, dtypes, numeric stats, sample rows) and the constraint that filename must be a CSV inside datasets/, which adds meaningful behavioral context. However, it does not mention side effects (e.g., read-only behavior) or error handling, leaving some aspects implicit.

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 concise and front-loaded with the main action, followed by a minimal Args block. Every sentence adds value—there is no fluff or repetition of schema fields, making it an efficiently structured docstring.

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 simple profiling tool, the description covers purpose, parameters, and output details. The presence of an output schema handles return structure, and the description adds the necessary file-location constraint. This is complete enough for an agent to select and invoke the tool correctly.

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?

Both parameters are explained in the Args section with more context than the schema: filename specifies a CSV inside datasets/ with an example, and sample_rows specifies how many head rows to include. Since schema descriptions are absent (0% coverage), the description fully compensates by providing essential 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 'Profile a dataset' and enumerates exactly what profiling includes: shape, dtypes, numeric stats, and row sample. This clearly distinguishes it from sibling tools like list_datasets (which lists datasets) or plot_distribution (which visualizes), making the tool's purpose unmistakable.

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?

No explicit usage context is provided—the description doesn't say when to choose profiling over detect_missing_values or list_datasets. The purpose implies initial data exploration, but there is no when/when-not guidance or named alternatives, leaving the usage scenario to be inferred.

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

train_modelA

Train a baseline scikit-learn model, evaluate it on a held-out split, and persist it to models/.

Categorical features are one-hot encoded and numeric features are imputed +
scaled inside a single sklearn Pipeline, so it works on raw Kaggle CSVs.

Args:
    filename: CSV file inside datasets/.
    target: Column to predict.
    features: Columns to use as predictors. Defaults to all other columns.
    task: "classification", "regression", or "auto" (inferred from target).
    test_size: Fraction held out for evaluation.
    random_state: Reproducibility seed.
ParametersJSON Schema
NameRequiredDescriptionDefault
taskNoauto
targetYes
featuresNo
filenameYes
test_sizeNo
random_stateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full transparency burden. It discloses key behaviors: one-hot encoding, imputation, scaling within a Pipeline, and persistence to models/. It also explains task inference for the 'auto' value. Missing details like overwrite behavior are not stated, but the core side effects and preprocessing are well covered.

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 main purpose, followed by a compact preprocessing note and a clear Args list. Every sentence adds value, and the Args section is necessary given the empty schema descriptions. No fluff or redundancy.

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?

The tool is a moderately complex training operation with 6 parameters, but the description covers all of them and explains the preprocessing steps. Since an output schema exists, the absence of return-value details is acceptable. The description provides a complete picture for selecting and invoking the tool correctly.

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%, but the description's Args section explains every parameter: filename, target, features, task, test_size, random_state. This fully compensates for the lack of schema descriptions and provides meaning well beyond parameter names/types.

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?

Description opens with 'Train a baseline scikit-learn model, evaluate it on a held-out split, and persist it to models/' which clearly identifies the action, resource, and outcome. It is fully distinguished from sibling tools like predict, list_models, profile_dataset, etc., which cover other stages of the ML workflow.

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?

The description gives clear context of what the tool does and states it 'works on raw Kaggle CSVs', implying it is suitable for end-to-end training from raw data. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to know when to invoke it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updatesv0.1.0
    • First observeddetect_missing_values
    • First observeddownload_kaggle_dataset
    • First observedlist_datasets
    • First observedlist_models
    • First observedplot_distribution
    • First observedpredict
    • First observedprofile_dataset
    • First observedtrain_model
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

Each tool targets a distinct action: listing datasets, profiling, missing values, plotting, training, listing models, predicting, and downloading. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_datasets, train_model). The single exception is 'predict' (verb only), but it remains stylistically consistent.

Tool Count5/5

With 8 tools, the set is well-scoped for a Kaggle analyst workflow. Each tool earns its place, covering data acquisition, exploration, model training, and prediction without unnecessary bloat.

Completeness4/5

The toolset covers the full lifecycle from downloading to profiling to modeling to predicting. Minor gaps exist, such as no explicit data cleaning tool (though train_model's pipeline handles imputation/encoding) and no model deletion, but these are not critical for the intended purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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