mlagents-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MLAGENTS_CONDA_ENV | No | Conda environment name to activate before running mlagents-learn | |
| MLAGENTS_CONDA_PATH | No | Path to conda installation (e.g. /home/user/miniconda3) | |
| MLAGENTS_CONFIG_DIR | No | Training config YAML directory (relative to project root) | config |
| MLAGENTS_RESULTS_DIR | No | Training results directory (relative to project root) | results |
| MLAGENTS_PROJECT_ROOT | No | Root 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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
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.
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.
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.
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.