Skip to main content
Glama

Create an RVC training upload

create_training_job

Creates a private NiceVois job and returns a one-time PUT upload URL. Do not ask for consent before the first attempt because NiceVois remembers the current standing account agreement. If the server returns CONSENT_REQUIRED, ask for one acceptance of the linked standing agreement and retry once with acceptsStandingAgreement=true. This allocates a private training slot but does not start GPU work until the audio is uploaded and start_training is called.

Input Schema

NameRequiredDescriptionDefault
epochsYes
fileNameYesOriginal WAV, MP3, FLAC, M4A, or OGG filename.
modelNameYes
sizeBytesYes
contentTypeYes
submissionIdYes
trainingEngineNorvc (default): Standard RVC, portable .pth and .index. nicevois: NiceVois Training (Seed-VC with a finishing pass); returns a complete ZIP, not an RVC index. Requires a training pass or an eligible subscription.
durationSecondsYes
acceptsStandingAgreementNoSet only when the user explicitly accepts the linked standing voice-training agreement after CONSENT_REQUIRED. Omit for accounts that have already accepted.

Output Schema

NameRequiredDescriptionDefault
idYes
linksYes
epochsNo
statusYes
uploadYes
etaTextNo
messageNo
artifactsYes
createdAtNo
expiresAtNo
modelNameNo
startedAtNo
updatedAtNo
completedAtNo
currentEpochNo
durationSecondsNo
estimatedCompletionAtNo
estimatedRemainingSecondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / trainingEngine / description
      Previous value: -"rvc (default): Standard RVC, portable .pth and .index. nicevois: NiceVois Training (Seed-VC with a finishing pass); returns a complete ZIP, not an RVC index."New value: +"rvc (default): Standard RVC, portable .pth and .index. nicevois: NiceVois Training (Seed-VC with a finishing pass); returns a complete ZIP, not an RVC index. Requires a training pass or an eligible subscription."
  2. Changed1 schema field changed
    • addedInput schema / properties / trainingEngine
      Added value: +{
      +  "description": "rvc (default): Standard RVC, portable .pth and .index. nicevois: NiceVois Training (Seed-VC with a finishing pass); returns a complete ZIP, not an RVC index.",
      +  "enum": [
      +    "rvc",
      +    "nicevois"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses key behavioral details: it returns a one-time PUT upload URL, allocates a private training slot, and does not start GPU work until upload and start_training. It also explains the CONSENT_REQUIRED retry flow and the acceptsStandingAgreement flag, which is valuable operational context.

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 front-loaded with purpose and return behavior, then covers consent handling and lifecycle constraints. Every sentence adds useful operational information without wasted wording.

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 description covers the create/upload/start lifecycle and consent behavior well, and an output schema exists so return values need not be detailed. However, for a 9-parameter tool with only 33% schema description coverage, the lack of parameter explanations leaves a significant completeness 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 only 33%, so the description should compensate for undocumented parameters. Instead, it adds little meaning for most parameters such as epochs, modelName, submissionId, sizeBytes, contentType, and durationSeconds, and its mention of acceptsStandingAgreement largely restates the schema.

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 states a specific verb and resource: it creates a private NiceVois training job and returns a one-time PUT upload URL. It also clarifies the lifecycle relative to start_training, but it does not explicitly differentiate itself from other creation siblings such as create_audio_job or create_voice_conversion.

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?

It gives clear consent-handling guidance and indicates that start_training must be called after upload before GPU work begins. However, it does not explicitly state when to choose this tool over sibling creation tools or describe any when-not-to-use conditions.

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