Skip to main content
Glama
limam-B
by limam-B

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MLAGENTS_CONDA_ENVNoConda environment name to activate before running mlagents-learn
MLAGENTS_CONDA_PATHNoPath to conda installation (e.g. /home/user/miniconda3)
MLAGENTS_CONFIG_DIRNoTraining config YAML directory (relative to project root)config
MLAGENTS_RESULTS_DIRNoTraining results directory (relative to project root)results
MLAGENTS_PROJECT_ROOTNoRoot directory of your Unity project.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
force_trainingA

Launch a new mlagents-learn training run as a background process. Always overwrites previous results for the same run_id. To continue from a checkpoint, use resume_training instead.

By default, blocks until ready: in editor mode (no env_path), waits until mlagents-learn says 'Listening on port... press Play'. In batch mode (with env_path), waits until the executable connects.

Args: config_path: Path to the YAML training config file. run_id: Unique identifier for this training run. env_path: Path to a built Unity environment executable. Omit to use the Unity Editor. num_envs: Number of parallel Unity environment instances. no_graphics: Disable graphics rendering for faster training. torch_device: PyTorch device (e.g. 'cuda', 'cpu', 'cuda:0'). seed: Random seed (-1 for random). time_scale: Unity time scale multiplier. base_port: Base port for Unity communication (auto-assigned if omitted). wait: Block until ready (default true). Editor mode: waits for 'press Play'. Batch mode: waits for connection. wait_timeout: Max seconds to wait when wait=true.

stop_trainingA

Gracefully stop a running training run (sends SIGINT so the model is saved).

Args: run_id: The run to stop. timeout: Seconds to wait for graceful shutdown before force-killing.

resume_trainingA

Resume a previously stopped/completed training run.

If config_path is not provided, reads the saved configuration.yaml from the previous run. By default, blocks until ready (same as force_training).

Args: run_id: The run_id to resume. config_path: Config file path (auto-detected from previous run if omitted). num_envs: Number of parallel Unity environment instances. no_graphics: Disable graphics rendering. torch_device: PyTorch device. time_scale: Unity time scale multiplier. wait: Block until ready (default true). Editor mode: waits for 'press Play'. Batch mode: waits for connection. wait_timeout: Max seconds to wait when wait=true.

cleanup_processesA

Kill orphaned mlagents-learn and Unity build processes that are not tracked by any active run. Use this when force_training fails due to leftover processes occupying ports, or after a crash.

get_run_statusA

Get detailed status of a training run including step progress, reward trend, and checkpoints.

Args: run_id: The run to query. last_n_rewards: Number of recent reward data points to include in the trend. last_n_checkpoints: Number of recent checkpoints to include.

get_metricsA

Read TensorBoard scalar metrics from a training run.

Args: run_id: The run to query. behavior_name: Specific behavior to read (auto-detected if omitted). metric_keys: Specific metric keys to read (defaults to reward, losses, LR). last_n: Number of most recent data points per metric (default 20). Use -1 for all.

get_training_logsA

Get recent stdout/stderr output from an active training run.

Args: run_id: The run to query. last_n_lines: Number of most recent log lines to return.

list_runsA

List known training runs with their status.

Args: status_filter: Filter by status: 'running', 'completed', 'failed', or 'stopped'. last_n: Number of most recent runs to return (default 20). Use -1 for all.

compare_runsA

Compare a specific metric across multiple training runs (useful for hyperparameter tuning).

Args: run_ids: List of run IDs to compare. metric_key: The TensorBoard metric key to compare (e.g. 'Environment/Cumulative Reward'). last_n: Number of most recent data points per run to include in the trend. Use -1 for all.

export_modelA

Locate .onnx model files and checkpoints for a training run.

Args: run_id: The run to query. behavior_name: Specific behavior (searches all if omitted). last_n: Number of most recent models/checkpoints to return. Use -1 for all.

get_configA

Read a YAML training configuration file.

Args: config_path: Path to the config file (relative to config dir or absolute).

update_configA

Deep-merge updates into an existing YAML config file. Only specified keys are changed.

Args: config_path: Path to the config file (relative to config dir or absolute). updates: Dictionary of updates to deep-merge into the config.

wait_for_first_metricsA

Block until the training run produces its first TensorBoard metric data point. Use this right after starting training to know when data starts flowing. Typically takes 1-2 minutes.

Args: run_id: The run to watch. timeout: Max seconds to wait. poll_interval: Seconds between checks.

wait_for_completionA

Block until a training run finishes. Use this to chain runs automatically: start skill A, wait_for_completion, then start skill B. This WILL freeze the conversation until training ends or timeout. Default timeout is 4 hours.

Args: run_id: The run to wait for. timeout: Max seconds to wait (default 14400 = 4 hours). poll_interval: Seconds between internal status checks (default 60).

check_stepA

Check if training reached a target step count. Always returns instantly with current step, reward, and whether the target was reached.

Args: run_id: The run to check. target_step: The step count target.

check_rewardA

Check if mean cumulative reward reached a target threshold. Always returns instantly with current reward, step, and whether the target was reached.

Args: run_id: The run to check. target_reward: The reward threshold.

check_completionA

Check if a training run has finished. Always returns instantly with current status, step, reward, and whether it completed.

Args: run_id: The run to check.

check_checkpointA

Check if new .onnx checkpoint files appeared on disk. Always returns instantly with list of all checkpoints and any new ones.

Args: run_id: The run to check. known_checkpoints: List of checkpoint paths already known (from a previous call). New files = current minus these. If omitted, returns all checkpoints.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 18 tools

Disambiguation4/5

Most tools target distinct resources/actions: launching, stopping, resuming, config, waiting, checking, logging, comparing. A coupple of overlaps exist, especially check_completion vs. wait_for_completion and the various check_* tools vs. get_run_status, but descriptions clearly separate blocking/non-blocking and specific conditions.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: force_training, stop_training, update_config, check_step, get_metrics, list_runs, export_model. There are no style mixes or vague one-word names.

Tool Count3/5

18 tools is in the heavier range and the count is inflated by several near-duplicate monitoring utilities: check_step, check_reward, check_completion, check_checkpoint, wait_for_completion, and wait_for_first_metrics could potentially be consolidated. Still, the coverage is understandable for a training lifecycle server.

Completeness4/5

The server covers most of the training lifecycle: launch, resume, stop, configure, monitor, wait, list, compare, and export models. Minor gaps exist, such as no explicit delete/cleanup for run artifacts besides process cleanup, but core workflows are not dead-end.

Maintenance

ActivityInactive
ResponsivenessNo issues