Skip to main content
Glama
Axiomatic-AI

axiomatic-mcp

Official
by Axiomatic-AI

AxModelFitterLegacy_compute_parameter_covariance

Compute parameter covariance matrices for fitted models to quantify uncertainty and correlations. Use after fitting to obtain standard errors and correlation matrix via robust Huber-White and inverse Hessian estimators.

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.

Compute parameter covariance matrices for fitted model parameters.

Provides uncertainty estimates using robust Huber-White sandwich estimator and
classical inverse Hessian approach. Use after fit_model to quantify parameter
uncertainty and correlations.

REQUIRED: Fitted parameters, model definition, same data used in fitting, variance estimate.
RETURNS: Covariance matrices, standard errors, correlation matrix.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
boundsYesALL parameter/input/output bounds: [{'name': 'a', 'lower': {'magnitude': 0, 'unit': 'dimensionless'}, 'upper': {'magnitude': 10, 'unit': 'dimensionless'}}]
varianceNoNoise variance (σ²) for uncertainty quantification. Estimate from residuals or domain knowledge. (estimated from loss if None)
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')
parametersYesFitted parameter values: [{'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'}
scale_paramsNoEnable parameter scaling for numerical stability
function_nameYesFunction name that computes the model output
function_sourceYesJAX function source code. MUST use jnp operations: jnp.exp, jnp.sin, etc.
cost_function_typeNoCost function: 'mse' (default), 'mae'mse

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.20

TDQS

A3.6/5.0
Behavior3/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 the estimation methods (Huber-White sandwich estimator and classical inverse Hessian), which is useful behavioral context. It also states required inputs and return values. However, it doesn't disclose potential failure modes, computational cost, or what happens if the model wasn't fit with this toolset, and it doesn't mention that this is a read-only computation (no mutation side effects). The method disclosure is meaningful but not comprehensive.

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-structured with a clear legacy warning up front, followed by a concise purpose statement, method details, usage instruction, and required/return summary. The legacy migration notice is somewhat long but earns its place given the tool's deprecation status. The use of bold labels (REQUIRED, RETURNS) improves scannability. Minor redundancy: 'Compute parameter covariance matrices' and 'RETURNS: Covariance matrices' repeat the same information.

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 with 15 parameters and no output schema, the description covers the essential context: what it does, when to use it, what inputs are required, and what it returns. The legacy migration guidance is valuable context. However, it doesn't describe the structure of the returned covariance matrices or how they relate to the parameter order, and it doesn't mention any prerequisites beyond 'fitted parameters' and 'same data'. Given the tool's complexity, a bit more detail on expected output format would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 15 parameters. The description adds the key semantic constraint that 'same data used in fitting' is required, which is critical for correct use. It also mentions 'variance estimate' as required, which maps to the variance parameter. However, it doesn't explain how parameters, bounds, and data_file interrelate beyond what the schema already says, so the added value is moderate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool computes parameter covariance matrices for fitted model parameters, with a specific verb ('Compute') and resource ('parameter covariance matrices'). It also names the sibling alternative (new AxModelFitter server's generate_code/execute_code) and distinguishes the legacy toolset. However, it doesn't explicitly contrast with the closely related sibling AxModelFitterLegacy_calculate_information_criteria or AxModelFitterLegacy_cross_validate_model, so differentiation from all siblings is incomplete.

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 explicitly says 'Use after fit_model to quantify parameter uncertainty and correlations', giving a clear when-to-use instruction. It also provides a strong when-not-to-use directive for new workflows: 'For NEW workflows, prefer the new AxModelFitter server's generate_code/execute_code tools'. It doesn't explicitly list exclusions for other legacy siblings, but the legacy/new workflow guidance is a clear routing signal.

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