What can you do with this server?

The wyoloservice2_mcp server enables AI agents to orchestrate distributed YOLO training on NeuralForgeAI clusters via MCP. Capabilities include: * Cluster Administration: Store cluster IP and CIFS credentials, fetch real-time health/worker/task status, and pause/resume invoker queues on specific workers. * Dataset Operations: Verify remote dataset path existence using ephemeral Docker containers, and perform deep validation of YOLO datasets (detection, segmentation, classification) to extract directory structure, class names, and counts. * Training Configuration: Generate NeuralForge Sweeper v2 YAML files with enforced naming conventions, model list, image sizes, epochs, trials, task type, and metadata. * Training Lifecycle: Launch a training study from a local YAML (auto-injecting the returned study_id), monitor live Optuna progress and metrics, and cancel running studies. * Advanced Controls: Launch a private test training targeted to a specific worker, and trigger a broadcast Docker pull on all nodes. * Agentic Assistance: Embedded instructions guide the agent to automatically discover study_id from local YAML files when fetching status, reducing user prompts.

Which integrations are available for this server?

Allows AI agents to inspect and control YOLO training studies in a Train Service 2 / NeuralForgeAI cluster, including launching, canceling, and monitoring training jobs.

How do I use wyoloservice2_mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wyoloservice2_mcp check the cluster status" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

wyoloservice2_mcp

by wisrovi

Overview Schema Related Servers Score Discussions

Python

Remote

🚀 NeuralForgeAI MCP Server (`wyoloservice-mcp`)

Version Python License PyPI

An advanced, state-of-the-art Model Context Protocol (MCP) server that empowers AI agents to seamlessly interact with the NeuralForgeAI YOLO training cluster, remote Samba datasets, and distributed worker nodes. Designed and architected by William Rodriguez (Wisrovi), this MCP bridges the gap between Large Language Models and complex, remote MLOps infrastructure.

📖 Table of Contents

Related MCP server: secure-cluster-mcp

🌟 Introduction

In modern AI workflows, training YOLO models across a distributed cluster requires interacting with remote storage (CIFS/Samba), scheduling hyperparameter sweeps, and monitoring GPU instances. Typically, these tasks are manual and prone to human error.

The wyoloservice-mcp allows any LLM (like Claude, Gemini via Antigravity, or OpenAI) to act on your behalf inside the NeuralForge ecosystem. By defining standard tools via the MCP protocol, the AI can validate datasets remotely, construct complex YAML configuration files, launch training trials, and report back on convergence metrics—all through natural language.

🎯 Why Use This MCP?

Zero-Friction Orchestration: Stop writing curl commands or memorizing YAML schemas. Tell your agent: "Launch a detection training for project Alpha" and watch it happen.
Embedded Intelligence: The MCP server doesn't just expose APIs; it injects strict workflow instructions into the LLM's prompt. It teaches the AI how to use the tools effectively.
Remote Execution: Bypasses local filesystem constraints by spinning up ephemeral Docker containers (worker_executor) to validate data residing deep inside corporate Samba shares.
Fully Traceable: The AI automatically modifies your local configuration files to inject return values (like study_id), ensuring you never lose track of a running cluster job.

✨ Core Features

Stateful Credential Management: Securely stores and manages API and CIFS credentials locally (~/.wyolo_mcp_config.json). The agent will ask for your credentials once and remember them across sessions.
Remote Dataset Validation: Instead of downloading terabytes of images to your local machine, the MCP triggers a validation container inside the cluster that mounts the CIFS share directly, verifying YOLO structures (labels, directories, yaml files) at the source.
Comprehensive Cluster Monitoring: Fetches real-time telemetry from multiple endpoints (/health, /workers, and /tasks) in a single parallelized HTTP call, giving the AI a holistic view of GPU availability and Celery queues.
Sweeper YAML Generation (v2): Autogenerates NeuralForge "Sweeper v2" configuration files locally for user review. It intelligently discovers dataset classes and uses getpass/socket to inject proper metadata and author tracing.
1-Click Training Launch & Tracking: Submits configurations to the NeuralForge API and, upon success, automatically rewrites the local YAML file to include the assigned study_id.

