Skip to main content
Glama
Axiomatic-AI

axiomatic-mcp

Official
by Axiomatic-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

AxModelFitterLegacy_compare_models

Compare multiple fitted models to identify the statistically best using AIC/BIC and Akaike weights.

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.

Compare multiple models to find the best one using statistical criteria.

USE CASE: You have several competing models (linear, exponential, polynomial) fitted to the same data.
This tool tells you which model is statistically best.

REQUIRED INPUTS:
- models: List of your fitted models with their loss values and parameter counts
- data_file: Path to your data file (same data used for all models)
- output_data: Which columns contain your output data
- sigma: Noise level (required for MSE models, None for MAE models)

EXAMPLE MODELS INPUT:
[
    {"name": "Linear", "loss_value": 0.05, "cost_function_type": "mse", "n_parameters": 2},
    {"name": "Exponential", "loss_value": 0.02, "cost_function_type": "mse", "n_parameters": 3}
]

RETURNS: Ranked models with statistical evidence for which is best.
Lower AIC/BIC = better model. Akaike weights show relative model support.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
n_obsNoExplicit count of independent residuals for ALL models. If None, infers from output data
sigmaNoREQUIRED noise std dev for diagonal covariance Σ=σ²I applied to ALL models. For mse: provide from domain knowledge. For mae: use None.
modelsYesList of model dicts: [{'name': 'Model1', 'loss_value': 0.01, 'cost_function_type': 'mse', 'n_parameters': 3}, ...]
data_fileYesPath to data file (CSV, Excel, JSON, Parquet). All data must be provided via file.
file_formatNoFile format: 'csv', 'excel', 'json', 'parquet' (auto-detect if None)
output_dataYesOutput column mapping: {'columns': ['y'], 'name': 'y', 'unit': 'volt'} or {'columns': ['y1', 'y2'], 'name': 'y', 'unit': 'volt'}
df_effectiveNoEffective degrees of freedom for penalized models (EXCLUDING scale) - applied to ALL models
n_scale_paramsNoNumber of scale parameters: 1 for single-output, d for d-output with separate scales
aicc_include_scaleNoInclude scale parameter in AICc correction (literature varies)
include_scale_paramNoInclude scale parameter (σ² or b) in k count

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.20

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 provides important context: the tool is an unchanged legacy continuation subject to removal, all data must come via file, and sigma is conditionally required for MSE vs MAE models. It also previews the return concept (ranked models, AIC/BIC, Akaike weights), though it omits side-effect/error behavior.

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 well-organized with labeled sections (LEGACY TOOL, USE CASE, REQUIRED INPUTS, EXAMPLE, RETURNS) and front-loads the important migration warning. It is somewhat wordy, with minor repetition between the opening and the use case, but remains scannable.

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?

The description covers purpose, usage, required inputs, an input example, and return semantics, which is substantial for a tool with no output schema. Advanced statistical parameters (n_obs, df_effective, scaling flags) are left to the schema, so the description is complete but not exhaustive.

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 descriptions cover all 10 parameters, so the baseline is 3, but the description adds a REQUIRED INPUTS section and a concrete 'EXAMPLE MODELS INPUT' that clarifies the nested models structure and the conditional sigma rule. This extra guidance helps an agent construct a valid call.

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 direct verb-resource statement: 'Compare multiple models to find the best one using statistical criteria,' then grounds it in a concrete use case (competing linear/exponential/polynomial models on the same data). This clearly separates it from fitting or criteria-calculating siblings.

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

Usage Guidelines5/5

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

It explicitly states when the legacy tool should be used ('existing workflows...should continue to use it') and when it should not ('For NEW workflows, prefer the new AxModelFitter server'), with a removal notice. The USE CASE paragraph names the exact scenario that should trigger this tool.

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