Skip to main content
Glama
Axiomatic-AI

axiomatic-mcp

Official
by Axiomatic-AI

AxModelFitterLegacy_fit_model

Fit user-defined JAX models to experimental data from file-based inputs, using numerical optimization to return optimized parameters, R², and results.

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.

Fit a custom JAX mathematical model against experimental data.

This tool fits user-defined mathematical models to data using numerical optimization.
All data MUST be provided via files (CSV, Excel, JSON, Parquet) - no direct data input.

REQUIRED INPUTS:
1. data_file: Path to your data file (e.g., "/path/to/data.csv")
2. input_data: Maps file columns to input variables
3. output_data: Maps file columns to output variables
4. function_source: JAX function code using jnp operations
5. parameters: Initial parameter guesses with units
6. bounds: Bounds for ALL parameters, inputs, and outputs

DATA MAPPING EXAMPLE:
- data_file: "/Users/data/experiment.csv"
- input_data: [{"column": "time_col", "name": "t", "unit": "second"}]
- output_data: {"columns": ["voltage"], "name": "v", "unit": "volt"}

FUNCTION REQUIREMENTS:
- MUST use JAX operations: jnp.exp(-rate*t), jnp.sin(freq*t), jnp.sqrt(x)
- Valid pint units: 'dimensionless', 'second', 'volt', 'meter', etc.
- All variables (parameters, inputs, outputs) need bounds

RETURNS: Optimized parameters, R², execution time, and result files

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
boundsYesALL parameter/input/output bounds: [{'name': 'a', 'lower': {'magnitude': 0, 'unit': 'dimensionless'}, 'upper': {'magnitude': 10, 'unit': 'dimensionless'}}]
max_timeNoMaximum optimization time in seconds
constantsNoFixed constants: [{'name': 'c', 'value': {'magnitude': 3.0, 'unit': 'meter'}}]
data_fileYesPath to data file (CSV, Excel, JSON, Parquet). All data must be provided via file.
docstringNoBrief description of the model
input_dataYesInput column mappings: [{'column': 'time', 'name': 't', 'unit': 'second'}, {'column': 'x_col', 'name': 'x', 'unit': 'meter'}]
model_nameYesModel name (e.g., 'ExponentialDecay', 'RingResonator')
parametersYesInitial parameter guesses: [{'name': 'a', 'value': {'magnitude': 2.0, 'unit': 'dimensionless'}}]
file_formatNoFile format: 'csv', 'excel', 'json', 'parquet' (auto-detect if None)
jit_compileNoEnable JIT compilation for performance
output_dataYesOutput column mapping: {'columns': ['signal'], 'name': 'y', 'unit': 'volt'} OR {'columns': ['y1', 'y2'], 'name': 'y', 'unit': 'volt'}
function_nameYesFunction name that computes the model output
optimizer_typeNoOptimizer: 'nlopt' (best default), 'scipy' (simple), 'nevergrad' (gradient-free)nlopt
function_sourceYesJAX function source code. MUST use jnp operations: jnp.exp, jnp.sin, etc.
optimizer_configNoOptimizer config: {'use_gradient': True, 'tol': 1e-6, 'max_function_eval': 1000000}
cost_function_typeNoCost function: 'mse' (default), 'mae', 'huber (with delta=1.0)', 'relative_mse'mse

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 burden. It discloses meaningful behavioral traits: legacy status with removal in the next major release, the hard constraint that 'All data MUST be provided via files - no direct data input,' the mandatory jnp-only function requirement, and the requirement that bounds cover ALL parameters, inputs, and outputs. It stops short of disclosing side effects (e.g., where result files are written) or failure modes, but covers far more than the typical description.

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?

Well-organized with clear section headers (LEGACY TOOL, REQUIRED INPUTS, DATA MAPPING EXAMPLE, FUNCTION REQUIREMENTS, RETURNS) and front-loaded with the most decision-critical information (legacy routing). It is long, and the data-mapping example partially duplicates schema examples, but for a 16-parameter legacy tool the length is largely justified.

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 complex tool (16 params, 8 required, nested objects, no annotations, no output schema), the description covers the critical workflow: legacy routing, file-only input, required inputs, JAX constraints, pint units, bounds, and return values. The main gap is the relationship between function_source and the required function_name (whether the source must define a function with that name), which is not explained anywhere.

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% with richly exemplified parameter descriptions, so the baseline is 3. The description adds genuine value beyond the schema by enumerating the required-input workflow, clarifying the cross-parameter invariant that bounds must cover every parameter/input/output, and stating what the tool returns. Minor flaw: its 'REQUIRED INPUTS' list omits model_name and function_name, which the schema marks as required.

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?

States a specific verb+resource: 'Fit a custom JAX mathematical model against experimental data.' The legacy banner explicitly names the replacement (new AxModelFitter server's generate_code/execute_code) and the sibling family it belongs to, so an agent can distinguish it from both the new toolset and other legacy siblings like cross_validate_model or compare_models.

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?

Gives explicit routing guidance: 'existing workflows built on this toolset should continue to use it' and 'For NEW workflows, prefer the new AxModelFitter server's generate_code/execute_code tools.' This tells the agent exactly when to select this tool versus the named alternative, with nothing left to inference.

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