⚙️ Installation Guide

The package is officially published on PyPI. You can install it globally or inside a virtual environment.

From PyPI (Recommended)

pip install wyoloservice-mcp

From Source (Development)

git clone https://github.com/wisrovi/wyoloservice2_mcp.git
cd wyoloservice2_mcp
pip install -e .

Installation automatically exposes the global binary wyolo-mcp, which acts as the stdio server for the MCP protocol.

🔌 Connecting to AI Assistants

To give your AI access to these tools, you must register the wyolo-mcp binary in your client's configuration file.

For Antigravity (Gemini)

Edit your ~/.gemini/config/mcp.json:

{
  "mcpServers": {
    "neuralforge-mcp": {
      "command": "</paht/to/environment>",
      "env": {
        "NEURALFORGE_API_URL": "http://<control_host_ip>:23442"
      }
    }
  }
}

For Claude Desktop

Edit your claude_desktop_config.json:

{
  "mcpServers": {
    "neuralforge-mcp": {
      "command": "wyolo-mcp"
    }
  }
}

For Opencode

Edit your ~/.config/opencode/opencode.jsonc:

{
  "mcpServers": {
    "neuralforge-mcp": {
      "command": "wyolo-mcp"
    }
  }
}

For Cursor IDE

Navigate to Cursor Settings > Features > MCP and add a new server using the command wyolo-mcp.

🛠️ Available Tools (Agent Capabilities)

When connected, the AI automatically gains access to the following toolkit:

set_cluster_credentials(ip, cifs_user, cifs_pass)
- Saves cluster IP and Samba credentials to the local config file.
get_cluster_status()
- Aggregates /health, /workers, and /tasks into a single online diagnostic report.
check_dataset_path(dataset_path)
- Performs a quick remote existence check on the Samba share via Docker.
validate_dataset_advanced(dataset_path, task)
- Deeply inspects the remote dataset to extract classes, counts, and directory integrity.
generate_training_yaml(config, output_dir)
- Builds a strict NeuralForge Sweeper v2 YAML. Enforces naming conventions (<project>_<dataset>).
launch_training(yaml_path)
- Pushes the local YAML to the cluster and auto-injects the returned study_id back into the file.
get_study_details(study_id)
- Fetches live Optuna trial progress, metrics, and active invokers.
cancel_study(study_id)
- Terminates a running study on the cluster.
manage_invoker_queues(worker_ip, action, mode, hours)
- Remotely pauses (temporally or perpetually) or resumes public queue consumption on a specific invoker node.

🧠 Agentic Workflows & Examples

This MCP is embedded with "Agentic Prompting." This means the tool docstrings actively instruct the AI on how to behave. Here are some natural language prompts you can use with your AI:

Example 1: The Initial Setup

User: "I need to configure my NeuralForge cluster. The IP is 192.168.10.252, user is wisrovi, password is wyoloservice." AI: (Calls set_cluster_credentials) "Credentials saved successfully! Your agent is now linked to the cluster."

Example 2: One-Shot Training

User: "Launch a classification training for the 'medical' project using the dataset /datasets/AIDIAGNOST/classification/ages_classification/. Use 150 epochs, 3 trials, and YOLOv8s-cls." AI: (Calls validate_dataset_advanced to discover classes, then generate_training_yaml to build the sweeper config, and finally launch_training to submit it. It then updates the local YAML with the study_id). "Training launched! The study ID has been injected into your local YAML file."

Example 3: The "Magic" Status Check

User: "How is my training going?" AI: (Reads internal tool instruction: DO NOT ASK FOR ID. Scans local directory, finds the YAML file, reads the study_id inside it, and calls get_study_details). "Your study 'medical_ages_classification' is currently on trial 2 of 3, achieving a top-1 accuracy of 94%."

🏗️ Architecture & Design

wyoloservice-mcp is built using the FastMCP framework. It utilizes httpx for asynchronous parallel requests to the NeuralForge API, preventing UI freezing on the agent's end.

