uad-console-mcp

by fomoPhil

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Every tool targets a distinct resource and action, and the 'Not for' sections explicitly disambiguate overlapping areas (e.g., uad_peek_meters vs uad_watch_meters, uad_get_plugin_params vs uad_set_plugin_params). No two tools appear to do the same thing; even closely related tools like uad_load_plugin and uad_plugin_preset have clear separation (loading vs preset recall).
Naming Consistency4/5
All tools share the uad_ prefix and most follow a verb_noun pattern (uad_list_channels, uad_set_preamp, uad_load_plugin). However, a few deviate: uad_raw_get is noun_verb instead of verb_noun, and uad_talkback, uad_safe_state, uad_plugin_preset, and uad_snapshot are single nouns or adjective_noun without an explicit verb. The deviations are minor and do not significantly hurt readability.
Tool Count4/5
With 21 tools, the server sits at the upper edge of the well-scoped range but is justified by the complexity of controlling a professional audio console. Each tool covers a meaningful aspect (status, channels, preamps, sends, monitor, safety, clock, plugins, meters, snapshots), and there is no redundancy. It feels slightly heavy but not overwhelming for the domain.
Completeness4/5
The tool surface covers core console operations comprehensively: channel control, preamp, sends, monitor, talkback, safety, clock, sample rate, plugin management, parameter adjustment, and metering. Obvious gaps like headphone output level and console session management are explicitly acknowledged as limitations, and the snapshot system compensates for state management. Minor missing operations (e.g., explicit routing beyond sends) are workarounds.
Average 4.4/5 across 21 of 21 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation but does not disclose key behavioral traits such as the effect of the 'loaded_only' parameter (which defaults to true and likely filters to only loaded slots, contradicting the claim of showing 'every insert slot'). It also omits information about permissions, side effects, or output formatting, and no annotations are provided to compensate.
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 concise and well-structured: two sentences that front-load the purpose and then provide usage guidelines with clear 'Use when' and 'Not for' sections. It is easy to parse and free of unnecessary words, though slightly more detail on parameters would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no schema descriptions, and no annotations, the description should provide substantial guidance. While it gives a general sense of the tool's purpose and usage, it omits crucial details about parameter behavior and output interpretation, making it incomplete for reliable invocation.
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 descriptions are completely absent (0% coverage), and the description adds only a vague hint about selecting 'one channel or all of them'. It does not explain the individual parameters (kind, device, target, loaded_only), leaving the agent without sufficient information to correctly populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Show') and resource ('insert slots' plus 'Unison slot'), and details the output content (plugin name, power state, preset). It explicitly distinguishes itself from the sibling tool uad_get_plugin_params by stating it is 'Not for parameter values inside a plugin'.
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?
The description provides explicit use cases ('Use when: auditing a channel's processing chain or finding a free slot') and a clear exclusion with an alternative tool ('Not for: parameter values inside a plugin - use uad_get_plugin_params'). This gives the agent strong guidance on when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals a key constraint: the tool only works on loaded plugins and empty slots are invalid. It also clarifies that this is a read/list operation, implying no mutation, and describes the kind of output to expect.
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?
Three concise sentences, front-loaded with the main purpose and followed by usage guidance. There is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the purpose and usage are clear and an output schema exists, the tool has three parameters (all undocumented) and no annotations. The description does not sufficiently explain how to identify the target plugin, leaving a critical gap for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate, but it provides no meaning for the parameters slot, device, or target. The required 'target' parameter is not explained at all, making it impossible for an agent to know what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('a loaded plugin's parameters'), and specifies what is returned (names, normalized 0-1 values, display text). This distinguishes it from sibling tools like uad_set_plugin_params or uad_get_status.
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?
Explicitly provides 'Use when' scenarios and a 'Not for' exclusion with a rationale (parameter nodes only exist once a plugin is loaded). This gives clear context for when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It uses the verb 'List' and mentions 'see the current mix state before changing it,' implying a read-only snapshot. It also discloses that results are grouped by device. However, it does not explicitly state 'read-only' or discuss any potential side effects, though the word 'list' and context make this safe.
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 three focused sentences: the first states the core action, the second gives usage intent, and the third lists exclusions. Every sentence adds value, and it is front-loaded with the most important information.
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?
For a simple list tool with an output schema, the description covers purpose, use cases, and exclusions well. However, it completely omits parameter semantics, and the output schema is not described in the text. Given the 0% schema coverage and the need to understand kind and device filters, the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (kind, device, include_hidden). It mentions 'hidden' as a field in the output, but does not connect it to the include_hidden parameter. The defaults exist, but without parameter documentation the agent cannot make informed choices about values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List every strip across every unit, grouped by device, with name, I/O type, fader, mute, solo, pan, hidden and stereo link.' This is a specific verb+resource+scope, and the 'Not for' clause explicitly distinguishes it from sibling tools like uad_peek_meters and uad_get_inserts.
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?
The description provides explicit usage guidance: 'Use when: you need to find a channel by name, or to see the current mix state before changing it.' It also names alternatives with 'Not for: meter levels (uad_peek_meters) or plugin contents (uad_get_inserts),' making it clear when to prefer other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses key behavioral details: polling up to 5 seconds, waiting for parameter nodes to materialize, and reporting whether they did. It also reveals the optional preset recall. Some side effects like power management are not mentioned, but the core behavior is transparent enough.
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 three sentences, front-loaded with the primary action, and every sentence adds value. No redundant or vague filler.
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 provides solid purpose, usage, and behavioral context, and an output schema exists for return values. However, with no annotations and zero schema descriptions, the unexplained target/device/power parameters leave notable gaps 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate. It explains slot values and preset usage, but leaves target, device, and power undefined. These are significant gaps for a 6-parameter tool with only 2 inferred parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: loading a UAD plugin into an insert slot or the Unison preamp slot, followed by polling for parameter nodes. It also distinguishes itself from sibling tools by explicitly mentioning what it is not for.
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?
Provides explicit 'Use when' guidance and names sibling alternatives for excluded use cases (uad_set_plugin_params, uad_remove_plugin). This is model guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it reveals the write operation, the empty EffectName mechanism, and the report behavior. It also clarifies what it does NOT do (bypass). Some side effects like DSP release specifics or Unison preamp behavior are not mentioned, but the core behavior is transparent.
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 three sentences, front-loaded with the action and mechanism, and wastes no words. Each sentence adds value: what it does, when to use it, and when not to use it.
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?
Purpose, usage, and behavioral transparency are strong, and an output schema exists for return values. However, parameter semantics are weak due to 0% schema coverage and no description of target/device. Overall, it is adequate but incomplete for a 3-parameter tool without annotations.
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 0%, and the description fails to define the required 'target' parameter or the optional 'device' parameter. It only implicitly references 'slot' as an insert/Unison slot. This is a significant gap for a tool with three parameters, especially since 'target' is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear an insert or Unison slot'), the mechanism ('by writing an empty EffectName'), and the result ('report what was removed'). This distinguishes it from sibling tools like uad_load_plugin, which loads rather than removes.
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?
Explicit 'Use when' and 'Not for' guidance is provided, including a concrete alternative: set Power via uad_load_plugin(power=false) when bypassing is intended. This leaves no ambiguity about when to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses that this is a batch-set operation and notes a protocol limitation, but it does not explain side effects such as whether existing send levels are overwritten, how errors in a batch are handled, or whether changes are reversible.
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 only three sentences and front-loads the core action, then gives the item shape, then usage guidance. Every sentence adds value and there is no fluff.
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?
An output schema exists, so return-value documentation is not necessary. The description covers the input item shape, typical use cases, and an important limitation. It lacks details on target semantics and error scenarios, but is generally sufficient for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the minimal input schema. It does so by outlining the item structure: {target, send: 'aux1' | 'cue1'... or index, device?, level_db?, pan?, bypass?}. This is helpful, though some nested fields like 'target' and 'device' remain underdefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Batch-set send levels into aux and cue buses', which is a specific verb+resource statement. It clearly distinguishes this from sibling tools like uad_set_channels or uad_set_monitor by focusing on send buses.
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?
Explicit 'Use when:' and 'Not for:' sections provide clear context and a specific exclusion (headphone output level). However, it does not name a sibling alternative tool for that excluded case, instead pointing to 'uad://limitations'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral details: the polling is capped at 30 seconds, it returns as soon as any watched channel exceeds the threshold (early exit behavior), and it reports per-channel peaks. It also states the design intent behind the cap. It doesn't mention side effects, but since this is a read-only meter poll, that's acceptable.
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 only three sentences, with the core action front-loaded. Every sentence adds value: the first defines what it does, the second gives usage cases, the third states the key limitation. No filler or repetition.
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 (so return values are covered there) and six optional parameters. The description fully covers the tool's purpose, usage, and design constraint (30s cap). It could have mentioned that it's a blocking call or how it handles no threshold breach, but the overall context is strong enough for an agent to understand when and how to invoke it.
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 0%, so the description must compensate. It explicitly names duration_s, threshold_db, and implies 'targets' via 'watched channel'. However, it does not explain device, kind, or interval_s. Given all parameters are optional with defaults, the partial compensation is moderate, but still leaves room for ambiguity on the unmentioned parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('poll'), the resource ('meters'), and the exact behavior (poll for up to duration_s, return when any watched channel exceeds threshold_db, report per-channel peaks). It distinguishes itself from sibling tools like uad_peek_meters by emphasizing the 'watch' behavior and the 30-second cap, which is not mentioned for other meter-related tools.
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 provides explicit 'Use when' and 'Not for' sections, listing concrete scenarios (verifying a live source, setting gain, hunting intermittent signals) and explicitly excluding long-term monitoring. However, it does not name an alternative sibling tool (e.g., uad_peek_meters) for the excluded case, so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'List' implies a read-only operation, and it adds useful behavioral context: 'Filterable and limited by default.' It does not explicitly state non-modifying behavior or connection requirements, but for a catalog listing tool these are largely entailed.
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 extremely concise and well-structured: it opens with the action and purpose, then provides usage guidance and an explicit exclusion. Every sentence adds value with no redundancy.
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 description covers the tool's purpose, output content, filtering behavior, and typical use cases, and it distinguishes the tool from its closest sibling. Because an output schema exists, detailed return values are not necessary. A minor gap is the lack of explanation about how filtering parameters interact, but overall this is adequate.
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 0%, and the description does not explain the five parameters (limit, search, category, unison_only, authorized_only) beyond the generic statement 'Filterable and limited by default.' The parameter names are somewhat intuitive, but the description does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the installed UAD plugin catalog with specific output fields (name, categories, Unison capability, authorization status). It also explicitly distinguishes itself from uad_get_inserts, which lists currently loaded plugins.
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?
The description gives explicit use cases: 'Use when: choosing a plugin to load, or checking whether one is authorized.' It also names a specific exclusion: 'Not for: what is currently loaded on channels - that is uad_get_inserts.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral details. It discloses mutation via 'Recall', requires a 'loaded plugin slot', notes conditional validation ('when the engine lists it'), and states a scope limitation ('does not manage' channel-strip/Console session presets). However, it does not explain whether the current parameter state is overwritten or reversible, which keeps it from a 5.
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 two focused sentences: the first states exactly what the tool does, the second gives clear when/not-for guidance. No wasted words and no repetition of schema details.
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 description covers purpose, when to use, and explicit non-goals, which is strong for a preset-recall tool. It relies on the output schema for return details and on `uad://limitations` for broader constraints, but the under-specified parameter relationships (target/slot/device) keep it from a 5.
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 0%, so the description must compensate. It identifies 'preset by name' and 'loaded plugin slot', but does not explain the relationships among `target`, `slot`, and `device`, nor their accepted forms. Required parameters are not individually described, leaving ambiguity for a 4-param schema with defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Recall' with a clear resource: 'a preset by name into a loaded plugin slot'. It also adds a distinguishing detail about validation against the plugin's preset browser, separating it from parameter-setting or plugin-loading siblings.
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?
Explicit 'Use when' clause gives a clear trigger: 'a named factory or user preset is a faster starting point than setting parameters.' The 'Not for' clause excludes channel-strip/Console session presets and references a limitations doc, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states the tool is read-only, returns data verbatim, includes metadata, and that writing is separated. It lacks details on path syntax or error behavior, but the core read-only nature is transparent.
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 three short sentences with no filler. It front-loads the core purpose, then gives usage context, and ends with an important exclusion. Every sentence earns its place.
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?
For a simple 1-parameter tool with an output schema, the description covers purpose, use cases, and write separation. Minor gaps such as exact path format and what 'full mode' means are not fatal, but a bit more detail on path handling would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'path' parameter, but the description compensates by explaining that the path addresses a node or property in the engine tree and can be used to confirm type/range/enum values. It does not specify path format, but the semantic meaning is clearly conveyed.
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 the tool reads any node or property in the engine tree verbatim with metadata, which is a specific verb and resource. It also differentiates from writing tools by explicitly noting it is not for writing, though it does not name sibling tools explicitly.
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?
The description provides explicit 'Use when' and 'Not for' guidance: use when no other tool covers a need or to confirm types/ranges/enums, and avoid for writing. It clearly indicates that writing is deliberately separate and only available in full mode, giving strong usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It reveals that this is a one-shot read (single sample, no polling) and that at-floor channels are explicitly flagged. While edge cases like invalid targets aren't covered, the key behavioral traits are clear for a read-only tool.
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 extremely concise: two sentences, front-loaded with the core function, then usage guidance and exclusions. No redundant words.
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?
With an output schema present, return value details are unnecessary. The description covers purpose, usage context, alternatives, and basic scope. The only gap is explicit parameter semantics, but that is partially covered in parameter_semantics. Overall, sufficient for an agent to decide when to use it.
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 0%, so the description should compensate. It implicitly maps 'named subset' to the targets parameter and 'at-floor' to the above_db threshold, but does not explicitly explain the device or kind parameters. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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: 'One-shot meter read (level, peak, clip) for all channels or a named subset'. It clearly distinguishes from sibling tools, especially by naming uad_watch_meters as the alternative for polling.
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?
The description provides explicit 'Use when' conditions (checking signal arrival or hot channel) and a 'Not for' exclusion with a named alternative (uad_watch_meters), making selection and invocation guidance clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that values must be normalized 0-1, that the protocol exposes only normalized values, and that display text is read-only. It implies mutation (setting parameters) but does not elaborate on side effects, idempotency, or error behavior. Still, it adds meaningful behavioral context beyond the schema.
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 three sentences, all relevant and useful. The purpose statement includes an example, the second sentence gives a clear when-to-use and prerequisite, and the third states an important limitation. No fluff, tight structure.
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?
Given the tool has four parameters, no schema descriptions, and no annotations, the description covers the core usage well: what it does, how to format params, and when to use it. It does not explain the 'target', 'slot', and 'device' parameters in detail, nor does it describe error handling, but the output schema covers return values and the recommendation to read uad_get_plugin_params fills potential gaps. Overall, fairly complete for the tool's 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 0%, so the description must compensate. It fully explains the 'params' parameter with an inline example and clarifies normalized value semantics, but it leaves 'target', 'slot', and 'device' mostly unexplained. The titles give some hint, but the description does not specify what 'target' refers to (e.g., plugin name, instance ID) or the role of slot/device. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: batch-setting a loaded plugin's parameters by name. It uses a concrete verb 'Batch-set' and a distinct resource ('loaded plugin's parameters'), and it differentiates itself from sibling tools like uad_get_plugin_params by focusing on mutation rather than reading.
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?
The description provides explicit when-to-use guidance: 'Use when: dialling in a plugin after loading it.' It also recommends reading uad_get_plugin_params first for exact names and current values, and it states what the tool is not for (dB/Hz values), clarifying the normalized-only constraint. This is exemplary usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It warns that 48V phantom power can destroy ribbon microphones and requires confirm_condenser_mic=true, and notes digital inputs have no preamp. However, it does not mention that unset parameters are left unchanged or describe the immediate effect on the device.
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 compact and front-loaded: three sentences cover the function, usage conditions, safety warning, and exclusions with no repetition of schema fields or filler.
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 output schema covers return values, so the description can focus on context. It includes the has_preamp prerequisite, the safety concern, and alternatives. It could add a note about null parameters meaning 'no change,' 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It names most controls (gain_db, pad, low_cut, phase, hi_z, source, phantom_48v) and clarifies source values ('Mic'/'Line') plus the confirm_condenser_mic requirement. But it omits target/device semantics and gain_db units/range, leaving meaningful gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Set preamp controls on one mic/line input') and enumerates the relevant fields, making it clear this is a preamp-focused tool. It also explicitly differentiates from uad_set_channels fader_db, distinguishing it from a sibling.
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 provides a direct 'Use when' condition (setting recording gain/input options when has_preamp is true) and a 'Not for' exclusion (fader level and digital inputs), explicitly naming the alternative sibling uad_set_channels for fader adjustments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses that confirm=true is required, that the tool refuses while audio is flowing, and explains the consequence (streams glitch), which provides meaningful behavioral context beyond a basic mutation.
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?
Three short sentences with front-loaded purpose, clear use cases, and no fluff. Each sentence serves a distinct role.
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?
For a simple setter with two parameters and an output schema, the description adequately covers purpose, usage, and critical behavior. It lacks only explicit details on return values and edge cases like invalid rates, which are minor for this tool.
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?
The input schema has zero descriptions, but the description adds value by specifying confirm must be true and giving rate examples. However, it does not fully enumerate valid rate values or explain failure behavior if confirm is false, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Change the system sample rate,' a specific verb+resource statement. It includes examples and explicitly differentiates from clock source troubleshooting via 'Not for: fixing a lock failure...' making it distinct from uad_set_clock and uad_get_status.
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?
The 'Use when' and 'Not for' lines provide explicit conditions for appropriate use, including a named alternative (uad_get_status) for a different scenario, meeting the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: explains each action's effect, safe restore ordering, dry_run default and return behavior, automatic pre-restore snapshot capture, and scope limitations. This goes well beyond what the schema alone provides.
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 compact and front-loaded, with the core mechanics in the first two sentences and usage guidance in the second paragraph. Every sentence conveys meaningful information with no redundancy.
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 complex multi-action tool with no annotations and minimal schema guidance, the description is remarkably complete: action modes, scope, safety behavior, use cases, and exclusions are all covered. The output schema exists to handle return-value details, and the description appropriately focuses on behavior.
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 0%, so the description must compensate. It does explain action, ignore glob patterns, and dry_run semantics, but leaves name, include_clock, include_monitor, and allow_cross_model to be inferred from their names. This is a notable gap given seven parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a multi-action snapshot tool for whole-rig state, detailing save/list/diff/restore. It distinguishes itself from sibling tools that target individual settings by focusing on comprehensive snapshots.
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?
Provides explicit use cases ('saving a session state before experimenting, seeing what drifted, or putting a known-good state back') and clear exclusions ('Not for: Console sessions or plugin scenes'). It does not name alternative sibling tools, but the when/when-not guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description transparently discloses important behavior: level_db is 'hard-railed', operations like unmuting/un-dimming/lowering dim_attenuation_db are treated as level events that can be refused, and level_db is written before the release is railed against the engine-reported level. This goes well beyond basic safety hints and helps the agent predict consequences.
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 packed into three scannable sentences, front-loading the primary action and parameters, followed by causal constraints and clear usage boundaries. Every sentence serves a distinct purpose with no filler or repetition.
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 7 optional parameters and an output schema, yet no annotations. The description covers purpose, usage, and critical behavioral quirks, but it leaves the 'device' parameter unmentioned and does not describe output semantics beyond relying on the output schema. This is a minor gap in an otherwise rich description.
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?
The input schema has 0% description coverage, so the description must compensate. It names most parameters and adds meaningful context (e.g., 'level_db (hard-railed)'), but it omits the 'device' parameter entirely and does not clarify value formats or ranges for alt_speaker or dim_attenuation_db. Thus the description is helpful but not fully compensatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set the control-room monitor' and enumerates the exact attributes (level_db, dim, mute, mono fold, alt speaker selection, dim attenuation), making the tool's purpose specific and distinct. The 'Not for: headphone level' clause further disambiguates it from monitoring-related sibling tools.
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 provides explicit when-to-use guidance: 'Use when: changing what the control room hears, or recovering after uad_safe_state.' It also explicitly states when not to use it ('Not for: headphone level') and points to uad://limitations as an alternative reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the auto-off timer default of 30 seconds and that 'Calling it again replaces the timer.' This is useful behavioral context beyond simple on/off. However, it doesn't mention the return value or any other side effects, which would make it fully transparent.
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 concise and well-structured: an opening sentence with core behavior and timer safety, followed by clear 'Use when' and 'Not for' sections. Every sentence adds value without repetition or fluff.
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 is simple with three optional parameters and an output schema. The description covers purpose, usage, exclusions, and parameter semantics. It lacks edge-case details (e.g., what happens when 'on' is null, or level ranges), but these are not essential for a basic invocation, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining the semantic meaning of each parameter: 'on' maps to 'Turn talkback on or off', 'level' to 'set its level', and 'auto_off_s' to the auto-off timer. It doesn't specify units or valid ranges for level, but the functional purpose is clear enough for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Turn talkback on or off and set its level, with an auto-off timer.' It also distinguishes the tool from routing tasks by explicitly saying 'Not for: routing the talkback mic or choosing which mic it is - that is set in Console.' This sets it apart from sibling tools like uad_set_sends.
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?
Provides explicit guidance: 'Use when: the engineer needs to speak to the live room.' and 'Not for: routing the talkback mic or choosing which mic it is.' This clearly outlines when to use and when not to use, with an alternative context ('set in Console').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing safety and side effects. 'Report' implies a non-destructive read operation, and the 'before any write' usage hint reinforces this. However, it does not explicitly state that no state changes occur or describe any potential error conditions, so it falls slightly short of full transparency.
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 three sentences with a clear structure: what it does, when to use it, and when not to use it. Each sentence serves a distinct purpose, and the information is front-loaded. There is no redundancy or filler.
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?
Given that there are no parameters and an output schema exists, the description need not explain return values. It covers the essential context: the tool's purpose, appropriate use cases, and exclusions. It is fully complete for a status-reporting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100% and the description need not explain parameters. The baseline for zero-parameter tools is 4, and the description does not attempt to add parameter-related meaning, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Report' followed by a specific list of resources (engine, clock, sample rate, DSP load, Apollo cascade, safety limits), clearly stating the tool's function. It also distinguishes from siblings by explicitly noting what it is not for, such as channel levels or meters, and directs to uad_list_channels and uad_peek_meters.
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?
Explicit 'Use when' and 'Not for' sections provide clear guidance on when to invoke this tool and when to use alternatives, naming specific sibling tools. This exceeds basic context and directly addresses the decision boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses the key behavior (muting all monitor outputs, turning off talkback) and, importantly, that it 'takes no arguments and needs no confirmation,' which sets expectations about immediacy and irreversibility. It doesn't mention return values or side effects beyond the audio state, but the stated behavior is unambiguous for a panic action.
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?
Three short sentences: the first defines the action, the second gives usage context, the third names an alternative for a different use case. Every sentence is purposeful and information-dense. The 'Panic button' label front-loads the intent.
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?
The tool is simple (no parameters, no nested objects). The description covers purpose, usage, and exclusions. It also provides a fallback alternative. Given the low complexity and presence of an output schema, no further detail is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description's assertion 'takes no arguments' adds value by confirming the schema's empty properties. Per the rubric, 0 params yields a baseline 4, and this description explicitly reinforces that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Panic button' and immediately defines the action: 'mute every monitor output and turn talkback off.' This is a specific verb-resource-scope statement that clearly differentiates it from siblings like uad_set_channels and uad_talkback.
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?
Provides explicit when-to-use ('there is feedback, a runaway level, or anything unexpectedly loud'), sequencing advice ('Call it first and diagnose afterwards'), and a clear when-not-to-use with an alternative tool ('normal muting of a single channel - use uad_set_channels').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It goes beyond a simple mutation statement by revealing that every item reports resolved device/index/name and per-property verified/before/after/warnings, giving the agent insight into response format and verification behavior. However, it does not mention persistence, undo, or authorization requirements, leaving some gaps in transparency.
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 concise and well-structured: it leads with the purpose, then provides the item format in a compact notation, and ends with use/not-for guidance. Every sentence contributes valuable information without fluff or repetition of schema fields, achieving high information density.
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?
Given the tool's complexity (many optional properties, batch operation, and no annotations), the description covers input format, return reporting, usage scenarios, and exclusions thoroughly. An output schema is present for return values, so the description doesn't need to explain every field; it provides the contextual information the agent needs to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is minimal (just an 'items' array with additionalProperties true), so the description provides the essential parameter semantics. It enumerates all supported property keys with types and optionality markers (e.g., 'target: name or index', 'device?', 'fader_db?'), and explains the return structure. This is a substantial addition beyond the schema, making the tool usable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Batch-set channel state' with a specific verb and resource, and enumerates the exact properties it can modify (faders, mutes, solos, pans, names, visibility). It also explicitly distinguishes itself from sibling tools by listing what it is NOT for (uad_set_monitor, uad_set_preamp, uad_set_sends), providing strong differentiation.
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?
The description gives explicit 'Use when' guidance for changing multiple channel properties at once, and clear 'Not for' exclusions that name alternative tools and their targets. This tells the agent exactly when to select this tool versus alternatives, exceeding the minimum bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description fully discloses critical behaviors: it verifies ClockLocked after changing, automatically reverts if the new source doesn't lock, requires confirm=true, and refuses while audio is flowing. This exceeds the typical level of behavioral detail and prepares the agent for side effects and safety conditions.
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 four concise sentences, front-loaded with the core action, then covering usage context, requirements, and exclusions. Every sentence adds meaningful information with no redundancy or filler.
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?
Given the tool's moderate complexity (2 params, output schema present), the description covers the operation, prerequisites, failure recovery behavior, use cases, and alternatives. The presence of an output schema means return-value details aren't needed, and the description is complete for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no description coverage and no enums on parameters, but the description compensates fully: it lists valid values for 'source' and explicitly states that 'confirm' must be true for the operation to proceed. This adds actionable semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Change') with a clear resource ('clock source'), and enumerates the exact selectable sources (Internal, Word Clock, ADAT, S/PDIF). It explicitly distinguishes itself from the sibling uad_set_sample_rate, making the tool's purpose unambiguous.
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?
The description provides explicit 'Use when' scenarios (slaving to/from external gear, recovering from unlocked clock) and a 'Not for' exclusion that names the correct alternative tool (uad_set_sample_rate). This gives clear guidance for when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![uad-console-mcp MCP server](https://glama.ai/mcp/servers/fomoPhil/uad-console-mcp/badges/card.svg)](https://glama.ai/mcp/servers/fomoPhil/uad-console-mcp)

Score Badge

Copy to your README.md:

[![uad-console-mcp MCP server](https://glama.ai/mcp/servers/fomoPhil/uad-console-mcp/badges/score.svg)](https://glama.ai/mcp/servers/fomoPhil/uad-console-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fomoPhil/uad-console-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server