Skip to main content
Glama
Sign In
AI-ML-Lab-MCP

AI-ML-Lab-MCP

by SyedHassan904
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Ridge Regression

ridge_regression

Train an L2-regularized linear regression model on correlated numerical features, with scaling and alpha tuning, to return fit metrics and top features.

Instructions

Train a Ridge (L2-regularised) linear regression. Good when features are correlated. The split must have only numerical, complete features. Args: split_id (str): ID of a split made by train_test_split. alpha (float): Regularisation strength, 0 or more. Larger values shrink coefficients more. Default is 1.0. fit_intercept (bool): Learn an intercept. Default is True. scale (bool): Standardise the features first. Strongly recommended for regularised models. Default is True. Returns: dict: model_id, train/test metrics (R2, MAE, MSE, RMSE, MAPE), top features and warnings.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "split_id": "<split_id>"
    },
    "name": "ridge_regression"
  }
}

Input Schema

NameRequiredDescriptionDefault
alphaNo
scaleNo
split_idYes
fit_interceptNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/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 well: it declares the data prerequisite, the returned dict contents (model_id, R2/MAE/MSE/RMSE/MAPE, top features, warnings), and that regularised models benefit from scaling. It omits side effects — notably whether a model artefact is persisted and how model_id is later consumed.

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?

Purpose and data prerequisite are front-loaded, then a conventional Args/Returns block; nothing is padded. Restating parameter types and defaults that already live in the schema is mildly redundant, but the surrounding semantic text justifies the structure.

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 training tool with no output schema and 0% schema coverage, the description supplies parameters, prerequisite, and return shape, which is the bulk of what an agent needs. Gaps are the lifecycle of the returned model_id and what the 'warnings' field contains.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully compensate, and it does: every one of the four parameters is documented with meaning, acceptable range, directional effect ("larger values shrink coefficients more") and defaults. The guidance on scale ("strongly recommended for regularised models") and the provenance constraint on split_id add real operational meaning.

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 names a specific verb and model ("Train a Ridge (L2-regularised) linear regression") and adds the condition under which it is appropriate (correlated features). It distinguishes itself from the linear/lasso siblings only implicitly through the 'L2' parenthetical rather than by naming an alternative, so it falls short of a 5.

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?

"Good when features are correlated" states a clear positive use case, and "The split must have only numerical, complete features" states a hard prerequisite an agent must check first. No exclusion conditions or explicit alternatives (e.g. lasso for sparse/irrelevant features) are named, so it is clear but not complete.

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