easydeploy-ai-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Create model version

create_model_version

Define a training-ready model version linked to a dataset version and target column, then pass its ID to submit_training_job. Supports time-series mode for ordered forecasting data.

Instructions

Create a model version tied to a dataset version and target column. Then call submit_training_job with the returned model version id.

Pass the train dataset's version, never the test one: a test file that reaches training is no longer a holdout. EasyDeploy does not check the type.

Set time_series_mode=true and time_column when forecasting ordered periods (e.g. weekly business metrics). Time-series mode uses forward-chaining cross-validation (TimeSeriesSplit) instead of shuffled k-fold: each fold trains on earlier periods and scores on later ones. get_model_report records the strategy a run used in metrics.crossValidation.strategy (time_series_split for forward-chaining).

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": {
      "project_id": "<project_id>",
      "model_id": "<model_id>",
      "dataset_version_id": "<dataset_version_id>",
      "target_feature": "<target_feature>"
    },
    "name": "create_model_version"
  }
}

Input Schema

Name	Required	Description	Default
`model_id`	Yes
`project_id`	Yes
`time_column`	No
`target_feature`	Yes
`time_series_mode`	No
`dataset_version_id`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.0Oct 2, 2026
- addedInput schema / properties / time_column
```
Added value: +{
+  "default": "",
+  "type": "string"
+}
```
- addedInput schema / properties / time_series_mode
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```
First observedv0.1.0May 29, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare write/non-destructive/non-idempotent, so the safety profile is covered. The description adds real behavioral context beyond that: EasyDeploy does not validate dataset-type, so misuse silently breaks the holdout, and time_series_mode switches the downstream cross-validation to TimeSeriesSplit. It stops short of saying whether duplicate/creation calls fail or what the created version's state is.

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 the action and next step, then the critical pitfall, then the optional time-series behavior. Well organized and mostly earned, though the final sentence about get_model_report recording the strategy is somewhat tangential for a create tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists so return values need not be explained. For a write tool operating in a multi-step workflow, the description supplies the sequencing, the data-hygiene caveat, and the semantics of the non-obvious parameters – nothing an agent needs to call it correctly is missing.

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 description coverage is 0%, so the description carries the full burden. It explains dataset_version_id (must be the train split), target_feature (the target column), and both time_series_mode and time_column with their semantics and default behavior. model_id and project_id are left implicit, which is the only gap.

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 ('Create a model version') and immediately scopes it ('tied to a dataset version and target column'), distinguishing it from siblings create_model, create_dataset_version and get_model_version. An agent knows exactly what object is produced.

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?

Explicitly routes to the next step ('Then call submit_training_job with the returned model version id'), states a hard prerequisite (pass the train version, never the test one, and why a leaked holdout is harmful), and gives the condition for time_series_mode ('when forecasting ordered periods'). This is when-to-use, when-not, and alternatives in one place.

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