Skip to main content
Glama
Axiomatic-AI

axiomatic-mcp

Official
by Axiomatic-AI

AxModelFitterLegacy_calculate_information_criteria

Calculate AIC, BIC, and AICc from loss value and parameter count to compare model architectures and select the best complexity, preventing overfitting.

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.

Calculate AIC and BIC information criteria for model selection.

REQUIRED INPUTS:
- loss_value: MSE or MAE value from your optimization
- cost_function_type: Either 'mse' or 'mae' only
- n_parameters: Number of fitted parameters in your model
- sigma: Noise standard deviation (REQUIRED for MSE, None for MAE)
- data_file: Path to your data file
- output_data: Which columns contain your output data

WHEN TO USE:
- Compare different model architectures (linear vs exponential vs polynomial)
- Select best model complexity (avoid overfitting)
- Use AIC/BIC values: lower is better

SIGMA PARAMETER:
- For MSE (Gaussian noise): Provide noise std dev from domain knowledge
- For MAE (Laplace noise): Set sigma to None
- Example: experimental measurement error ±0.1 volts → sigma=0.1

RETURNS: AIC, BIC, AICc values with interpretable model comparison metrics.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
n_obsNoExplicit count of independent residuals. If None, infers from output data
sigmaYesREQUIRED noise std dev for diagonal covariance Σ=σ²I. Specify from domain knowledge or estimate based on available data.
data_fileYesPath to data file (CSV, Excel, JSON, Parquet). All data must be provided via file.
loss_valueYesMean loss value from optimization (MSE or MAE only)
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)
n_parametersYesNumber of fitted parameters in mean function (scale param added automatically)
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)
cost_function_typeYesLoss function type: 'mse' (Gaussian) or 'mae' (Laplace) only
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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the legacy status, planned removal, and that behavior is unchanged from the original AxModelFitter. It also explains the conditional sigma requirement (required for MSE, None for MAE) and specifies the return payload as AIC, BIC, and AICc. This is substantial behavioral context beyond the schema, though it does not detail error cases or side effects.

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 longer than average but well organized with clear headers: LEGACY TOOL, REQUIRED INPUTS, WHEN TO USE, SIGMA PARAMETER, RETURNS. The legacy front-loading is important for routing decisions. The required-input list is somewhat redundant with the schema, but the extra context sections justify the length.

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 12-parameter tool with no output schema, the description covers the key inputs, the conditional sigma behavior, use cases, and the returned values. Optional parameters like n_obs, df_effective, and include_scale_param are left to the schema, which is acceptable. The returns statement is present but slightly generic ('interpretable model comparison metrics'); a more explicit note about AICc handling would round it out.

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 coverage is 100%, so the baseline is 3. The description adds value by clarifying that sigma is required for MSE and None for MAE, and it gives a concrete example (measurement error ±0.1 volts → sigma=0.1). It also enumerates required inputs and links cost_function_type strictly to 'mse' or 'mae'. This goes beyond the schema's descriptions.

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 specific verb and resource: 'Calculate AIC and BIC information criteria for model selection.' It clearly distinguishes this legacy tool from the new AxModelFitter generate_code/execute_code tools and from sibling metrics tools like calculate_r_squared and fit_model. The legacy framing also prevents confusion with similarly named 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?

The description provides an explicit WHEN TO USE section: compare model architectures, select best model complexity, and use lower AIC/BIC values. It also gives clear routing guidance by telling existing workflows to continue using the legacy tool while directing new workflows to the new AxModelFitter server. This is strong alternative-identification.

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