rvc-training

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

The description adds significant behavioral context beyond annotations: the one-time nature of the upload URL, allocation without GPU start, and consent retry logic. Annotations say readOnlyHint=false (write) and destructiveHint=false, which the description aligns with and elaborates on. No contradiction.

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

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

The description is four sentences, each serving a purpose: purpose, consent guideline, retry procedure, and workflow clarification. It is front-loaded with the main action and contains no redundant information.

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

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

Given the complexity (8 parameters, 7 required, low schema coverage) and the presence of an output schema, the description does not provide enough context for correct invocation. Key parameters like epochs, modelName, and submissionId remain unexplained, leaving the agent to guess their meaning and valid values.

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

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

Schema description coverage is only 25% (2 of 8 parameters described). The tool description does not compensate; it mentions the upload URL and workflow but does not explain parameters like epochs, modelName, sizeBytes, contentType, submissionId, or durationSeconds. The agent lacks semantics for most parameters.

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

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

The description clearly states the tool creates a private NiceVois job and returns a one-time PUT upload URL. It distinguishes from sibling start_training by noting that GPU work is not started until later. The verb-resource pair is specific and actionable.

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

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

The description provides explicit guidance: do not ask for consent on first attempt, retry logic with acceptsStandingAgreement if CONSENT_REQUIRED. It also outlines the sequence (create, upload, start_training). However, it does not explicitly state when not to use this tool or compare to all siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by explicitly stating it is for a 'private' training job and that the tool is meant for polling (implying it is non-mutating and safe to call repeatedly, with a rate hint). No contradictions found.

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

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

The description is two sentences with zero waste. All information is relevant and front-loaded: first sentence states the tool's purpose and scope, second adds a crucial usage constraint. Every word earns its place.

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

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

Given it has an output schema (so return structure is documented), only 1 required parameter with clear purpose, and annotations already cover safety, the description covers all necessary ground. It explains what the tool does, how to use it (polling with rate limit), and distinguishes it from siblings. No gaps remain.

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

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

Schema coverage is 0%, meaning the description must compensate. It does not describe the 'jobId' parameter explicitly, but the tool's purpose ('check one training job') strongly implies jobId identifies which job. With only one required parameter, the context is sufficient. A brief clarification of what jobId looks like would merit a 5.

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

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

The description uses a specific verb ('check'), states a clear resource ('one private NiceVois training job'), and explicitly lists what it retrieves ('stage, completed epochs, ETA, and artifact readiness'). This effectively distinguishes it from sibling tools like create_training_job or list_training_jobs.

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

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

The description explicitly tells when to use this tool ('to check one training job') and provides proactive usage guidance ('poll reasonably; do not call more often than every 15 seconds'). This helps the agent avoid misuse or excessive calls.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, indicating a bounded read operation. The description reinforces this by stating it confirms requirements (not creating or modifying data). It adds valuable behavioral context about what is covered (formats, limits, consent, retention, workflow) beyond the annotations, which is ideal.

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

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

The description is a single concise sentence that front-loads the when-to-use guidance and lists the key categories of information returned. Every element earns its place, with no filler or redundancy. The list format is efficient and clear, fitting well within typical character limits.

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

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

Given zero parameters, perfect annotations (readOnlyHint, no destructive effects), and an output schema present, the description is complete. It sufficiently covers all relevant aspects: usage context, what data is retrieved, and boundary. The tool is informational, and the description leaves no ambiguity for an AI agent.

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

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

The tool has zero parameters, so the schema provides no constraints. The description fully compensates by explaining what the tool returns: details on input formats, duration and epoch limits, consent requirements, output specifications, retention policies, and upload workflow. This adds rich semantic meaning where the schema is empty, achieving high value.

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

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

The description specifies a clear verb+resource combination ('get' + 'training requirements') and explicitly lists the purpose: confirming input formats, duration limits, epoch limits, consent requirements, outputs, retention, and upload workflow. This distinguishes it from sibling tools like create_training_job or start_training, which are operational actions.

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

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

The description begins with 'Use this before training an AI voice,' providing explicit when-to-use guidance. It implies this is a prerequisite or configuration step, clearly differentiating it from the execution-focused sibling tools (e.g., start_training). No exclusions are needed given the tool's informational nature.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe. The description adds that it lists only 'recent' jobs and for the 'authenticated user', which is useful but not extensive. No additional behavioral details like pagination or sorting are provided.

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

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

The description is a single sentence that is front-loaded with the action and resource, and every word adds meaning. No redundant or filler content.

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

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

Given the tool has no parameters, clear annotations, and an output schema that describes return values, the description covers the essential purpose and usage guidance. It could mention that it only lists recent jobs, but the output schema likely defines the structure. Overall, it's complete for this simple tool.

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

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

The input schema has no parameters, and schema description coverage is 100% (trivially). The description adds context by specifying 'recent' and 'authenticated user's', which clarifies the scope implied by the empty schema. A score of 4 reflects that the description effectively handles the parameter-free case.

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

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

The description clearly states the verb 'list' and the resource 'private RVC training jobs', and specifies it returns the authenticated user's recent jobs. It distinguishes itself from siblings like 'get_training_job' which likely retrieves a single job by ID.

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

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

The description explicitly states to use this tool before asking for a job ID, providing clear use-case context. However, it doesn't explicitly mention when not to use it or compare directly with siblings like 'get_training_job' or 'start_training'.

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

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

Annotations already indicate write operation (readOnlyHint=false) and non-destructiveness. The description adds the context of starting training after upload, but does not disclose other behaviors like asynchronicity, potential long execution time, response format, or error conditions. It provides adequate but not rich behavioral context beyond annotations.

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

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

The description is a single sentence, which is concise, but it omits necessary parameter explanation and behavioral details. Conciseness is valued, but not at the cost of essential information. It could be slightly expanded without losing efficiency.

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

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

Given the tool has only one parameter and an output schema that is not described, the description should cover prerequisites (mentioned), response semantics (missing), error possibilities, and async behavior. The context of starting a training job implies possible long-running or queued execution, but no such detail is provided. The description is insufficient for complete understanding.

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

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

The schema description coverage is 0%, so the description carries the full burden of explaining the only parameter (jobId). However, the description never explicitly states that jobId is the ID returned by create_training_job. It only implies this by referencing the upload URL from create_training_job. An agent would benefit from a clear statement like 'The jobId returned by create_training_job.' This omission fails to add meaning beyond the bare schema.

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

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

The description clearly states the verb ('Starts') and the resource ('the private cloud RVC training job'), distinguishing it from sibling tools like create_training_job (which prepares the job) and get_training_job (which checks status). It is specific and immediately informative.

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

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

The description explicitly says 'Use this only after the source audio was successfully PUT to the upload URL returned by create_training_job,' providing a clear precondition and referencing the correct sibling tool. This tells the agent exactly when and after what step to invoke this tool.

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