Skip to main content
Glama
Sign In
ableton-auto-mix-mcp

ableton-auto-mix-mcp

by HighVoltSound
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

suggest_style

Read-onlyIdempotent

Analyze rendered track WAV files to recommend the best matching style profile before applying auto-mix or previewing the mix in Ableton Live.

Instructions

Analyze the rendered tracks and suggest which style profile fits best.

Read-only. Use this before auto_mix when you are unsure which style to pick; the returned profile name can then be passed to auto_mix or preview_mix.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "suggest_style"
  }
}

Input Schema

NameRequiredDescriptionDefault
patternNoGlob pattern matching the WAV files inside render_dir. Default '*.wav'.*.wav
render_dirNoFolder containing one WAV per track (bounced from Ableton). Defaults to the renders/ directory.renders

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / pattern / description
      Added value: +"Glob pattern matching the WAV files inside render_dir. Default '*.wav'."
    • addedInput schema / properties / render_dir / description
      Added value: +"Folder containing one WAV per track (bounced from Ableton). Defaults to the renders/ directory."
  2. First observedv0.1.2

TDQS

A4/5.0
Behavior4/5

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

The description states 'Read-only,' which aligns with and reinforces the readOnlyHint annotation. Rather than contradicting, it adds value by confirming the non-destructive nature and framing the output as a suggested profile name to be consumed by sibling tools. With both readOnlyHint and idempotentHint annotations present, the description's disclosure is adequate—it adds the context of what the output is used for.

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 tight and effective. The first line states the primary function, and the second paragraph gives targeted usage guidance and output flow. Every sentence earns its place—no filler, no repetition of schema details, appropriately front-loaded.

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 tool has an output schema (which the description needn't explain), a read-only safety profile covered by annotations, and full parameter documentation in the schema. The description covers the essential behavioral context—what it does, when to use it, and how the result flows into auto_mix/preview_mix. This is complete for a tool of this complexity.

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 both parameters (pattern and render_dir) are already documented with their own descriptions including defaults. The description adds no additional parameter semantics beyond what the schema provides. Per the baseline rule for high schema coverage, a 3 is appropriate.

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 what the tool does: analyze rendered tracks and suggest a fitting style profile. 'Suggest which style profile fits best' is a specific verb+resource combination. It's reasonably distinguishable from siblings like list_styles (which lists available profiles) and get_style (which retrieves a specific one), though it doesn't explicitly name those alternatives.

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 instructs when to use it: 'Use this before auto_mix when you are unsure which style to pick.' It also explains the downstream flow—the returned profile name can be passed to auto_mix or preview_mix. This provides clear context on when to invoke it, though it doesn't explicitly mention when NOT to use it beyond the 'unsure' framing.

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

Deploy Server

Other Tools