For remote dataset validation, it employs the subprocess module to orchestrate docker run commands dynamically. By mounting the Samba CIFS network at runtime inside a lightweight wisrovi/train_service container, it entirely decouples the AI's local host constraints from the massive storage requirements of the training ecosystem.

Example to use

send a new train

get status over a train started

📜 Changelog & Version History

Version 0.4.3 (Current Release) - 2026-07-31

Broadcast Docker Pull: Added trigger_broadcast_docker_pull tool to send Celery broadcast remote control signals to all active nodes, forcing them to execute a docker pull on the specified image for immediate updates.

Version 0.4.2 - 2026-07-31

Study Name Grouping: Removed the timestamp suffix from the Optuna/MLflow study_name in launch_private_test_training to allow runs targeting the same task type and IP to be grouped together under a single MLflow experiment.

Version 0.4.1 - 2026-07-31

Enriched Cluster Telemetry: Upgraded the get_cluster_status tool to automatically resolve the physical IP address of workers executing active GPU training tasks and generate exact docker logs and persistent logging ssh commands.
Launch Private Test Training: Added a fully self-contained launch_private_test_training tool to launch a base test training study (supporting 'detection', 'classification', or 'segmentation') targeted directly to a specific worker IP using forced private routing parameters.

Version 0.4.0 - 2026-07-29

Invoker Queue Management: Added manage_invoker_queues tool to remotely pause (temporal/perpetual) or resume public queue consumption on any specific invoker node by setting persistent states in Redis and sending instant Celery signals.

Version 0.3.0 - 2026-07-03

Optuna cancellation tool integration: Added cancel_study(study_id) tool mapping the /study/{study_id}/cancel FastAPI endpoint.
Prompt instructions tuning: Enhanced tools docstrings with explicit agent guidelines to automatically search the active directory for .yaml files containing a study_id before querying metrics.

Version 0.2.0 - 2026-05-20

Asynchronous parallel status checks: Implemented get_cluster_status() grouping parallel API requests.
Remote dataset validation: Integrated docker subprocess calls to execute validations on local hosts.

Version 0.1.0 (Initial Release) - 2026-02-28

FastMCP stdio server exposing credential config and base studies retrieval tools.

📝 License

This project is open-sourced under the MIT License.

Author: William Rodriguez (Wisrovi) AI Leader & Solutions Architect

Licensing and Usage

This project uses a PolyForm Noncommercial License model:

Community/Research: Licensed under the PolyForm Noncommercial. See LICENSE.
Commercial: Requires a commercial license. See COMMERCIAL.md for details.

Academic Research

If you use this project in academic research, you are required to cite this repository using the provided CITATION.cff and notify the author with a link to your publication.

Changelog

Bumped version due to License update to PolyForm Noncommercial and Dual Licensing model.

Available Tools

8 tools

cancel_studyA

Cancel a running training study by its ID. This will stop the active trials and terminate the executor containers.

ParametersJSON Schema

Name	Required	Description	Default
`study_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses stopping trials and terminating containers, but omits details about reversibility, permission requirements, or side effects (e.g., whether results are preserved).

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?

Two concise sentences, front-loaded with the core action. Every word earns its place with no unnecessary elaboration.

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

Completeness3/5

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

Despite an existing output schema, the description does not hint at return values or confirmation. Missing context about error states, idempotency, or whether partial cancellation is possible. Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It only says 'by its ID', which adds minimal meaning beyond the parameter name 'study_id'. No format, validation, or example is provided.

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?

The description clearly states the verb 'Cancel', the resource 'training study', and the specific actions 'stop the active trials' and 'terminate the executor containers'. This distinguishes it from sibling tools like 'launch_training' or 'get_study_details'.

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

Usage Guidelines3/5

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

The description implies use only for 'running' studies, but does not explicitly state when not to use it, prerequisites (e.g., check study state via 'get_study_details'), or that the action is irreversible.

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

check_dataset_pathB

Verify if a dataset path exists on the remote Samba share by spinning up a lightweight Docker container.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

The description explicitly mentions 'spinning up a lightweight Docker container', which is a key behavioral aspect and goes beyond simple input/output. However, without annotations, it does not fully disclose implications (e.g., latency, cost, idempotency).

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?

The description is a single sentence that conveys the core action and method efficiently. It could be slightly more structured but is not overly verbose.

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

Completeness3/5

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

The presence of an output schema reduces the burden of explaining return values. However, the description lacks information on when to choose this tool over siblings and does not mention the overhead or cost of spinning up a container.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds context that the 'path' is a 'dataset path on the remote Samba share', which is helpful. However, with 0% schema description coverage, it does not fully compensate by specifying path format or constraints.

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?

The description clearly states the tool 'Verify if a dataset path exists', which is a specific verb-resource pair. However, it does not distinguish itself from the sibling 'validate_dataset_advanced', which could also be used for path checking but presumably does more.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives like 'validate_dataset_advanced'. There is no mention of required prerequisites, context, or exclusions.

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

generate_training_yamlA

Generate a NeuralForgeAI training YAML configuration file and save it to disk. This allows the user to inspect the file before launching the training. Returns the absolute path to the generated YAML file.

ParametersJSON Schema

Name	Required	Description	Default
`config`	Yes
`output_dir`	No		.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It mentions file saving and return of path, but does not disclose overwrite behavior, permissions, or any side effects beyond that.

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?

The description is three sentences, each adding value: main action, purpose, return value. No wasted words.

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

Completeness2/5

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

The description omits crucial prerequisites, such as the need to run validate_dataset_advanced first to fill metadata fields. Given the complexity and sibling tools, this is a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% per context, but the tool description adds no parameter info. It does not compensate by explaining the 'config' parameter or the required fields, despite nested schema having descriptions.

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?

The description clearly states the tool generates a training YAML config file and saves it to disk. It distinguishes from siblings like launch_training and validate_dataset_advanced by emphasizing inspection before launching.

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?

The description implies usage before launch_training by saying 'allows the user to inspect the file before launching.' However, it does not explicitly state when not to use or list alternatives, but provides clear context.

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

get_cluster_statusA

Get the overall status of the NeuralForgeAI cluster, including health metrics, active celery workers (invokers), and the current tasks queue.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It implies read-only behavior via 'Get' and describes what is returned, but does not disclose rate limits, authentication needs, or other potential constraints.

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?

Single sentence, front-loaded with main action, no wasted words. Efficient and clear.

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?

Tool is simple with no parameters and has an output schema. Description sufficiently explains what the tool does (get status) and what it includes. No missing context for an agent to use it correctly.

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?

Tool has zero parameters, so schema coverage is 100%. Per guidelines, baseline is 4. Description does not need to add parameter information.

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?

The description clearly states the verb 'Get', the resource 'overall status of the NeuralForgeAI cluster', and lists the included items (health metrics, celery workers, task queue). It distinguishes from sibling tools which are unrelated to status retrieval.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs alternatives, but the tool is self-contained and its purpose implies usage when cluster health is needed. Sibling tools are unrelated, so minimal contrast is needed.

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

get_study_detailsA

Get detailed telemetry and status of a specific YOLO training study. Returns progress, active invoker, and current trial metrics.

IMPORTANT WORKFLOW FOR AGENTS: When the user asks 'how is my training going?' (or similar) without providing a study_id:

DO NOT ask the user for the study_id immediately.
First, search the current working directory for .yaml files.
Read the discovered .yaml files to check if they contain a study_id field.
If you find a study_id inside a YAML file, automatically use this tool with that ID to check its status.
Only ask the user for the ID or file path if you cannot find any .yaml files with a study_id in the current directory.

ParametersJSON Schema

Name	Required	Description	Default
`study_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not explicitly state the tool is read-only, nor does it mention error conditions, authentication requirements, or rate limits.

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

Conciseness3/5

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

The main sentence is concise, but the lengthy workflow section reduces conciseness. While useful, it could be more succinct without losing clarity.

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?

The description explains return values (progress, active invoker, trial metrics) and required parameter. With an output schema present, return details are covered. Minor gaps in error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the schema provides no documentation for the study_id parameter. The description mentions study_id only in the workflow, without specifying format, constraints, or examples.

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?

The description clearly states the tool retrieves detailed telemetry and status of a YOLO training study, with specific return fields (progress, active invoker, trial metrics), distinguishing it from sibling tools like cancel_study or launch_training.

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?

The description provides explicit workflow instructions for agents, specifying when to use this tool (when user asks about training progress) and alternative steps (search YAML files for study_id) before asking the user.

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

launch_trainingA

Submit a locally saved YOLO training YAML configuration to the NeuralForgeAI cluster. Use this after the user has reviewed and approved the YAML file generated by generate_training_yaml.

ParametersJSON Schema

Name	Required	Description	Default
`yaml_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description must disclose traits. Only says 'Submit', missing details on whether action is synchronous, idle, or destructive (costly). No error or result info.

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?

Two concise sentences, front-loaded with purpose, no unnecessary words. Each sentence adds value.

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

Completeness3/5

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

Adequate for a single-parameter tool with output schema, but lacks details on submission outcome (e.g., job ID returned, async behavior). More context would help.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 0%; description mentions 'locally saved YOLO training YAML' but does not clarify path format, existence requirements, or validation for the single parameter.

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?

Clearly states verb 'Submit' and resource 'YOLO training YAML configuration' to a specific cluster. Distinguishes from sibling `generate_training_yaml`.

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?

Explicitly states to use after user has reviewed and approved the YAML from `generate_training_yaml`, providing clear prerequisite context. Lacks explicit when-not-to-use or alternatives.

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

set_cluster_credentialsA

Save the cluster IP and Samba CIFS credentials to a local configuration file. The agent should call this tool when the user provides the cluster IP and credentials.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes
`cifs_pass`	Yes
`cifs_user`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the side effect of saving to a local configuration file, but does not specify whether it overwrites, appends, or handles existing files. More detail would improve transparency.

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?

Two sentences, no wasted words. Information is front-loaded with the action and followed by usage guidance. Highly concise.

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

Completeness3/5

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

Given the tool's simplicity and the presence of an output schema (not shown), the description covers the basic purpose and trigger. However, it lacks details on prerequisites, error handling, or security implications, leaving some gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description adds no meaning beyond the parameter names. It does not explain formats, constraints, or usage for 'ip', 'cifs_user', or 'cifs_pass'. For a tool with 3 required parameters, this is a significant gap.

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?

The description clearly states the action: 'Save the cluster IP and Samba CIFS credentials to a local configuration file.' It specifies the verb 'save' and the resource 'cluster IP and Samba CIFS credentials', distinguishing it from sibling tools like get_cluster_status or launch_training.

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?

The description explicitly states when to call the tool: 'The agent should call this tool when the user provides the cluster IP and credentials.' This provides clear context, though it does not mention when not to use it or alternatives.

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

validate_dataset_advancedB

Validates a YOLO dataset structure by running an inspection script inside a Docker container connected to the remote CIFS share. Supports detect/segment (yaml) and classify (directory).

ParametersJSON Schema

Name	Required	Description	Default
`task`	No		detect
`dataset_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

The description discloses that execution occurs inside a Docker container connected to a remote CIFS share, which is useful behavioral context. No annotations were provided, so the description partially fills the gap. However, it does not mention potential side effects, required permissions, or whether the tool is read-only.

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?

The description is two sentences long, front-loads the core purpose, and each sentence adds meaningful information. No superfluous content.

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

Completeness3/5

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

Given the complexity (Docker execution, remote share, multiple task types), the description omits prerequisites (Docker, CIFS mount), potential errors, and timeouts. However, since an output schema exists, return values are not required. The description is adequate for basic understanding but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds value by explaining that 'task' supports detect/segment (yaml) and classify (directory), and 'dataset_path' is the path on the CIFS share. However, it does not detail allowed values for 'task' beyond these categories or the format of 'dataset_path'.

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?

The description clearly states it validates a YOLO dataset structure, specifies the method (Docker container, CIFS share), and lists supported task types. However, it does not distinguish from the sibling tool 'check_dataset_path', which may perform a similar validation.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'check_dataset_path'. The description does not include context for use cases or prerequisites.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: canceling, checking paths, generating YAML, cluster status, study details, launching, credentials, and dataset validation. No overlapping functionality.

