AI-ML-Lab-MCP

Overview Schema Source Related Servers Discussions Admin

Regression Metrics

regression_metrics

Compute regression metrics (R2, MAE, MSE, RMSE, MAPE, bias) from a trained model or true and predicted value lists to evaluate and compare model accuracy.

Instructions

Compute regression metrics: R2, MAE, MSE, RMSE and MAPE, plus bias, median and maximum absolute error. Use EITHER a trained model (model_id) OR your own lists of true and predicted values. MAPE is given in percent and skips rows whose true value is 0. Args: model_id (str, optional): ID of a trained regression model. Metrics are recomputed from its stored data. dataset (str): "test", "train" or "both". Only used with model_id. Default is "test". y_true (list[float], optional): True values (use together with y_pred). y_pred (list[float], optional): Predicted values, same length as y_true. Returns: dict: The metrics (one block per dataset when dataset="both").

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "regression_metrics"
  }
}

Input Schema

Name	Required	Default
`y_pred`	No
`y_true`	No
`dataset`	No	test
`model_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full burden and does add real behavior: metrics are recomputed from stored data when model_id is used, MAPE is expressed in percent, and MAPE skips rows whose true value is 0. It does not disclose what happens when neither input mode is supplied, when y_true and y_pred lengths differ, or whether anything is persisted — gaps that matter for an unannotated tool.

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?

Front-loaded with purpose and the either/or choice, then a clean Args/Returns block; every sentence carries information. Slight redundancy between the prose summary and the Args section, and the Args/Returns scaffolding is heavier than needed for four parameters.

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?

No output schema exists, and the Returns line compensates by noting a dict of metrics with one block per dataset when dataset='both'. Combined with the zero-coverage schema being fully documented in prose, an agent can call this correctly; only failure/validation behavior is unaddressed.

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 0%, so the description must do all the work and largely does: every one of the four parameters is explained, including that dataset accepts only 'test'/'train'/'both', defaults to 'test', and is ignored unless model_id is set, plus the same-length constraint on y_true/y_pred. The mutual exclusivity of the two input modes is stated explicitly, which the schema's all-optional shape does not convey.

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?

States a specific verb and resource ('Compute regression metrics') and enumerates the exact metrics produced (R2, MAE, MSE, RMSE, MAPE, bias, median/max absolute error), which separates it from the modeling siblings like linear_regression or ridge_regression. It never explicitly says it is the post-fit evaluation step rather than a fitting tool, so the differentiation is implicit.

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

Usage Guidelines3/5

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

The 'EITHER model_id OR y_true/y_pred' line is strong guidance on invocation modes and prevents a common misuse. However, it gives no guidance on when to pick this over alternatives (e.g. classification_report for classification tasks, or compare_models for model selection), so context is implied rather than stated.

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

Deploy Server