Skip to main content
Glama

Train

train

Train a new version of the model. Two steps: the first call changes nothing and returns what the run will use from the workspace's allowance plus a confirmation code; show that to the user, and only after they explicitly agree call again with that exact code. The user's yes is not the code. A code works once, for this model and these arguments, for 10 minutes.

Input Schema

NameRequiredDescriptionDefault
model_idYesThe model id, from list_models.
model_typeYesclassifier: Classifier Model (words only). ai_classifier: AI Classifier Model (reads meaning; for pictures, the AI Image Classifier Model). dedicated: Dedicated AI Model trained on the user's examples on a GPU (for pictures, the Dedicated AI Image Model); a model last trained in the workspace's own Amazon Bedrock retrains there, on the same connection and base model. byom: Your AI Model (bring your own model), the workspace's own AI platform asked with the user's examples, nothing trained (text only); retrains with the AI platform, model and settings of its last Your AI Model run, which is first chosen in the app.
confirmationNoThe code from the first call, sent only after the user said yes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / model_type / description
      Previous value: -"classifier: Classifier Model (words only). ai_classifier: AI Classifier Model (reads meaning; for pictures, the AI Image Classifier Model). dedicated: Dedicated AI Model trained on the user's examples on a GPU (for pictures, the Dedicated AI Image Model)."New value: +"classifier: Classifier Model (words only). ai_classifier: AI Classifier Model (reads meaning; for pictures, the AI Image Classifier Model). dedicated: Dedicated AI Model trained on the user's examples on a GPU (for pictures, the Dedicated AI Image Model); a model last trained in the workspace's own Amazon Bedrock retrains there, on the same connection and base model. byom: Your AI Model (bring your own model), the workspace's own AI platform asked with the user's examples, nothing trained (text only); retrains with the AI platform, model and settings of its last Your AI Model run, which is first chosen in the app."
    • changedInput schema / properties / model_type / enum
      Previous value: -[
      -  "classifier",
      -  "ai_classifier",
      -  "dedicated"
      -]New value: +[
      +  "classifier",
      +  "ai_classifier",
      +  "dedicated",
      +  "byom"
      +]
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description adds substantial context those annotations cannot convey: the first call is a no-op preview returning allowance usage plus a code, the code is single-use, scoped to this model and these arguments, and expires in 10 minutes. That is exactly the behavioral detail an agent needs before a costly write.

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?

Four short sentences, front-loaded with the two-step shape, and every sentence carries operational weight (preview, user confirmation, code-is-not-consent, code lifetime). No filler.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and does describe the first call's response (allowance usage plus confirmation code). It does not say what the second call returns or how to track training progress (e.g., via job_status), which leaves a modest gap for a mutating tool.

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 100%, so the baseline is 3, but the description adds real meaning about the confirmation parameter beyond the schema: it is single-use, valid for 10 minutes, and bound to this model and these arguments. The model_id/model_type semantics are left entirely to the schema's already-detailed enum text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Train a new version of the model') and immediately frames it as a two-step operation, so the agent knows what the tool does. It does not, however, distinguish itself from sibling tools like create_model or review_retrain, so the agent must infer which of several model-related tools is appropriate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit procedural guidance: call once to preview, show the user, and only call again after explicit agreement with the exact code, including the sharp caveat that 'the user's yes is not the code.' It lacks any comparison to alternative tools (create_model, publish, cold_start), but the when/when-not protocol for this tool is unusually clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources