SoundCraft MCP Server

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

Annotations already declare the safety profile (not read-only, not open-world, not idempotent, not destructive). The description adds useful operational context — accepted input formats, target formats, and the fact that it delegates to SoundCraft's converter — but does not disclose overwrite semantics, where outputs land, or whether existing files are affected, which matters for a tool that writes to disk.

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?

A single front-loaded sentence led by the verb, with no filler. It is dense with parenthetical format lists but every clause carries information; the only mild cost is readability from packing all options into one sentence.

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?

For an 11-parameter write tool with no output schema and only 36% schema coverage, the description covers the core conversion story but omits output behavior (where files are written, what is returned) and several parameters. It is adequate to attempt a call but incomplete for confident edge-case handling like overwriting.

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 36%, so the description must compensate, and it partially does: it clarifies input cardinality (one, a list, or a folder, mapping to input_path/input_paths/input_dir) and names sample rate, bit depth, and normalize. However it says nothing about suffix, overwrite, or output_path/output_dir semantics beyond what the schema provides.

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 gives a specific verb (convert) and resource (audio files), and enumerates accepted input formats (WAV, AIFF, FLAC, MP3, OGG, M4A/AAC, ALAC, CAF) and target formats (WAV, AIFF, FLAC), plus its optional transformations. It clearly describes the operation, though it never explicitly distinguishes itself from the sibling process_audio, leaving some ambiguity about which to pick.

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 explains optional capabilities (sample rate, bit depth, normalizing) but gives no guidance on when to use this tool versus process_audio or export_session, nor any prerequisites or exclusions. Usage is only weakly implied by the verb 'convert'.

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 declare it is a non-read-only, non-destructive, non-idempotent operation, so the mutation profile is covered. The description adds genuinely useful behavior beyond that: it discloses exactly which files are written (wav/aiff/flac, stems, MIDI, editable .scraft session) and that it reports peak and integrated LUFS plus returns a waveform picture, which the annotations do not convey.

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 purpose is front-loaded in the opening clause, which is good. However, the description is a single sprawling run-on sentence that enumerates nearly every field the schema already documents, so much of its length does not earn its place and hurts scannability.

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?

For an 18-parameter tool with no output schema, the description does well by describing the return artifacts (mix files, stems, MIDI, LUFS, waveform image). It omits nuance around overwrite/output path behavior, but those are covered by parameter descriptions, so nothing critical is missing for correct invocation.

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 89%, so the schema itself already documents nearly every parameter, giving a baseline of 3. The description usefully ties the parameter surface to a workflow (clip gain, fades, sends to aux busses, tempo, meter, key, markers) but adds no syntax, defaults, or constraints beyond what the schema already states.

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 names a specific verb and resource ('Build a song, podcast or soundtrack with SoundCraft... and mix it down') and enumerates the concrete artifacts it produces (mixdown, stems, MIDI, .scraft, LUFS report). It is clear what the tool does, but it never distinguishes itself from siblings like export_session (which also produces mixdowns) or edit_session, so an agent must infer the create-from-scratch scope.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. With siblings like edit_session, export_session, and run_soundcraft_commands available, the agent gets no rule for choosing this tool over them; the create-from-scratch scenario is only weakly implied by 'Build a song... and mix it down'.

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=false, destructiveHint=false and idempotentHint=false, and the description corroborates the key safety claim with a strong, explicit statement: "The original session is never changed." It also discloses that outputs are written (mixdown, stems, MIDI, new session copy), which is useful context beyond the flags. It omits the preview default-of-true and the confirmation/overwrite behavior, so it is helpful but not exhaustive.

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?

Front-loaded with the core action and followed by a one-sentence guarantee about the original session. The long middle sentence is dense but each clause maps to real capability, so little is wasted; it is only slightly list-heavy for a description.

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?

For a 20-parameter, deeply nested mutation tool with no output schema, the description covers the essential mental model: what gets modified, what gets produced, and that the input is preserved. Remaining details (preview, output_dir being required for new files, overwrite semantics) live in the well-covered schema, so nothing critical is missing.

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 90%, so the schema already documents nearly every parameter, including the default output formats and the name-based track addressing. The description's contribution is an inventory of the changeable categories (tempo, meter, key, markers, busses, tracks, outputs) rather than syntax or format detail, which is the expected baseline when the schema does the heavy lifting.

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?

States a specific verb (open/change/edit) and resource (a .scraft SoundCraft session) and then enumerates the full edit surface: tempo, meter, key, markers, busses, add/change/remove tracks, and output writing. This makes it unmistakably distinct from create_session (new session) and export_session (write-only) without needing to name them.

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?

Gives clear usage context – it applies to an existing session or to starting a project from audio files – and implies the edit-then-render workflow. It never states when to prefer a sibling such as export_session or process_audio, nor any exclusions, so it lands at clear-context-without-alternatives rather than full routing guidance.

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 a non-destructive write (readOnlyHint=false, destructiveHint=false), lowering the burden. The description usefully adds output composition, e.g. stems land in a <name>_stems folder and scraft copies audio into an 'Audio Files' folder, plus normalize-to--0.1 dBFS and LUFS reporting. It does not address overwrite semantics, permissions, or failure behavior, so it adds moderate context but not rich disclosure.

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?

A single front-loaded sentence led by the verb 'Mix down', with parentheticals and slashes packing detail efficiently and no filler. It is slightly dense to parse, but every clause contributes information and nothing is redundant with the title.

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?

With 12 parameters, no required fields, and no output schema, the description still conveys the modes, the output formats, and the return information (peak and LUFS of each mix). It leaves the input_path vs input_paths vs input_dir selection and the first-format-only output_path behavior to the schema, but overall it is adequate for the tool's complexity.

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 83%, so the schema documents most parameters (range, bit depth, normalize, overwrite, output_dir). The description echoes the key ones (range, normalize, bit depth, stems) without adding syntax or constraints beyond the schema, so the baseline of 3 applies.

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 names a specific verb ('mix down') and resource ('one .scraft session') and enumerates the three input modes (single session, list, folder) plus the concrete output types (wav/aiff/flac, stems, MIDI, LUFS reporting). It is clearly an export/render operation distinct from edit_session or create_session. It stops short of explicitly contrasting with convert_audio, which is the nearest ambiguous sibling, so it earns a 4 rather than 5.

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 three modes imply when each path parameter is relevant, but the description never states explicit when-to-use/when-not guidance or names an alternative (e.g., convert_audio for format-only changes). Usage is only inferable from the phrasing, matching the 'implied usage' level.

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, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description does add real behavioral context beyond the annotations — loudness=true "renders the audio once" (a cost side effect) and waveform=true returns a picture of only the first file — but omits batch behavior and the 200-item cap.

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?

Two dense sentences with no filler, front-loading the returned fields before the optional flags. Every clause carries information, though the first sentence is long enough to be slightly dense.

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?

With no output schema, the description has to carry the return-value burden, and it does list the field categories. However, it says nothing about how inputs are selected (dir vs path vs array) or the shape/nesting of the result, which an agent needs for a 5-parameter 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?

Schema coverage is only 40%, and the three undocumented parameters (input_dir, input_path, input_paths) are the ones that actually control what gets inspected — yet the description never explains the difference between them or what happens when the multiple-path array is used. The loudness/waveform explanations largely restate what the schema already documents.

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 names the concrete resource and the fields returned: format, channels, sample rate, bit depth, length for audio files, and tracks/clips/plugins/busses/markers/tempo for .scraft sessions. This clearly distinguishes it from siblings like get_soundcraft_status or list_soundcraft_catalog. It lacks an explicit verb ("get"/"inspect"), but the enumeration makes the capability unambiguous.

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?

It describes what the loudness and waveform flags do, which implies when to enable them, but never states when to prefer this tool over alternatives or what preconditions apply (e.g., must the file exist, does it need SoundCraft open?). No exclusions or sibling routing are given, so usage is only implied.

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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds one useful behavioral signal — that it reports whether the app is currently running and listening for control, i.e., live state rather than static config — but says nothing about behavior when SoundCraft is absent or the output shape.

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?

One sentence, front-loaded with the verb and resource, followed by a tight colon-delimited list of inspected facets. No filler, no restatement of the title.

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?

There is no output schema, but the description effectively enumerates what the response covers (platform, version, plugins, formats, running state), which largely substitutes for one. It falls short only on error/edge behavior, e.g., what is returned when SoundCraft is not installed.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the enumerated check list is informational rather than parameter guidance.

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?

States a specific verb ('Check') and resource ('SoundCraft installation') and then enumerates the exact facets inspected: platform, executables, version, engine commands, plugins, Pro Tools coverage, formats, and running/listening state. This is clearly distinguishable from siblings like list_soundcraft_catalog or run_soundcraft_commands, which act on content rather than installation health.

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?

Usage is implied rather than stated: an agent can infer this is the preflight/diagnostic call to make before run_soundcraft_commands or open_in_soundcraft, but the description never says when to use it or when to prefer a sibling. No exclusions or prerequisites are given.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing behavioral beyond content scope — no note on result size, caching, or whether the catalog is static. It is a passive static-data read, so little is needed, but the description itself contributes no extra behavioral context.

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?

A single sentence, front-loaded with the tool's overall purpose and then cleanly partitioned by kind. The nested parentheticals are dense and require careful reading, but every clause carries information — there is no filler to cut.

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?

For a two-parameter, closed-world, read-only catalog with no output schema, the description tells the agent what content each kind returns and which downstream tool consumes it. It omits only the concrete shape/size of the returned structure, which is a minor gap given the tool's simplicity.

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 only 50%; the 'kind' enum has no per-value description in the schema, and the description compensates by explaining what each of the four enum values actually yields and why it matters. That is genuine added meaning beyond the schema, though the 'filter' parameter is left entirely to the schema and no matching semantics are elaborated.

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?

Opens with 'What SoundCraft can do' and enumerates exactly what each of the four kinds returns (commands with parameters/menu place, plugins with parameter id/range/unit, drum note names, formats). An agent can tell it is a read-only catalog lookup distinct from the action siblings like run_soundcraft_commands or open_in_soundcraft. It never uses a crisp verb like 'List/Return', which keeps it from a 5.

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?

It implicitly gives usage by naming the consumers of each kind ('for run_soundcraft_commands', 'for `effects` and `instrument_params`'), which tells an agent why it would fetch a given kind. But it never states when to call this versus the sibling tools, whether it should be called before running commands, or when the filter is worth using. Usage is implied rather than instructed.

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?

Adds real behavioral context beyond annotations: opening launches a GUI, and control=true starts a loopback-only control channel (a security-relevant detail). Annotations already cover the safety profile (non-read-only, non-destructive, not idempotent), but the description doesn't say what happens if the app is already open or what the call returns.

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?

Two sentences, zero waste, front-loaded with the core action before the conditional control-channel detail. Nothing repeated from title or schema.

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?

No output schema exists, so the description should carry the burden of return behavior, and it does not state what the tool returns or what happens on failure/already-running app. Everything else an agent needs to invoke it correctly is present.

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 67% and the control parameter has no schema description at all; the description compensates by explaining exactly what control=true does (starts the control channel enabling live driving). demo and path already carry schema descriptions, so this is additive rather than duplicative.

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?

Specific verb+resource ('Open a .scraft session in the SoundCraft desktop app') with scope ('to listen and keep editing by hand'), clearly distinguishing it from create_session/edit_session siblings that manipulate sessions without launching the desktop app.

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?

Names the alternative explicitly and the condition that selects it: with control=true, run_soundcraft_commands live=true can drive the app. An agent can decide between this tool and run_soundcraft_commands without inference.

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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description usefully clarifies that 'Inputs are only read', which softens the readOnlyHint=false flag by telling the agent the source files are untouched. It stops short of explaining overwrite behavior, re-run/idempotency semantics, or failure handling for the many-file case.

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 core action is front-loaded, which is good, but the tool's identity is delivered as one very long sentence with two dense parenthetical catalogues of effects and formats. The plugin enumerations duplicate content already in the schema's plugin field, and breaking the pipeline into ordered steps would be far more scannable.

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?

For a 25-parameter tool with no output schema and 56% coverage, the description should do more. It conveys the overall pipeline shape but omits how outputs are named/located (suffix, output_dir vs output_path vs output_path), what happens with multiple inputs and multiple formats, and the default preview behavior, all of which an agent needs to call it correctly.

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 56% across 25 parameters, so the schema carries much but not all of the load. The description's capability list (trim, normalize, gain, reverse, invert, pitch shift, time stretch, varispeed, effects) maps loosely onto parameter names but adds no units, defaults, or interaction rules, so it only partially compensates for the undocumented half.

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?

States a specific verb (run files through SoundCraft) and enumerates the concrete capability set: trim, AudioSuite processing, insert effects, fades, volume/pan, and encoding to WAV/AIFF/FLAC. It reads as a full processing pipeline rather than a tautology. However it never names or contrasts with the nearest siblings (convert_audio, run_soundcraft_commands, edit_session), so an agent must infer the boundary itself.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named despite clear overlap with convert_audio and run_soundcraft_commands. The only routing hint is the implicit 'processor, not editor' framing, which the agent has to derive from the capability list.

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 destructiveHint=true and idempotentHint=false, and the description adds real behavior beyond that: sequential execution, live=true driving the open app vs a headless engine, and the guarantee that open_path is never saved over. It still does not explain overwrite or stop_on_error semantics, but the additions are substantive.

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?

A single dense paragraph, but it is front-loaded with the 'Advanced: run any ... in order' framing and nearly every clause carries non-obvious information. The malformed quoting around the bars_beats example and the run-on length keep it from a 5.

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?

For a 12-parameter, destructive, no-output-schema tool the description covers the hard parts (ordering, step references, positions, live mode, open_path safety) but omits error handling and overwrite behavior and leaves a third of the parameters unexplained. Adequate but with clear gaps.

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 33%, so the description must compensate, and it does for live, steps, and output writing by documenting the '$steps[N].field' chaining syntax and the position formats (samples, {"seconds": x}, bars_beats) that appear nowhere in the schema. Several parameters (bit_depth, normalize, overwrite, stop_on_error, sample_rate) remain undocumented in both places.

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?

States a specific verb and resource (run SoundCraft engine commands in order) and enumerates the command namespaces and engine-tool step ids, so the agent knows exactly what it executes. It does not, however, contrast itself against siblings like edit_session or process_audio, which overlap with the step ids it lists.

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 'Advanced:' prefix implies this is the heavyweight option and listing engine tools as steps hints at the relationship to siblings, but there is no explicit when-to-use / when-not or routing statement (e.g. 'prefer create_session for a simple new session'). Usage is only implied.

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