Skip to main content
Glama
EasyDeploy-AI

easydeploy-ai-mcp

Official

Run batch prediction

run_batch_prediction

Score an entire dataset against a trained model version by starting a batch prediction job; poll for completion or wait for results.

Instructions

Score an entire dataset against a trained model version.

Each call starts a new batch job and spends one prediction credit per row; get_prediction follows one already started, by its prediction_id.

project_id and target_feature are auto-resolved from the model version record when omitted. dataset_version_id identifies both the input file and the row count for credit billing (one prediction credit per row).

Holdout validation: score your test dataset version with its labels still in it. The CSV you download via get_prediction is that file in its original row order with every column kept (target and ids included), plus prediction and, for classifiers, one probability_<class> column per class (probability_1 is the positive class for a 0/1 target); compute the holdout metrics and decision threshold yourself from it, since EasyDeploy does not return them. For a string target the probability columns are named by encoded class index (probability_0, probability_1, ... in sorted label order), not by label; the completed prediction's classLabels, from get_prediction, maps each index to its label. Columns the model was not trained on, such as ids, are ignored for scoring and kept in the output, so leave them in to join results back; every training feature must be present or the job fails naming the missing one. The download is capped at 9 MB, so keep test files small enough that their scored output fits, or split the test set across several batches.

Returns immediately by default (fire-and-poll). get_prediction(prediction_id) reports the status; for a completed batch it also has batch_output_available: true, download_url and curl_command. Set wait_for_result=true to block for max_wait_seconds (45 s by default, at most 60 s); if the batch is still running then, the result has timed_out: true and next_steps: poll get_prediction to keep waiting.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idNo
target_featureNo
wait_for_resultNo
max_wait_secondsNoWith 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_idYes
dataset_version_idYes
poll_interval_secondsNoSeconds between status checks while waiting (default 5.0). Values below 2 are raised to 2.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.3
    • 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."
  2. Changed3 schema fields changedv0.3.0
    • changedInput schema / properties / max_wait_seconds / default
      Previous value: -600New 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 5.0). Values below 2 are raised to 2."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the generic non-readonly/non-idempotent profile; the description goes well beyond by disclosing credit cost per row, the auto-resolution of project_id/target_feature, the hard failure mode when a training feature is missing, and the 9 MB download cap. The timeout/clamping behavior and the poll-to-keep-waiting fallback give the agent the operational picture annotations cannot.

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 correctly: purpose, then billing, then fleet/timing semantics, then the holdout-validation guidance. Every sentence adds information, but the holdout paragraph is long and drifts toward task-level tutorial content rather than tool-selection guidance, costing some tightness.

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 7-parameter, async, credit-spending job with rich outputs, the description covers inputs, billing, failure modes, polling, and download constraints. Although an output schema exists, the extra explanation of the CSV's prediction/probability columns and classLabels is aligned with the schema rather than redundant noise.

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?

With schema description coverage at 29%, the description carries most of the load: it explains that project_id and target_feature are auto-resolved when omitted, and that dataset_version_id identifies both the input file and the row count used for billing. model_version_id is left to inference, but the three schema-documented timing parameters are covered in the schema itself, so the gap is narrow.

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 precise verb+resource+scope: 'Score an entire dataset against a trained model version.' It immediately distinguishes itself from the sibling run_prediction (single-row) and get_prediction (follows an already-started job), so an agent can route correctly without opening schemas.

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 states that each call starts a NEW batch job and that get_prediction is the tool for following an existing one, naming the selecting condition (you already have a prediction_id). It also gives concrete when-to-use guidance for wait_for_result=true versus fire-and-poll, including what to do after timed_out.

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