Set input audio

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

The description states the effect (changing mute/volume), consistent with annotations indicating a write operation (readOnlyHint=false). It does not add context about partial update behavior (whether unspecified parameters are left unchanged), the distinction between volumeDb and volumeMul, or any side effects. Annotations cover basic safety, so the description's contribution is limited but not contradictory.

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

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

The description is a single, direct sentence that immediately conveys the core functionality. It is front-loaded with the action and resource, with zero unnecessary words or repetition. This is exemplary conciseness.

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 tool with 5 optional parameters and no required fields, the description is too minimal. It does not mention that either inputId or inputName must be provided to identify the target, nor does it clarify how mute and volume interact when both are set. The output schema exists but does not replace critical usage context like partial updates. This leaves significant gaps for an agent.

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

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

Schema description coverage is only 40% (inputId and inputName have descriptions; muted, volumeDb, volumeMul do not). The description does not compensate by explaining these parameters—it mentions 'mute' and 'volume' generically without mapping them to specific schema fields or clarifying units. Agents receive insufficient guidance on parameter selection.

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

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

The description clearly states the action (set) and the resource (mute and/or volume for an OBS input), making the purpose evident. It distinguishes itself from generic input_settings_set and mixer-level audio_mixer_set by focusing specifically on input audio properties, though it doesn't name these siblings explicitly.

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 usage is implied: use this tool when you need to adjust mute or volume on an input. However, it offers no explicit when-to-use vs. when-not-to-use guidance, nor does it mention alternatives like input_audio_get for reading or audio_mixer_set for mixer channels. This leaves the routing decision to inference.

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