Loading ToolBench
MCP server for data analysis, visualization, and machine learning model training on CSV files
Server has 3 tools with basic descriptions and visible schemas. However, critical gaps exist: (1) Tool naming lacks action verbs, 'describe_column' and 'plot_histogram' are acceptable, but 'model' is dangerously vague (does it train? evaluate? predict?); (2) Parameter descriptions are minimal (10-20 chars) and lack format/constraint guidance; (3) No output schema documentation, return types are inferred from code but not formally declared in docstrings; (4) No error handling guidance beyond basic ValueError checks; (5) No pagination or result limits despite tools handling CSV data of unknown size. The server sits at the lower end of 'Fair' due to these foundational gaps, though schemas ARE present and visible.
Get summary statistics (count, mean, std, min, max, etc.) for a specific column in a CSV file.
Automatically train a model (classification or regression) based on the target column type.
Generate and save a density histogram for a specific column in a CSV file.
Tool 'model' uses a dangerously vague name that does not clearly signal its action. 'model' alone does not tell an LLM whether it trains a model, evaluates one, makes predictions, or loads one. Recommend rename to 'train_model' or 'train_classifier_or_regressor'.
All three tools lack documented output schemas. Tool descriptions include 'Returns dict' or 'Returns str', but do not specify the structure, field names, or types the LLM should expect. For 'describe_column', the dict structure is unclear (is it a Pandas describe() result? What are the exact keys?). For 'model', the dict keys 'model_type', 'metric', 'score' are inferred from code but not documented in the docstring.
Parameter descriptions are minimal and lack format/constraint guidance. 'csv_path' is described as 'The file path to the CSV file' (38 chars), which is technically present but offers no guidance on format, validation, or error handling (e.g., absolute vs. relative paths, permissions, size limits). 'column' is similarly generic. Recommendation: add format hints like 'Must be an absolute path or relative to the current working directory' and 'Column name must exactly match the CSV header'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
No error guidance. Errors like 'Column not found in CSV' are raised but not actionable for the LLM. The error should guide recovery: 'Column "age" not found. Available columns: name, age_years, salary, department. Did you mean "age_years"?' Bare ValueError exceptions tell the agent nothing about next steps.
Tool 'model' lacks documentation of when to use classification vs. regression. The docstring does not explain the auto-detection logic ('is_classification = y.dtype == "object" or len(y.unique()) <= 10'). The LLM cannot predict whether a given y_column will trigger classification or regression without trying. Add explicit guidance: 'Automatically detects classification (target has ≤10 unique values or is non-numeric) vs. regression (continuous numeric target).'
No input validation documented. Parameters like 'bins' default to 10 but have no min/max constraints. An LLM could pass bins=0 or bins=100000, causing failure or excessive memory usage. Add constraints: 'bins must be an integer between 1 and 100. Defaults to 10.'
No pagination or result-limiting logic. 'describe_column' calls df[column].describe(), which returns at most ~8 statistics. However, if the server is later extended to return raw data or histograms, unbounded results could exhaust the context window. Current baseline is low risk, but pattern awareness is missing.