easydeploy-ai-mcp

Official

by EasyDeploy-AI

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Set model alias

set_model_alias

DestructiveIdempotent

Create or move a model alias to a specific trained model version so prediction calls stay unchanged while the alias switches versions; request confirmation before schema or target changes.

Instructions

Point a model alias, such as staging or production, at one of the model's versions: creates the alias, or moves it. Callers that predict with model_id + alias score with the new version from then on, without changing their calls. Pointing an alias at the version it already has changes nothing.

Promote a version only after it passed holdout validation (playbook section validate) and the user agreed. alias starts with a lowercase letter, then lowercase letters, digits or -, 32 characters at most; latest is reserved. The version must belong to model_id and have finished training (TRAINING_COMPLETED).

Every call first checks the change without writing. When the version was trained on different columns or a different target than the one the alias points to now, callers sending the old columns may fail or get a different kind of answer, so the tool writes nothing and returns needs_confirmation: true with warnings (TRAINING_COLUMNS_CHANGED with the added and removed columns, TARGET_FEATURE_CHANGED, TRAINING_COLUMNS_UNKNOWN), current_model_version_id, expected_current_model_version_id and next_steps. Show the user those changes and call again with confirm=true and that expected_current_model_version_id only if they agree. If the alias moved in between, nothing is written and needs_confirmation comes back with the new state. Otherwise the alias is written and the result has modelVersionId, version, previousModelVersionId, warnings and ui_url.

Needs a full-scope API key: a predict-only key gets 403 INSUFFICIENT_SCOPE, and only the user can supply a full-scope key. A 409 means the alias moved at the same moment and nothing was written; call again without confirm to see where it points now.

Input Schema

Name	Required	Description
`alias`	Yes
`confirm`	No	Write the alias even though the check found warnings. Set it only after the user has seen the warnings and agreed.
`model_id`	Yes
`project_id`	Yes
`model_version_id`	Yes
`expected_current_model_version_id`	No	The current_model_version_id returned by the needs_confirmation result, or the literal 'none' for a new alias. With confirm=true, the alias is written only if it still points there; otherwise the tool returns needs_confirmation again with the new state.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.0Oct 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations flag destructiveHint=true, but the description goes far beyond: a dry-run check on every call, the needs_confirmation/warnings protocol with named codes (TRAINING_COLUMNS_CHANGED, TARGET_FEATURE_CHANGED, TRAINING_COLUMNS_UNKNOWN), a 409 race-condition meaning, and the 403 INSUFFICIENT_SCOPE requirement for a full-scope API key. This is exactly the context annotations cannot carry.

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 effect, then rules, then the confirmation protocol, then error behavior—a sensible order. It is long (five paragraphs) and repeats some return-value detail that the output schema already covers, so a little trimming is possible, but almost every sentence carries operational weight.

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 destructive, race-prone mutation with a multi-step confirmation flow, the description covers authorization requirements, idempotency behavior, conflict handling, and the warning/retry loop. Nothing an agent needs in order to call this correctly—or to decide to stop and ask the user—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 only 33%, so the description must compensate, and it largely does: alias format rules (lowercase start, 32 chars, 'latest' reserved) and model_version_id constraints are stated, and expected_current_model_version_id / confirm semantics are explained through the confirmation flow. project_id and model_id remain undescribed, though their meaning is self-evident.

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: "Point a model alias... at one of the model's versions: creates the alias, or moves it." The dual-mode nature (create vs. move) is spelled out, and the effect on prediction callers separates it clearly from siblings like list_model_aliases and create_model_version.

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 preconditions: promote only after holdout validation (playbook section 'validate') and user agreement, and the target version must be TRAINING_COMPLETED and belong to model_id. It also defines an explicit when-not: if the alias already points at the version, nothing changes.

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