easydeploy-ai-mcp

Official

by EasyDeploy-AI

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Get training status

get_training_status

Read-onlyIdempotent

Check an EasyDeploy AI training job by job_id and optionally wait for it to complete or fail, returning status, training time, and model version.

Instructions

Check a training job by job_id (the jobId field from submit_training_job).

Response fields:

status: PENDING | RUNNING | COMPLETE | FAILED
trainingTimeSeconds: wall-clock seconds once the job stops; null while running
modelVersionId: the model version being trained

By default returns the current status immediately.

Set wait=true to block until the job reaches a terminal state (COMPLETE or FAILED). Polls every poll_interval_seconds (default 10 s) for up to timeout_seconds (45 s by default, at most 60 s; some hosts end a tool call at 60 s). Training can take from minutes to several hours depending on the plan and the data. If the timeout expires, the last polled status is returned with timed_out: true and next_steps: the job is still running, so call this tool again with the same job_id to keep waiting — do not resubmit the training job.

Input Schema

TableJSON Schema

Name	Required	Description
`wait`	No
`job_id`	Yes
`timeout_seconds`	No	With wait=true, how long to block, 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; call get_training_status again to keep waiting.
`poll_interval_seconds`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.4.3Oct 17, 2026

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

changedInput schema / properties / timeout_seconds / description

Previous value: -"With wait=true, how long to block, in seconds (default 150). Values above 150 are clamped to 150 so the call returns before MCP hosts end it (about 3 minutes); call get_training_status again to keep waiting."New value: +"With wait=true, how long to block, 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; call get_training_status again to keep waiting."

Changed2 schema fields changedv0.3.0Oct 2, 2026

changedInput schema / properties / timeout_seconds / default
```
Previous value: -180New value: +150
```

addedInput schema / properties / timeout_seconds / description

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

First observedv0.1.0May 29, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive); the description goes well beyond them by disclosing the polling interval, the 45s default and 60s ceiling, host-side tool-call cutoffs, and the exact timeout-expiry payload (timed_out: true plus next_steps). That is the operational context an agent cannot infer from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose, then a compact response-field list, then the wait/timeout semantics. Bullets and inline code formatting make it scannable, and no sentence is filler — even the closing warning about not resubmitting carries distinct guidance.

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 polling tool with a long-running backend, everything needed is present: the terminal states, the timeout contract, the retry loop, and the response fields. An output schema exists, yet the description's field summary still adds clarity about null-while-running and timed_out rather than duplicating blindly.

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 only 25%, so the description must carry the load, and it does: job_id's provenance, wait=true semantics, poll_interval_seconds (default 10 s), and timeout_seconds (default 45, max 60, larger values clamped). Every parameter is given meaning beyond its bare type/default.

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 and resource ('Check a training job by job_id') and immediately anchors the identifier to its source tool ('the jobId field from submit_training_job'), which cleanly separates it from sibling submit_training_job and from the unrelated get_upload_status/get_model_report.

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 contrasts the default non-blocking behavior with wait=true, and gives a precise recovery rule for the timeout case: 'call this tool again with the same job_id to keep waiting — do not resubmit the training job.' It even notes training can take hours, telling the agent when polling is expected rather than a failure.

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