easydeploy-ai-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Run prediction

run_prediction

Score input data against a trained model version or production alias to get predicted labels or values, with optional wait or polling for results.

Instructions

Run a single ad-hoc prediction against a trained model version.

Each call is a new prediction and spends a prediction credit; get_prediction follows one still running, by its prediction_id.

Name the model one way: model_version_id for an exact version, or model_id + alias (such as production) for whichever version the alias points to. Prefer the alias for recurring scoring, so the user can promote a new version with set_model_alias without changing the calls. The result's modelVersionId is the version that actually scored, and alias echoes the alias that resolved it; report that version next to the output.

project_id and target_feature are auto-resolved from the model version record when omitted. By default waits and returns the predicted label or value in output. For a classifier the result also has probabilities, one {"probability_<class>": p} object per entry of output, named like run_batch_prediction's CSV columns, and classLabels, the label each <class> stands for: {"0": "B", "1": "M"} for a text target, {"0": 0, "1": 1} for a 0/1 target. output follows the model's default rule, so a threshold you chose applies to the probability, not to output. Regressors return neither. Set wait_for_result=false to return immediately with prediction_id. A wait lasts max_wait_seconds (45 s by default, at most 60 s); if the prediction is still running then, the result has timed_out: true and next_steps: poll get_prediction to keep waiting.

Input Schema

Name	Required	Description
`alias`	No	With model_id: score with the version this alias (such as 'production') points to when the call runs. Leave empty when passing model_version_id.
`model_id`	No	With alias: the model whose alias picks the version. Leave empty when passing model_version_id.
`input_data`	Yes
`project_id`	No
`target_feature`	No
`wait_for_result`	No
`max_wait_seconds`	No	With wait_for_result=true, how long to wait, in seconds (default 45, at most 60; larger values are clamped). Hosts end long tool calls at different times, some at 60 s, so the default returns well before that; poll get_prediction to keep waiting.
`model_version_id`	No	The exact model version to score with. Leave empty when naming the model by model_id + alias instead.
`poll_interval_seconds`	No	Seconds between status checks while waiting (default 2.0). Values below 2 are raised to 2.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.5.0Oct 25, 2026

addedInput schema / properties / alias

Added value: +{
+  "default": "",
+  "description": "With model_id: score with the version this alias (such as 'production') points to when the call runs. Leave empty when passing model_version_id.",
+  "type": "string"
+}

addedInput schema / properties / model_id

Added value: +{
+  "default": "",
+  "description": "With alias: the model whose alias picks the version. Leave empty when passing model_version_id.",
+  "type": "string"
+}

addedInput schema / properties / model_version_id / default
```
Added value: +""
```

addedInput schema / properties / model_version_id / description

Added value: +"The exact model version to score with. Leave empty when naming the model by model_id + alias instead."

changedInput schema / required

Previous value: -[
-  "model_version_id",
-  "input_data"
-]New value: +[
+  "input_data"
+]

Changed2 schema fields changedv0.4.3Oct 17, 2026

changedInput schema / properties / max_wait_seconds / default
```
Previous value: -150New value: +45
```

changedInput schema / properties / max_wait_seconds / description

Previous value: -"With wait_for_result=true, how long to wait, in seconds (default 150). Values above 150 are clamped to 150 so the call returns before MCP hosts end it (about 3 minutes); poll get_prediction to keep waiting."New value: +"With wait_for_result=true, how long to wait, in seconds (default 45, at most 60; larger values are clamped). Hosts end long tool calls at different times, some at 60 s, so the default returns well before that; poll get_prediction to keep waiting."

Changed3 schema fields changedv0.3.0Oct 2, 2026

changedInput schema / properties / max_wait_seconds / default
```
Previous value: -90New value: +150
```

addedInput schema / properties / max_wait_seconds / description

Added value: +"With wait_for_result=true, how long to wait, in seconds (default 150). Values above 150 are clamped to 150 so the call returns before MCP hosts end it (about 3 minutes); poll get_prediction to keep waiting."

addedInput schema / properties / poll_interval_seconds / description

Added value: +"Seconds between status checks while waiting (default 2.0). Values below 2 are raised to 2."

First observedv0.1.0May 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover the safety/idempotency profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false); the description adds what annotations cannot — each call spends a prediction credit, the call blocks by default, the wait is capped at 60 s with larger values clamped, and a timeout returns timed_out: true plus next_steps. It also discloses the subtle interaction where a chosen threshold affects probabilities but not output.

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 core action and the model-naming rule, then cost, then wait semantics — a sensible ordering. The classifier return-value paragraph (probabilities, classLabels, the {"0": "B"} example) is the longest block and is partly redundant given an output schema exists, which is what keeps this from a 5.

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?

For a costly, non-idempotent, blocking-with-timeout prediction call, the agent gets everything needed to invoke it correctly: two mutually exclusive model-naming modes, default resolution of optional fields, cost per call, timeout behavior, and the follow-up tool. The output schema carries the return shape, so no further description is required.

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 56%, and the description compensates well for the aliasing parameters and for the auto-resolution of project_id and target_feature when omitted — meaning the schema does not convey. input_data is required but its expected shape is left entirely to the bare-object schema, which is the main remaining gap for a 9-parameter tool with nested objects.

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?

Opens with a specific verb and resource ("Run a single ad-hoc prediction against a trained model version") and immediately distinguishes itself from the two nearest siblings: run_batch_prediction (implicitly, via "single ad-hoc") and get_prediction ("follows one still running, by its prediction_id"). An agent can route between these three without opening any schema.

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 conditional guidance: use model_version_id for an exact version vs model_id + alias for alias resolution, and states a preference rule ("Prefer the alias for recurring scoring") with the reason (set_model_alias promotes without changing calls). It also states when to set wait_for_result=false and names the alternative path (poll get_prediction) when the wait times out.

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