Naming Consistency5/5

All tools use snake_case with a consistent verb_noun pattern (e.g., cancel_study, generate_training_yaml). There are no naming convention conflicts.

Tool Count5/5

8 tools is appropriate for the server's scope—covering credential setup, dataset validation, YAML generation, training launch, monitoring, and cancellation. No unnecessary tools.

Completeness4/5

The toolset covers the core training lifecycle, but lacks a tool to list existing studies or modify credentials after setup. The workflow instructs agents to find study IDs from local YAML files, which is a reasonable workaround.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

givemeanode
com.givemeanode
On-demand GPU nodes for agents: create nodes, run commands, and submit jobs, billed by the minute.
AI & Machine Learning Cloud Platforms Code Execution
1
Sprawl
to.sprawl
Build and supervise fleets of agents from Claude Code, Codex or Cursor. Connects over OAuth.
Agent Orchestration Autonomous Agents App Automation
1
northflank A
io.usefulapi
Inspect and control your Northflank projects, services, jobs, and builds from your AI assistant.
Cloud Platforms CI/CD & DevOps
172
laravel-forge A
io.usefulapi
Manage Laravel Forge servers, sites, and deployments from your AI assistant.
Cloud Platforms Developer Tools CI/CD & DevOps
172

Related MCP Servers

Kubeflow MCP Serverofficial
AI & Machine Learning Agent Orchestration
kubeflow
A
license
Not graded
quality
A
maintenance
Enables AI agents to plan, submit, monitor, and manage Kubeflow training jobs through natural language, without needing to learn Kubernetes or the Kubeflow SDK.
Updated 6 hours ago (2026-09-03 13:52 UTC)
41
Apache 2.0
secure-cluster-mcp
Shell Access File Systems Command Line
FlorianSp2000
A
license
Not graded
quality
C
maintenance
Enables AI assistants to manage SLURM cluster jobs with safety guardrails, including file transfer, job submission, log reading, and remote command execution.
Updated 3 months ago (2026-05-25 12:51 UTC)
1
MIT
colab-autopilot
Agent Orchestration Code Execution AI & Machine Learning
Emile-Andre
A
license
Not graded
quality
D
maintenance
Enables AI agents to autonomously manage Google Colab GPU sessions, submit and monitor training jobs, and debug/fix issues via an encrypted tunnel without requiring a browser tab.
Updated 5 months ago (2026-04-07 17:51 UTC)
MIT
ultralytics-mcp
AI & Machine Learning Cloud Platforms
amanharshx
A
license
B
quality
A
maintenance
Enables management and interaction with the Ultralytics Platform, including browsing projects/datasets/models, starting training, running predictions, and creating exports.
Updated 2 months ago (2026-07-18 12:14 UTC)
28
16
10
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wisrovi/wyoloservice2_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🚀 NeuralForgeAI MCP Server (wyoloservice-mcp)

📖 Table of Contents

🌟 Introduction

🎯 Why Use This MCP?

✨ Core Features

⚙️ Installation Guide

From PyPI (Recommended)

From Source (Development)

🔌 Connecting to AI Assistants

For Antigravity (Gemini)

For Claude Desktop

For Opencode

For Cursor IDE

🛠️ Available Tools (Agent Capabilities)

🧠 Agentic Workflows & Examples

Example 1: The Initial Setup

Example 2: One-Shot Training

Example 3: The "Magic" Status Check

🏗️ Architecture & Design

Example to use

send a new train

get status over a train started

📜 Changelog & Version History

Version 0.4.3 (Current Release) - 2026-07-31

Version 0.4.2 - 2026-07-31

Version 0.4.1 - 2026-07-31

Version 0.4.0 - 2026-07-29

Version 0.3.0 - 2026-07-03

Version 0.2.0 - 2026-05-20

Version 0.1.0 (Initial Release) - 2026-02-28

📝 License

Licensing and Usage

Academic Research

Changelog

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Kubeflow MCP Serverofficial

Latest Blog Posts

MCP directory API

🚀 NeuralForgeAI MCP Server (`wyoloservice-mcp`)