io.github.AudialAI/audial-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Generate a sample pack

generate_samples

Extract one-shot drum hits and loops from a finished track by reusing an existing Audial analysis or processing a local audio file into a new sample pack.

Instructions

Extract a sample pack (one-shots and loops) from a track.

Use when the user wants drum hits or loops taken from a finished track. With the analysis_id from segment, the pack is built from that analysis's sections and the stems Audial made for it: nothing is uploaded and it is included in the analysis's run (right after a new analysis it waits a few minutes for the stems). With file_path it runs the sample-pack pipeline: prepares the track (analysis and stems together), then builds the pack; one call, counted as one run, each step reported as it starts and finishes. If that call times out the job keeps running: pipeline_status finds it. Samples go to a new results folder.

Input Schema

Name	Required	Description
`genre`	No	Genre hint.
`job_type`	No	Sample pack job type accepted by Audial (default engine choice when omitted).
`file_path`	No	Full path to a local audio file (.wav, .mp3, .aif, .aiff, .flac, .m4a, .ogg, .aac). ~ is expanded. Give this or analysis_id.
`components`	No	Which components to sample, e.g. ['drums', 'bass'].
`analysis_id`	No	The analysis_id a segment result returned (in its metadata and summary). Reuses that analysis: nothing is uploaded and it does not count as another run. Give this or file_path.

Output Schema

Name	Required	Description	Default
`tool`	Yes
`files`	Yes
`summary`	Yes
`metadata`	Yes
`output_dir`	Yes
`execution_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.7.0Nov 7, 2026

addedInput schema / properties / analysis_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The analysis_id a segment result returned (in its metadata and summary). Reuses that analysis: nothing is uploaded and it does not count as another run. Give this or file_path.",
+  "title": "Analysis Id"
+}

addedInput schema / properties / file_path / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / file_path / default
```
Added value: +null
```

changedInput schema / properties / file_path / description

Previous value: -"Full path to a local audio file (.wav, .mp3, .aif, .aiff, .flac, .m4a, .ogg, .aac). ~ is expanded."New value: +"Full path to a local audio file (.wav, .mp3, .aif, .aiff, .flac, .m4a, .ogg, .aac). ~ is expanded. Give this or analysis_id."

removedInput schema / properties / file_path / type
```
Removed value: -"string"
```
removedInput schema / required
```
Removed value: -[
-  "file_path"
-]
```

First observedv0.1.1Sep 29, 2026

TDQS

A4.2/5.0

Behavior4/5

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

The annotations already flag non-read-only, open-world, non-idempotent behavior, yet the description adds genuine context beyond them: data upload implications per mode, run accounting, the wait for stems after a fresh analysis, per-step progress reporting, and the fact that a timed-out call keeps running in the background. This is strong, but it never states whether repeated calls create duplicate result folders or how cost scales across modes, which matters for a non-idempotent, run-billed tool.

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 front-loaded with the one-line purpose and then organized by mode, with no filler sentences. The sentences are dense, multi-clause and stack several behaviors at once (wait-time, run counting, progress reporting), which slightly slows scanning but no sentence is disposable.

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?

For a five-parameter generation tool with an output schema and no required arguments, the description covers where the output lands (a new results folder), which input combinations are valid, and the failure path for long jobs. Since the output schema handles return values, nothing an agent needs to invoke this correctly is missing.

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?

Schema description coverage is 100%, so the schema already documents all five parameters, which sets the baseline at 3. The description adds meaningful mode semantics on top (analysis_id vs file_path, and the run-count/no-upload consequences), but does not clarify genre, job_type, or components beyond what the schema states.

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 first line gives a precise verb and resource ('Extract a sample pack (one-shots and loops) from a track'), so the agent knows the operation and the artifact produced. It also pins down what a pack contains (one-shots and loops), but it never explicitly contrasts this with stem_split or segment, so sibling differentiation relies on inference.

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?

It states the trigger condition directly ('Use when the user wants drum hits or loops taken from a finished track') and then explains the two mutually exclusive entry modes and their trade-offs: analysis_id reuses an existing run with nothing uploaded, while file_path runs the full `sample-pack` pipeline and costs one run. It even names the fallback (pipeline_status) for the timeout case, leaving little to infer.

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