Skip to main content
Glama
Axiomatic-AI

axiomatic-mcp

Official
by Axiomatic-AI

AxModelFitterLegacy_cross_validate_model

Cross-validate a model to assess generalization and detect overfitting using kfold, shuffle, or custom train/test splits.

Instructions

LEGACY TOOL (AxModelFitterLegacy, formerly AxModelFitter): existing workflows built on this toolset should continue to use it — it is the unchanged continuation of the original AxModelFitter tools. For NEW workflows, prefer the new AxModelFitter server's generate_code/execute_code tools (console script axiomatic-modelfitter). This legacy toolset will be removed in the next major release.

Test how well your model generalizes to new data using cross-validation.

REQUIRED INPUTS (same as fit_model):
- All model parameters: function_source, parameters, bounds, etc.
- data_file: Path to your data file
- input_data: Maps file columns to input variables
- output_data: Maps file columns to output variables

VALIDATION TYPES:
- 'kfold': Split data into equal parts (good default)
- 'shuffle': Random train/test splits
- 'custom': Specify your own train/test indices

TYPICAL USAGE:
1. Use same parameters as your fit_model call
2. Set validation_strategy='kfold' and n_splits=5
3. Check if test R² values are consistent across folds

INTERPRETATION:
- Consistent high R² across folds: Good generalization
- Large R² variation: Model may be overfitting
- Low average R²: Model not capturing data patterns well

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
boundsYesParameter/input/output bounds
max_timeNoMaximum optimization time in seconds per fold
n_splitsNoNumber of validation folds (for kfold and shuffle)
constantsNoFixed constants
data_fileYesPath to data file (CSV, Excel, JSON, Parquet). All data must be provided via file.
test_sizeNoTest set proportion (for shuffle split)
input_dataYesInput column mappings: [{'column': 'time', 'name': 't', 'unit': 'second'}, {'column': 'x_col', 'name': 'x', 'unit': 'meter'}]
model_nameYesModel name for identification
file_formatNoFile format: 'csv', 'excel', 'json', 'parquet' (auto-detect if None)
jit_compileNoEnable JIT compilation
output_dataYesOutput column mapping: {'columns': ['signal'], 'name': 'y', 'unit': 'volt'} OR {'columns': ['y1', 'y2'], 'name': 'y', 'unit': 'volt'}
random_stateNoRandom seed for reproducibility
custom_splitsNoCustom train/test splits: [{'train': [0,1,2], 'test': [3,4]}, ...]
function_nameYesFunction name that computes the model output
optimizer_typeNoOptimizer: 'nlopt' (best default), 'scipy' (simple), 'nevergrad' (gradient-free)nlopt
function_sourceYesJAX function source code using jnp operations
optimizer_configNoOptimizer config: {'use_gradient': True, 'tol': 1e-6, 'max_function_eval': 1000000}
cost_function_typeNoCost function: 'mse', 'mae', 'huber', 'relative_mse'mse
initial_parametersYesInitial parameter guesses for optimization on each fold
validation_strategyNoValidation type: 'kfold', 'shuffle', or 'custom'kfold

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.20

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It transparently discloses the legacy status and imminent removal, describes the three validation strategies, and explains how to interpret results (R² consistency for overfitting, low average R² for poor fit). It doesn't discuss side effects or state mutations, but for a cross-validation test tool this is less critical—the description covers the core behavior well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear section headers (LEGACY TOOL, REQUIRED INPUTS, VALIDATION TYPES, TYPICAL USAGE, INTERPRETATION). The most critical warning (legacy status) is front-loaded cars. Each section earns its place—even the legacy notice is actionable information for tool selection. It's slightly verbose but not padded, and the structure aids readability for an agent.

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 complexity (20 parameters, 8 required, no output schema), the description is reasonably complete. It explains the overall workflow (use same params as fit_model, choose validation strategy, interpret R²), and it implicitly conveys the return type by mentioning 'test R² values across folds.' Details like custom_splits structure and optimizer_config are left to the schema, which is acceptable given 100% schema coverage. Minor gaps: it doesn't explicitly state what the tool returns, but this is inferred.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful usage context beyond the schema: it groups required inputs into a conceptual set ('All model parameters... data_file, input_data, output_data'), explains validation_strategy options in plain language, and provides typical values (n_splits=5, 'kfold' as a good default). This practical guidance helps choose and configure parameters correctly, earning a 4.

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 a clear, specific verb phrase: 'Test how well your model generalizes to new data using cross-validation.' This directly states the tool's purpose and differentiates it from siblings like fit_model (which fits) and calculate_r_squared (which measures fit quality). The legacy warning further distinguishes it from the new AxModelFitter server tools, reducing ambiguity.

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 provides explicit usage guidance: a REQUIRED INPUTS section (same as fit_model), a VALIDATION TYPES section explaining available strategies, and a TYPICAL USAGE section with concrete steps (e.g., set validation_strategy='kfold' and n_splits=5). It clearly implies when to use this tool (to assess generalization before deploying a model) and when to prefer the new server for new workflows. It lacks explicit 'when not to use' statements beyond the legacy note, but the context is sufficient.

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

Deploy Server

Other Tools