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

No annotations are provided, so the description carries the transparency burden. It discloses the get/set nature and volume unit semantics (0 dB unity, -100 silence), but does not describe return values, side effects, or behavior when both optional parameters are omitted. This is adequate but not rich.

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 short sentences, front-loaded with the core action and followed by a necessary unit clarification. No filler or redundancy.

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 simple 3-parameter tool with no output schema, the description covers the core behavior and parameter semantics sufficiently for an agent to select and invoke it. It lacks explicit return-value documentation, but the 'get' half of the description and the schema's 'omit to leave unchanged' hints make the query behavior inferable.

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 description adds meaning beyond the schema by explaining that volumeDb is in dB with 0 as unity and -100 as silence; the schema only provides the numeric range. It also maps 'mute state' and 'volume' to the muted and volumeDb properties, though inputName is left implicit as the audio input identifier.

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 uses 'Get or set' with a clear resource ('audio input') and attributes ('mute state and volume'), making the tool's function immediately identifiable. It also distinguishes from siblings like obs_audio_routing and obs_set_input_settings by focusing specifically on mute/volume control.

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 implies usage for controlling an audio input's mute and volume but provides no explicit guidance on when to prefer this over siblings such as obs_get_input_settings or obs_set_input_settings, nor any exclusions. The context is inferable from the purpose, so it meets the 'implied usage' level but not higher.

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?

With no annotations, the description carries full behavioral burden. It discloses several traps: syncOffsetMs silently ignored beyond ~960ms, sources on unconnected tracks may not meter, monitorType can cause audio feedback, and the reply always reflects OBS state after the write with a 'notes' list. This exceeds typical disclosure and prepares the agent for edge cases.

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 lengthy but well-structured: it begins with the core read/write distinction, then lists traps in a numbered list. Each sentence adds value, though some repetition could be trimmed. The front-loading of the purpose and the clear trap enumeration make it efficient for an agent.

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?

Despite having no output schema, the description clearly explains the return (post-write state plus notes). It covers all aspects: how to read vs. change, parameter semantics, traps, side effects, and relationships to siblings. For a tool with nested objects and 5 parameters, this is complete and self-contained.

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 already covers 100% of parameters with descriptions, so baseline is 3. The description adds semantic value beyond the schema: it explains that omission means unchanged, clarifies the syncOffsetMs trap and effective range, and reinforces the meaning of balance values. It does not repeat schema text verbatim but augments it, earning a 4.

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 it reads and optionally changes where an audio input goes (tracks, monitoring, sync, balance), with a specific verb ('Read - and optionally change') and resource (audio input routing). It also distinguishes from siblings like obs_audio_control (mute/volume) and obs_audio_routing_map (likely a read-only map), making the purpose 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?

Explicit guidance: 'Call it with only inputName to read; every other field is a change.' It contrasts with mute/volume tools, explains when to use it vs. alternatives, and warns against 'fixing' sources intentionally excluded from tracks. Also notes that monitorType should be NONE to avoid feedback, giving specific do's and don'ts.

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?

With no annotations provided, the description carries full behavioral burden and succeeds: it states 'Read-only', lists specific failure classes it detects, notes that no-audio inputs are skipped rather than flagged, and describes edge cases like sync offsets past ~960 ms. This is far beyond a generic read-only label.

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 longer than usual but every clause earns its place; it front-loads the core purpose and then details failure modes. Minor redundancy between 'explicit list of what is misrouted' and the subsequent list of failures, but overall it is well-structured and readable.

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?

Despite no output schema and no annotations, the description tells the agent what the tool returns, which input categories are included, which are skipped, the specific misrouting conditions detected, and when to prefer it over alternatives. This is unusually complete for a diagnostic 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?

The input schema already covers the only parameter (onlyProblems) with a clear description and default. The tool description adds no parameter-specific semantics beyond the schema, so the baseline score 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 states a specific, valuable function: 'The whole audio routing picture in one call' with explicit outputs (tracks, monitoring, sync offset, balance, misrouted list). It also clearly differentiates from alternatives by framing this as the aggregate diagnostic versus per-input requests.

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 gives explicit when-to-use guidance: 'Start here when audio is wrong and you do not yet know which source is at fault.' It also names the alternative ('four requests per input') and explains why this tool is preferred for comparison-driven diagnosis, making the usage context clear.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It correctly implies a mutating action (create) and gives useful examples of input kinds, but it does not mention potential side effects, prerequisites (e.g., scene must exist), or the fact that inputSettings might be required for certain kinds. It does not contradict annotations since none are provided.

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, concise sentence that front-loads the core purpose and then lists common examples. It is efficient and without fluff, though it could be slightly longer to cover parameter semantics without becoming verbose.

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?

Given the tool's complexity (4 params, nested objects, no output schema, no annotations), the description provides essential guidance on inputKind but lacks details about inputSettings, required fields per kind, potential errors, or the result of the operation. It is adequate for a basic understanding but incomplete for advanced usage.

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 input schema provides only names and types for the 4 parameters, and the description does not explicitly describe the parameters. However, it does explain the possible values for inputKind, which is a key parameter. It does not explain the meaning of sceneName, inputName, or inputSettings beyond what the schema showsable. Since schema coverage is 0%, the description should compensate more but only partially does.

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 purpose: 'Create a new source in a scene' and provides a comprehensive list of common input kinds with their use cases. This distinguishes it from siblings like obs_create_scene (which creates scenes) and obs_remove_input (which removes inputs).

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 implicitly indicates when to use this tool: when you need to create a new source in a scene. It provides a list of common input kinds, guiding selection of the inputKind parameter. However, it does not explicitly state when NOT to use it or mention alternatives for modifying or removing sources, though siblings like obs_set_input_settings and obs_remove_input exist.

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?

With no annotations, the description carries full responsibility. It discloses that the scene is not switched to, that it is literally empty (no background, audio, or inheritance), and that renaming later has external consequences. These are key behavioral traits that the user must know, and they are all explicitly stated.

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 longer than necessary, but every sentence adds value—addressing behavior, usage, naming, and side effects. It is well-structured and front-loads the core purpose, then elaborates on important nuances. Slightly verbose but not wasteful.

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?

Given the tool's simplicity and the absence of an output schema, the description covers all essential aspects: the action, non-actions, side effects, naming implications, and subsequent steps. It leaves no critical gaps for the user's decision-making.

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 single parameter 'sceneName' is described simply as 'Name for the new scene,' but the description goes further by explaining uniqueness and its role as an address for other tools. This adds meaningful context beyond the schema's basic type and description, enriching the user's understanding.

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?

Clearly states the action: 'Create a new empty scene.' It specifies the resource (scene) and the nature (empty, new), and distinguishes from related tools like obs_switch_scene by explicitly noting it does not switch. The verb is specific and the scope is 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?

Provides explicit guidance on when to use the tool: 'Build it first with obs_scene_item_add, then switch.' It also cautions about safety ('safe while live') and naming implications, effectively directing users to the appropriate workflow and alternatives.

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?

With no annotations to fall back on, the description must fully carry the behavioral burden, and it succeeds admirably. It discloses the critical partial-settings gotcha (only non-default values returned), explains that an empty object means 'running on defaults' not 'broken', points to obs_filter_kinds for full parameter defaults, and clarifies the ordering semantics ('lowest index first... order audio and video actually flow'). This is exactly the nuanced behavioral context an agent needs to interpret results correctly.

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 dense, with roughly 130 words carrying significant non-obvious information. It front-loads the core action before the critical partial-object caveat. The all-caps 'THE SETTINGS OBJECT IS PARTIAL' is strident but arguably earned given it's the single most important trap to avoid. No wasted sentences; everything earns its place, though it could be slightly tightened.

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 read-only tool with 2 parameters, no output schema, and no annotations, the description covers the essential ground: what it returns, the partial-object semantics, the ordering, and cross-reference to a sibling tool for deeper discovery. Minor gaps like error behavior (e.g., nonexistent filterName) and the exact response key structure are not addressed, but for the tool's complexity level, the provided context is sufficient for an agent to use 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 coverage is 100% for the 2 parameters, establishing a baseline of 3. The description adds value by explicitly instructing 'Omit filterName for the whole chain,' which clarifies the optional parameter's behavioral consequence beyond the schema's basic 'Optional:' prefix. It could go further by describing the shape of the response when a single filter is requested, but for just two parameters the marginal value is sufficient.

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 leads with a specific verb+resource pairing: 'Read the filter chain on a source, or one filter in full detail.' It clearly distinguishes the two modes of operation (whole chain vs. single filter) and differentiates from siblings implicitly by noting that other filter tools address filters by exact name, implying this one retrieves them. The scope ('on a source') and the filtering by 'filterName' are explicit.

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 gives explicit when-to-use instruction: 'Do this before changing anything.' It justifies importance by explaining that sibling filter tools require exact names, implying this is the discovery/read step in a read-modify-write workflow. It could list alternative sibling names directly, but the guidance is specific and actionable without them.

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?

With no annotations, the description carries the full transparency burden and excels: it explains the plugin/DLL dependency, the misleading invalid-kind error, the v2 vs legacy kind strings, and the empty-object meaning for defaults.

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 front-loaded and organized into three digestible paragraphs: core function, plugin-diagnosis usage, and parameter caveats. Every sentence adds information; the v2 preference and empty-object warning are concise but high-value.

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 simple listing tool with no output schema, it covers the key behaviors and failure modes well. It could be slightly more explicit about the exact return shape for the list itself, but the phrase 'list every filter kind' plus the detailed defaults behavior is sufficient in practice.

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 schema only says filterKind is optional and returns default settings, but the description adds crucial semantics: kind strings are exact, v2 variants should be preferred, and an empty defaults object means 'nothing declared', not 'no settings'. This materially improves correct invocation and interpretation.

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 opening sentence names a specific action and resource: 'List every filter kind this OBS install can create' and adds the optional defaults behavior. It is easy to distinguish from sibling filter tools because it deals with enumerating kind identifiers rather than acting on existing filters.

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 gives a clear diagnostic use case: use this to verify a plugin actually loaded, since missing filter kinds mean the DLL is absent and retrying CreateSourceFilter will not help. It does not explicitly compare itself to sibling tools such as obs_list_input_kinds or obs_filter_get, so it falls short of fully explicit alternatives.

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?

With no annotations, the description carries the full explanatory burden, and it excels here. It explicitly discloses that indexes are contiguous and renumber after every move, warns against reusing old numbers, specifies the valid range (0 to 8192), and notes the return state ('the resulting chain comes back'). This manages expectations about state mutation and response.

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 longer than average but is front-loaded with the core action ('Move a filter within the chain') before elaborating. The analogies are illustrative and justified. While it's on the wordy side, the info does add value to understanding the tool's behavior. It could potentially be tightened, but not without losing some valuable context.

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?

Given the tool's complexity (related to signal processing order), the description is remarkably complete. It covers the core functionality, the 'why' (with examples), the stateful behavior (renumbering), and the valid range. It gives a strong mental model for the agent to determine when and how to invoke the tool 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?

Although schema coverage is 100% and documents the parameters, the description adds substantial semantic value beyond the bare schema. It expands on the 'index' parameter, explaining the meaning of ordering ('signal path'), the contiguity caveat, and the renumbering behavior, which is not captured in the schema's one-liner.

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 starts with a specific verb+resource: 'Move a filter within the chain.' It goes beyond a simple label by explaining the crucial signal-path semantics (index 0 runs FIRST), which is the key differentiator. It clearly distinguishes this as a reorder operation, contrasted with sibling tools like obs_filter_remove or obs_rename.

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 provides excellent context for when to use this tool by explaining the signal chain with concrete audio and video examples (noise suppression → compressor → limiter). It implies when reordering matters. However, it doesn't explicitly state when NOT to use this (e.g., for adding/removing filters), which could be clearer diagnostic 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the operation is permanent ('permanently', 'no undo'), side effects (renumbering, stale filterIndex), scope ('affects every scene that uses the source'), and return value ('returns the chain that is left'). This is highly transparent and goes beyond simple operation description.

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 concise yet comprehensive, organized into three short paragraphs that each deliver essential information: permanence and alternative, renumbering side effect, and scope/return value. Every sentence contributes value, and it is front-loaded with the core purpose. No filler or redundancy.

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?

Given the tool's destructive nature and lack of annotations, the description covers all critical aspects: irreversible deletion, alternative bypass, renumbering implications, per-source impact, and response format. It also mentions the need to re-fetch via obs_filter_get. This is complete for the operational context.

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 input schema already provides 100% coverage for both parameters, with descriptions like 'Exact filter name, from obs_filter_get.' The description adds minimal new parameter-level detail, but it does reinforce the per-source scope and re-read recommendation, which indirectly clarifies usage. Since schema coverage is high, a baseline of 3 is appropriate.

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 tool's purpose: 'Delete a filter from a source, permanently.' It uses a specific verb (delete) and resource (filter from a source), and distinguishes itself from the sibling obs_filter_toggle by clarifying that bypassing is an alternative. This makes the tool's role 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?

The description explicitly provides usage guidance: it warns that 'if you might want it back, obs_filter_toggle bypasses it instead and keeps the tuning,' and it advises re-reading with obs_filter_get after renumbering. This gives clear when-to-use vs. when-not-to-use context, as well as a concrete alternative.

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?

With no annotations provided, the description carries the full burden of disclosure. It explains that renaming can break external tooling because filters are referenced by exact name, and explicitly notes that renaming does not affect index, settings, or enabled state. This adds significant behavioral insight 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.

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

The description is concise and well-structured, starting with the direct purpose, then explaining the risk, and ending with invariants. Every sentence adds value; there is no fluff or redundancy.

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 simple rename tool with no output schema and no annotations, the description covers the core purpose, the critical risk of external breakage, and the invariants (unique names, no side effects on settings/state). It could mention error conditions (e.g., duplicate newName handling), but the uniqueness note covers that implicitly. The description is sufficiently complete for an agent to use this tool 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?

The input schema already describes all three parameters with 100% coverage, including uniqueness requirements. The description adds context about external naming conventions but does not introduce new parameter-level semantics beyond what the schema already states. Thus, a baseline of 3 is appropriate since 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?

The description clearly states 'Rename a filter' as the primary action and goes on to explain why renaming is unique compared to other filter operations (the name is the only handle). This distinguishes it from sibling tools like obs_filter_remove or obs_filter_toggle, making the purpose 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?

The description provides strong context on when to use this tool (when renaming is needed) and highlights the risk of breaking external dependencies, which is critical guidance. It does not explicitly mention alternatives for other filter operations, but the warning implies that if you need to change settings, you should use the appropriate tool. The naming conventions on the reference machine further clarify expected usage.

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?

With no annotations, the description must disclose behavioral traits. It indicates the tool can mutate state ('or add one') but provides no details on consequences (e.g., whether adding overwrites existing filters, requires specific permissions, or affects current settings). It also does not mention that the listing operation is read-only or what response format to expect. The lack of any behavioral context beyond the action itself is a significant gap.

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 concise: one sentence stating the core action, followed by a semicolon-separated list of useful filters with brief parenthetical justifications. Every part adds value—the filter names are actionable tips for common use cases (noise suppression, gating, chroma key, async delay). There is no fluff or repetition, making it efficient and easy to scan.

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?

Given the tool's moderate complexity (4 parameters, dual functionality, no output schema), the description covers the main actions and imparts helpful filter-kind examples, but lacks critical details: it does not state that adding requires both kind and name, does not clarify that 'sourceName' is always needed, and does not describe return values for listing. It is adequate for basic usage but leaves the agent to infer important operational details, especially for the add operation.

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 0%, so the description must compensate. It indirectly explains 'addFilterKind' by providing a list of useful filter kind strings with parenthetical hints (e.g., 'RNNoise mic cleanup'). However, it does not clarify that 'addFilterName' is required when adding, nor does it explain 'addFilterSettings' or that 'sourceName' is always required. The examples aid but leave the add process incomplete, so it only partially compensates for the missing schema descriptions.

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 dual purpose: 'List filters on a source, or add one.' It uses specific verbs ('List', 'add') and identifies the resource (filters on a source). It distinguishes itself from sibling tools like obs_filter_get (which retrieves specific filter settings) and obs_filter_remove by covering the listing and adding operations, making it unambiguous when this tool applies.

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 implies general usage for listing or adding filters, but does not explicitly compare with alternatives. It provides practical guidance by listing useful filter kinds with explanations (e.g., 'noise_suppress_filter_v2' for mic cleanup, 'async_delay_filter' for sync lag), which helps when adding. However, it lacks explicit when-not-to-use instructions or mention of sibling tools like obs_filter_get or obs_filter_remove for other filter operations.

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?

With no annotations present, the description fully discloses behavior: merge vs replace semantics, silent acceptance of unknown keys, the response returning real settings, and live application with no staging. These are critical behavioral traits that an agent must know and are not available elsewhere, making the description highly transparent.

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 well-organized into three focused paragraphs: examples, merge/replace warning, and validation/response. It front-loads the core purpose and uses every sentence to convey essential information without redundancy. The length is justified given the complexity of the behavior explained.

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 no output schema, the description compensates by explaining what the response contains ('returns the filter's real settings afterwards'). It also covers the timing of effects (live). Given the number of parameters and the nuanced behaviors, the description is thorough and complete enough for an agent to use 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?

Even though the schema covers all 4 parameters (100% coverage), the description adds significant meaning beyond the schema: it elaborates on the replace parameter's merge behavior, gives a concrete example for settings, and warns about key validation. This deepens the agent's understanding of how to use the settings object and its edge cases.

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 'Tune a filter that already exists' with specific resource and action, and distinguishes from siblings like obs_filter_toggle (toggle), obs_filter_remove (remove), and obs_filter_get (read settings). It uses a specific verb 'tune' and resource 'filter', making the purpose unmistakable.

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?

Explicit guidance is provided: 'Read obs_filter_get first to see the keys a kind really uses' and 'Use the default merge unless you specifically want a clean slate.' It also warns about replace:true's destructive behavior. This gives clear when-to-use and when-not-to-use instructions relative to other filter operations.

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?

With no annotations, the description carries the burden and details important behaviors: settings are preserved, disabled filters stay in the chain at the same index, and the effect is immediate on live output. It does not describe error or return behavior, but the operational side effects are well covered.

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 selection guidance. The examples about noise suppression and sync delay are meaningful and communicate real-world impact, though the description is slightly longer than strictly necessary.

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 no annotations and no output schema, the description provides essential operational context: reversibility, chain/index stability, and immediate live effect. It does not discuss return values or failure cases, but for a simple toggle action with full schema coverage it is largely complete.

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 100%, so the baseline is 3. The description reinforces toggle semantics and the 'settings are kept' concept but does not add parameter-specific detail beyond what the schema already 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?

Description begins with a specific verb and resource: 'Switch a filter on or off without removing it.' It clearly states the tool's primary function and explicitly contrasts it with obs_filter_remove, making its scope 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?

Provides explicit when-to-use guidance: 'Reach for this instead of obs_filter_remove whenever the question is is this helping', and explains why removal is not equivalent because it loses tuning and has no undo. This directly supports tool selection.

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?

No annotations are provided, so the description must convey side effects by itself. 'Read' and 'get' hint at a non-mutating and safe operation, but the description does not explicitly disclose auth/denial/errors/return contents, and there is no annotation to confirm read-only behavior.

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 short sentence, fully front-loaded, no filler or redundant phrases.

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?

The parameter set is simple (1 required, fully documented) and the purpose is narrow; however, there is no output schema and return shape/error semantics are not described, so completeness is good but not complete.

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 100% but the schema only defines inputName with a terse description. The tool description adds context that this is one named input's full settings object encompassing resolution, deviceId, URL, file path and similar configuration fields.

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?

Description uses specific verb 'read' with distinguishing scope 'full settings object of one input', mentioning fields like resolution, device id, URL, and file path. It clearly contrasts with output-settings tools and other input tools, though it does not explicitly rule out sibling tools.

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?

Description implies this is for when the settings object of one named input is needed, but it does not state when to prefer this over related tools, nor when not to use it.

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?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the keys an output accepts depend entirely on its kind, there is no schema request for them, and the returned object is the only list of meaningful keys. It also warns 'expect less than you think' with a concrete example. This is strong transparency.

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 fairly long but front-loaded with the core purpose. The latter half provides essential context about what the settings do not contain, which is valuable but adds length. It is not overly verbose, but the length is justified by the critical clarifications.

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?

The tool has a single param, a simple task, but no output schema or annotations. The description compensates by explaining what the response will look like (a list of keys) and gives a concrete example. It also clarifies what the tool does NOT do, preventing common misuse. Given the complexity and lack of structured info, this is quite complete.

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 input schema covers the single parameter fully (outputName with description 'Exact output name from obs_list_outputs'), so schema coverage is 100%. The description adds context on the output type but does not add new parameter-specific semantics beyond the schema. Baseline 3 is appropriate.

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 purpose is clear: it reads an output's settings object. It distinguishes itself from obs_set_output_settings by explicitly stating it should be used before that, and the description clarifies it is for reading, not for finding streaming destinations. This is a specific verb+resource with some differentiation from siblings.

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 explicitly states when to use it (before obs_set_output_settings) and provides clear exclusions: it cannot tell you where the rig is streaming, nor will writing to it change the destination. It also clarifies that bitrate and encoder settings are profile-level, so this tool is not for those. This is exemplary usage 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?

No annotations are provided, so the description carries the full burden. It describes the returned data and the read-only nature implicitly ('health snapshot'). It could add caveats like 'requires OBS running' or 'non-destructive', but the term 'snapshot' conveys safety and comprehensiveness.

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 two sentences: the first statefully lists all returned data, the second gives usage guidance. No filler or redundancy, and the most important information is front-loaded.

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 zero-parameter diagnostic tool with no output schema, the description enumerates all expected data items and explains when to use it. It fully covers what the agent needs to know to select and invoke the tool 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?

The tool has zero parameters, so there is nothing to explain. The description correctly focuses on the output rather than inputs, which is appropriate and provides a good default for no-parameter tools.

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 it's a 'Full health snapshot' with a specific verb ('snapshot') and resource (OBS health). It enumerates exact data fields (OBS version, active scene, stream/record state, live stats). It also distinguishes itself from siblings by positioning as the first diagnostic step.

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 explicitly says 'Use this first to diagnose anything, and to check whether the machine is keeping up,' providing clear when-to-use guidance. It doesn't name specific alternatives or exclusions, but the 'first' directive implies a diagnostic workflow where more specific tools follow.

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?

With no annotations provided, the description fully carries behavioral disclosure. It explicitly calls itself a 'blunt instrument' that fails silently, details what happens when nothing is bound (OBS accepts and does nothing) and when unexpected bindings fire (including stopping stream/recording), and notes the impossibility of verifying bindings beforehand.

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 well-structured in three clear paragraphs: purpose and usage, behavioral warnings, and parameter format. Each sentence adds value without redundancy; the length is justified by the tool's risk profile and the need to emphasize safety precautions.

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 only two parameters and no output schema, the description covers all essential context: when to use, safety risks, parameter constraints, and examples. It addresses the tool's dangerous potential thoroughly, making it complete for safe operation.

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 schema already documents both parameters with descriptions (coverage 100%), but the description adds crucial semantics: keyId must be OBS_KEY_* identifiers from libobs/obs-hotkeys.h with examples, clarifying it's not browser key names or raw characters, and that modifiers belong in keyModifiers. This extends the schema's meaning, though the schema already provided examples.

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 tool presses a key combination at OBS, acting as if typed while OBS has focus. It distinguishes this from alternatives by specifying it's only for actions without a name in obs_hotkey_list and no request, differentiating it from sibling tools like obs_hotkey_trigger.

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?

Provides explicit guidance: use only when an action has no name in obs_hotkey_list and no request, with a concrete example (plugin binding configured by hand). It also warns against misuse, explaining the risks of unintended bindings and that no check is possible, giving clear when-not-to-use 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?

With no annotations provided, the description carries the full burden, and it goes far beyond a simple statement. It discloses deduplication, grouping, counts, and the raw response size ('411 strings of which 37 are repeats'). It also reveals the critical trap that a repeated name cannot be addressed individually, which is exactly the kind of behavioral nuance the agent needs before invoking the tool.

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 longer than average, but it is well-structured into purpose, parameter usage, and a warning section. Every major point earns its place, and the front-loaded purpose makes the tool's intent clear immediately. It is slightly verbose, but given the lack of annotations and output schema, the extra explanation is justified.

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 two optional parameters, no annotations, and no output schema, this description is remarkably complete. It explains what the output contains, how results are grouped and deduplicated, how to narrow results, and what to do with the information. The agent can safely select and invoke this tool without needing additional context.

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 100%, so the baseline is 3. The description adds meaningful behavior beyond the schema by explaining that filter is case-insensitive and that pluginsOnly:true skips roughly 390 core entries. It also connects the parameters to the output's deduplicated count behavior, which helps the agent reason about results.

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 uses a specific verb and resource: 'List the hotkey action names OBS knows about.' It clearly distinguishes itself from the sibling obsession tools by explaining this is the way to discover what plugins can do, especially since plugin actions usually have no obs-websocket request. The scope is concrete and immediately understandable.

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 explicitly states when to use this tool ('how you discover what PLUGINS can do') and gives concrete usage guidance for both parameters. It also warns against triggering repeated actions and tells the agent to 'find the real request instead,' naming alternatives like SetInputMute and SetSceneItemEnabled. This is strong when-to-use and when-not-to-use 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?

With no annotations provided, the description fully bears the transparency burden. It discloses destructive potential (StopStreaming, ForceStopStreaming), no undo/confirmation, refusal to reject any name, duplicate-name ambiguity, and that success means 'name accepted' not 'effect produced'. It also advises verifying outcomes. This is thorough and honest.

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?

Despite being long, every sentence carries critical information: purpose, examples, danger warnings, alternatives, and return semantics. Structurally it is well-organized into clear paragraphs (function, danger, alternatives, verification). No wasted words; density is high and appropriate for a dangerous tool.

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?

The tool has no output schema and no annotations, yet the description covers all necessary context: how to obtain valid names, destructive consequences, duplicate registration pitfalls, and the need to verify effects. It also provides integration with sibling tools (obs_hotkey_list) and alternative APIs. The description is complete for an agent to use this tool safely.

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 100%, so the schema already thoroughly describes both parameters, including case-sensitivity and context discovery caveats. The description adds marginal value beyond schema—it primarily repeats schema details—but it does reinforce the 'exact name from obs_hotkey_list' requirement and the advice to omit contextName unless plugin docs provide one. Baseline 3 is appropriate.

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 tool's purpose: 'Fire an OBS hotkey action by name', specifies it's for invoking plugin features without a dedicated request, and provides concrete examples (VerticalCanvasDock*, SwitcherHotkey). It distinguishes from sibling tools like obs_hotkey_list (which lists hotkeys) and obs_hotkey_key (which sends key presses).

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 explicitly says 'DO NOT USE IT AS A SHORTCUT FOR A REAL REQUEST' and lists specific alternatives like SetInputMute, SetSceneItemEnabled, SetCurrentProgramScene. It also instructs to get names from obs_hotkey_list and cautions about dangerous names. This is exemplary guidance for when to use and when not to use the tool.

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?

无注释，但描述非常透明：解释了默认对象只是下限，不是完整集合；键跨种类被静默接受；版本后缀存在，unversioned 标志只用于识别而非创建。这些是关键的运行时行为，且与 schema 不冲突。

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?

描述非常详细，但组织良好：第一段讲用途，第二段讲限制，第三段讲版本后缀。虽然长，但每个句子都传递了重要信息，不算冗余。结构清晰，但为了简洁可以稍微精简。

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?

对于无输出 schema 且需要大量背景知识的工具，描述提供了完整的上下文：包括返回值、与其他工具的关系、常见陷阱。非常完整。

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：解释了省略 inputKind 会列出所有种类，并警告未版本化的名称不应用于创建。它提供了参数有效值及行为，远超 schema 中的简要说明。

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?

描述明确说明该工具列出 OBS 支持的输入种类及其设置键。它还将其与'哪些插件已加载'的相关性联系起来，这是一个具体的范围。这清楚地与兄弟工具区分开来，例如 obs_get_input_settings 是读取实际设置，而这里是列出种类。

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?

描述详细说明了何时使用（无参数列出种类，带 inputKind 获取默认对象），何时不使用（避免猜测键），并提供了替代方案（读取工作输入、使用属性项）。还警告不要用未版本化的名称创建源。明确的指导和排斥条款。

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?

No annotations are provided, so the description carries the full burden. It fully discloses behavior: returns a list of itemName/itemValue, explains itemEnabled=false semantics, emphasizes that itemValue (not itemName) is what OBS matches, and notes that values are not portable or permanent (USB port change). It also clarifies that it reads properties of an existing instance, not a kind.

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?

Though lengthy, the description is efficiently structured: purpose, usage guidance, parameter specifics, and caveats. Every sentence adds critical context—there is no filler. The structure is logical and front-loaded with the primary usage; the detailed device ID list and failure messages are directly actionable.

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?

Given the complexity of OBS internals and the absence of an output schema, the description is remarkably complete. It explains exactly what is returned (itemName/itemValue), how to interpret itemEnabled, and how to use the result with obs_set_input_settings. It covers portability and the effect of device changes on stored IDs, eliminating guesswork for the 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?

Both parameters have schema descriptions, but the description adds significant depth. It explains that propertyName is the internal ID and provides a verified list of IDs for different input types (dshow_input, wasapi_input_capture, monitor_capture). It also clarifies that inputName must be an exact existing input name and that the source must already exist. This goes well beyond the basic field descriptions.

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 is extremely specific: it enumerates the selectable device options (webcams, mics, etc.) for a given input property, with exact device IDs. It clearly distinguishes itself from sibling tools like obs_list_inputs (lists inputs) and obs_set_input_settings (writes settings), and explains exactly what value to extract for later use.

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?

Explicitly states when to use it ('Read the list here, then write the chosen itemValue with obs_set_input_settings'), contrasts it with the guesswork without it, and gives detailed failure-mode guidance ('Unable to find a property by that name' vs 'The property found is not a list') to help diagnose wrong vs right property IDs. It also warns against reusing stored values.

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?

No annotations are provided, but the description's 'List every source type' read-only operation is inherently non-mutating. Omits any mention of permissions, rate limits, or return contents, but for a pure discovery tool with no side effects the remaining ambiguity is modest.

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, no redundant words: 'List every source type this OBS install supports (tells you which plugins loaded).' The payload is front-loaded and complete.

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?

Tool has one unit of information, and no output schema matters. It may have many sibling tools, but its unique scope is the supported installed source types and plugin discovery. Description contextualizes the info completely; no output schema or parameter info required.

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 accepts zero parameters and the input schema is complete (100% coverage). There is no information for the description to add; the baseline of 4 is appropriate because parameter semantics are not applicable.

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?

Description uses a specific verb ('List') with a clear resource ('every source type') and defines its scope: 'this OBS install supports', plus the parenthetical clarifies the informational value ('tells you which plugins loaded'). It clearly differentiates from sibling enumeration tools.

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 implies a discovery/enumeration use case ('every source type this OBS install supports') but does not explicitly state when to choose this tool over siblings or any exclusions. Read-only enumeration is clear from 'list', but no alternative tool is directly indicated.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that it lists every input/source and includes their kind, but it does not disclose potential limitations (e.g., whether hidden or disabled sources are included, or whether the list is sorted). For a read-only list tool, this is adequate but could be slightly richer.

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 two sentences, both essential. The first sentence states the action and scope, the second provides a concrete use case. No redundancy or fluff.

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 simple list tool with no parameters and no output schema, the description fully covers the purpose and the use case. It tells the agent exactly what will be returned (all inputs with kinds) and why to call it. Additional details would be unnecessary.

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 has 0 parameters, so there is no parameter semantics to add. Baseline for zero-parameter tools is 4; the description does not need to explain parameters. It appropriately focuses on output content instead.

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?

Description clearly states the verb 'List' and the resource 'input/source' with the scope 'every' and provides concrete examples of kinds (video capture device, media source, browser, audio input). It distinguishes from siblings like obs_list_input_kinds (which lists available kinds) and obs_list_sources_in_scene (which lists sources in a scene) by focusing on all inputs globally.

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?

Provides an explicit use case: 'Use this to see which cameras and mics OBS can actually see.' This gives clear context for when to invoke the tool, but does not explicitly mention when not to use it or name alternative tools. It is sufficient context for straightforward selection.

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?

The description transparently explains quirks: plugin outputs use arbitrary labels, width/height may be 0 without indicating breakage, and the key field outputFlags.OBS_OUTPUT_SERVICE indicates service outputs. This goes beyond the schema (which has no annotations) and prevents misinterpretation.

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 overly verbose and repetitive. It repeats 'on the reference machine' multiple times and explains the same points (e.g., width/height being 0) in several sentences. It could be condensed to half the length without losing meaning, which detracts from clarity.

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?

Given the lack of parameters and output schema, the description fully compensates by explaining what the returned list contains, how to identify service outputs, and how to interpret fields like width/height. It provides all necessary context for using the tool effectively.

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 has zero parameters, so the baseline is 4. The description does not add parameter information (none exists), but it does provide context about the output list itself, which is beneficial for interpreting results.

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 tool's function: 'List every output OBS currently has - the stream, the recording, the replay buffer, the virtual camera, and any output contributed by a plugin - with which ones are running right now.' This is specific and distinguishes it from sibling tools like obs_output_status or obs_get_output_settings.

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 provides explicit usage guidance: 'Start here before touching anything in this module, because the names are not predictable.' This tells the agent when to use this tool and why, making it a clear entry point for output-related operations.

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?

With no annotations provided, the description carries full burden and does well: it discloses the read nature and the output behavior (identifying which scene is program vs previewed). It doesn't cover edge cases like preview state when studio mode is off, but for a 0-parameter list operation, the transparency is strong.

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 14-word sentence that front-loads the verb 'List' and includes only essential details. The parenthetical clarification of OBS terminology ('live (program)') earns its place. Zero wasted words.

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 0-parameter tool with no output schema, the description captures the essential contract: the full scene list plus the program/preview state of each. It could elaborate on return format or null preview states, but the scope of this tool is small enough that the description is largely sufficient.

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 has 0 parameters (empty schema with 100% coverage), so the baseline is 4 per the rubric. The description rightly focuses on behavior rather than parameters, and there is nothing in the schema for it to supplement.

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 uses a specific verb+resource ('List every scene') and adds the key differentiator: program/preview status. It distinguishes itself from siblings like obs_list_sources_in_scene and obs_switch_scene by making the listing scope and state annotation explicit.

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 through purpose: an agent can infer when to call this (need scene list with live/preview state). However, there are no explicit when-not-to-use statements or mentions of alternatives, such as pointing to obs_list_sources_in_scene for source-level listings.

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?

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only list operation and enumerates the returned data (item IDs, visibility, transform). It does not mention behavior for nonexistent scenes, 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.

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

The description is two sentences: the first states purpose and output fields, the second gives a usage hint. Every word earns its place, with no redundancy or unnecessary detail.

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 simple list tool with one parameter and no output schema, the description adequately covers purpose, key output fields, and usage context. It lacks details on return format or edge cases, but these are not critical for such a 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?

The only parameter sceneName is fully documented in the schema with 'Scene to inspect.' The description adds the context that the scene contains sources, but does not significantly enhance the semantics beyond what the schema provides. Given 100% schema description coverage, baseline 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 uses the specific verb 'List' with resource 'sources (scene items) inside a scene' and explicitly states the output fields (item IDs, visibility, transform). This clearly differentiates it from sibling tools like obs_list_inputs and obs_list_scenes.

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 phrase 'Needed before moving, resizing or hiding anything' gives explicit context for when to use this tool. It implies a relationship with modification tools like obs_set_source_transform and obs_set_source_visible, though it does not name alternative tools explicitly.

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?

No annotations exist, so the description carries the full burden. It discloses the silent success no-op behavior, the need to inspect returned state, and the watchdog's failure mode on pausing/stopping a looping media source. This is strong 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?

The description is longer than average, but every section earns its place: purpose, no-op behavior, and a critical warning with a safer alternative. It is front-loaded with the core purpose and structured by increasing risk.

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?

Given the tool's complexity and lack of output schema, the description is complete enough. It explains the dangerous edge cases, directs the agent to check returned state, and provides an alternative workflow. The exact shape of the returned state is not detailed, but the guidance to inspect it is actionable.

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 100% and already describes all parameters. The prose adds meaningful nuance beyond the schema for the action parameter (playlist-only, no-op on ffmpeg_source, looping-source watchdog behavior), but inputName/inputUuid are not enriched beyond what the schema already says.

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 first sentence states a specific verb and resource: 'Transport control for a media source' with the six actions. The action list clearly positions it against sibling tools like obs_media_status and obs_media_seek.

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 explicitly explains when next/previous are meaningful, warns they are no-ops on ffmpeg_source, says to check returned state, and names a concrete alternative command for the looping-media case. This is explicit when/when-not/alternative 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?

With no annotations provided, the description takes full responsibility for disclosure and excels. It explicitly states 'There is NO bounds checking... seeking past the end does not clamp,' warns about live-stream behavior, and details the state-file desync risk on the reference machine. This is exactly the kind of non-obvious behavioral context an agent needs.

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?

Every sentence earns its place: the first paragraph states the core function and mutual exclusivity; the second addresses edge cases (no bounds checking, live streams); the third warns against a common misuse pattern and points to the supported alternative. It is front-loaded, scannable, and free of redundant phrasing.

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 4-parameter, 0-required tool with high schema coverage and no output schema, the description completes the picture: it covers preconditions, failure modes, and unintended side effects. The reference-machine example grounds the guidance in an actual operational context. No significant informational gaps remain.

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?

Although the schema covers 100% of parameter descriptions, the description adds critical semantics by defining the mutual exclusivity ('Exactly one of the two') and clarifying the unit and sign conventions (e.g., 'negative to rewind'). This goes beyond the schema's per-parameter documentation and earns more than the baseline.

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 uses a precise verb+resource structure: 'Move the playhead of a media source, either to an absolute position or by a relative amount,' and clearly identifies both parameters with their roles. It differentiates itself from siblings by focusing on seeking and by referencing the read-first prerequisite (obs_media_status). This is specific, not a tautology, and immediately distinguishes this tool from the peer tools listed.

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 gives explicit when-to-use guidance ('Read obs_media_status first... if durationMs is null and unboundedDuration is true, this source is a live stream and seeking is meaningless') and an explicit when-not-to-use scenario ('do not seek a looping media source to reach the next track'), including the alternative command. This is a model of clear usage direction.

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?

The description is highly transparent about the tool's behavior, explaining that PLAYING does not guarantee media is advancing, and that durationMs can be null for live feeds. It also describes the probeMs parameter and its effect on detecting advancing media, without contradicting any annotations (none provided).

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 excessively verbose and repetitive, using three long paragraphs that essentially repeat the same key points with slightly different wording. This hinders quick comprehension and would benefit from a more concise, structured summary.

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?

The description covers the essential aspects: default behavior, the liveness trap and its solution, and the meaning of durationMs. It provides enough context for an agent to understand the tool's purpose and limitations, though it could be more succinct.

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?

While the schema already provides per-parameter descriptions, the tool description adds valuable context: inputName defaults to checking all inputs, inputUuid is used as an alternative, and probeMs controls a second sample for liveness. This goes beyond the basic schema descriptions.

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 tool surveys which media sources are playing, and explains it checks all inputs by default. It distinguishes itself by highlighting the trap that PLAYING state can be misleading, which is a unique purpose.

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 provides guidance on when to use this tool, especially for diagnosing sources that appear to be playing but may have failed. It suggests using probeMs to detect actual liveness, and clarifies the default behavior when no inputName is 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?

No annotations exist, but the description richly discloses behavior: index instability across replugging, the fact that projectors cannot be closed via API, and the surprising consequence of a projector appearing over OBS's own window. This is excellent behavioral documentation beyond what any schema could 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?

Two paragraphs, both earn their place. First sentence states the action and its context. The rest adds critical warnings and fallback guidance. Zero fluff, but it does use 2-3 sentences to explain why — well worth the space.

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?

Given zero parameters and no output schema, the description covers the full picture: what the tool does, how to interpret results (index, count), and what operational decision to make (windowed vs fullscreen). The workaround for the API limitation (cannot close projector) is exactly the kind of context that makes a tool usable. It also references sibling tools by not needing them, which is fine.

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?

Zero parameters, so the schema covers everything. The description adds a helpful baseline example (one 1920x1080 display) and explains the index meaning, which would help an agent interpret output. Slightly shy of 5 because the description doesn't detail the return format (e.g., list of monitor objects) but that may be overkill for a zero-param tool.

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 is exceptionally clear: it states the tool lists physical displays with their indices for fullscreen projectors, explicitly noting positional instability and the lack of a query to find the monitor with the main OBS window. It is distinct from siblings like obs_projector_open_mix or obs_screenshot by focusing on enumeration, not action.

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 explicitly instructs calling this tool before opening a fullscreen projector, warns when not to use it (single monitor) and provides an explicit alternative (use windowed mode when count is 1). This goes beyond generic context and directly addresses when to use this tool vs. alternatives.

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?

No annotations are provided, so the description carries the full burden. It extensively discloses high-stakes behaviors: stopping the service output ends the broadcast everywhere, stopping a replay buffer discards memory, the tool refuses to stop a service output without confirm:true, and starting/stopping an already-running/stopped output is an error.

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 long but every section earns its place: scope in the first paragraph, severe consequences in the second, alternatives in the third, and toggle/error behavior in the fourth. Front-loads the core purpose then layers risks logically.

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?

Given three parameters and no output schema, the description covers intended use, exclusions, safety conditions, error behavior, and tool relationships. It even hints at the return behavior ('reports the state it found instead of failing obscurely'), making the tool predictable to 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?

Although schema coverage is 100%, the description adds vital examples and scenario context: concrete output names like adv_stream and adv_file_output, what confirm:true is for, and why toggle is risky. This significantly enriches the parameter meaning beyond the schema's field descriptions.

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 starts with a specific verb+resource: 'Start, stop or toggle any output by name' and covers StartOutput, StopOutput, ToggleOutput. It clearly distinguishes itself from sibling tools like obs_stream_control and obs_record_control by labeling itself as the general lever for outputs without dedicated tools.

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?

Explicit guidance is provided on when to use this tool vs. alternatives: 'For the main stream and the main recording, prefer obs_stream_control and obs_record_control.' It also advises checking obs_output_status before toggling and using explicit start/stop over toggle.

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?

With no annotations provided, the description fully carries the burden and excels. It discloses critical hidden behaviors: counters are NOT cleared when output stops, outputTimecode and outputDuration reset to zero and therefore agree with outputActive, rising skipped frames with congestion indicates a bottleneck, outputReconnecting interrupts broadcast without outputActive going false, and healthy metrics do not prove the relay is forwarding to platforms. These are exactly the insights an agent needs.

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 lengthy but exceptionally dense with valuable information. Each paragraph has a clear purpose: overview, the critical active-gating caveat, metrics interpretation, and limitation warning. The concrete example of the live rig (1.68 GB, 131,933 frames) illustrates the pitfall effectively. While not concise, every sentence earns its place, only slightly excessive in length for a hint.

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 read-only health tool with one optional parameter and no output schema, this description is comprehensively complete. It covers what the tool does, how to interpret its output ('outputTotalFrames', 'outputCongestion', 'outputReconnecting'), critical state-reset behavior, and significant limitations (relay blindness). Nothing meaningful is left undisclosed.

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?

With 100% schema coverage for the single `outputName` parameter, the baseline is 3. The description adds meaningful behavior beyond the schema ('Omit outputName to get all of them at once'), which clarifies the special omit behavior and enriches the parameter's semantics, so a 4 is appropriate.

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 opening sentence, 'Live health of an output: whether it is running, how long it has been running, how many bytes it has pushed, how many frames it dropped, and how congested it is,' uses a specific verb and resource with clear scope. It effectively differentiates this health-check tool from siblings like obs_list_outputs or obs_health by focusing on real-time output status and even calls it 'the fastest read of what this machine is actually doing right now.'

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 gives actionable usage guidance: 'Read outputActive first and let it gate everything else' and identifies which counters to watch ('the two numbers to watch over time are outputSkippedFrames and outputCongestion'). While it provides rich situational context for when to use the tool, it does not explicitly name sibling tools as alternatives or exclusions, so it falls just short of a 5.

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?

No annotations are provided, so the description carries the full burden—and it excels. Discloses side effects (press is visible on stream, toggling 'activate' drops camera to black), reversible behavior (toggles both directions), success semantics ('clean result means the button was pressed, not that the thing you wanted happened'), and OBS's caching behavior. Also explains that property_items returns 'The property found is not a list' to confirm existence.

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?

Long (three paragraphs with a bulleted list) but every sentence earns its place—the tool has genuine operational subtleties. Well-structured: core purpose → rationale → two canonical use cases → cautions → discoverability. Front-loads the purpose in the first sentence. Slightly verbose given the sibling tool listing, but the density of actionable information justifies the length.

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 no output schema and no annotations, this description addresses every critical aspect: what it does, why it exists, exact ids for the two real use cases, side effects on live streams, success semantics, and the limitation of property_items. This is not just complete—it teaches the agent how to work around OBS's API limitations.

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 100%, setting baseline at 3. The description adds real value beyond the schema: propertyName is elaborated with the exact internal ids ('refreshnocache' not 'refresh'), the bidirectional 'activate' behavior, and the note that asking for a non-existent id returns an error. inputName is linked to obs_list_inputs. This exceeds the baseline but doesn't provide per-parameter syntax detail for every edge case.

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 'Press a button inside a source's Properties dialog'—a specific verb and resource. Clearly distinguishes from siblings by explaining OBS exposes actions only as buttons, and explicitly contrasts with obs_set_input_settings (which writes settings, not buttons) and obs_input_property_items (which only enumerates dropdowns).

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?

Provides extensive when-to-use guidance: two concrete use cases with exact ids ('refreshnocache' on browser_source, 'activate' on dshow_input), when not to use (check which scene is live first to avoid dropping a working camera), and how to verify before pressing (via obs_input_property_items error messages). Explicitly names the alternative for verification (obs_screenshot).

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?

With no annotations, the description carries full weight and reveals important non-obvious behaviors: failure code 506 and its translation, the limit that staging does not guarantee network feeds, that staged scenes are not frozen, and that preview/program swap after transition. This goes far beyond a basic read/set statement.

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 opens with the core purpose, then uses a clearly labeled 'TRAPS' section to list non-obvious behaviors in an easy-to-scan way. Despite length, each item adds real operational value and no sentence has plain, unnecessary filler.

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?

The tool is parameter-simple but operationally nuanced, and this description covers studio mode prerequisites, failure codes, cross-tool workflow, network source caveats, and the dynamic nature of preview. Given that no output schema exists, the description provides complete enough context for an agent to decide and invoke the tool 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?

The single parameter sceneName is already fully documented in the schema ('Omit to just read. Exact scene name from obs_list_scenes'), and the description mainly reinforces 'omit' vs 'set' in prose without adding new parameter-level details. Schema coverage is 100%, so baseline 3 is appropriate.

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 identifies a specific verb+resource: 'Read or set the scene currently sitting in PREVIEW' and clarifies it is staged, not on air. It explicitly distinguishes itself from the scene-change workflow by calling it 'the safe half of a scene change' and contrasting it with obs_studio_transition.

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 includes named alternatives and a required workflow: 'Stage here, screenshot the scene by name... then cut with obs_studio_transition.' It also names obs_studio_mode as the fix when studio mode is off and warns about relying on staged scenes without screenshot confirmation, which is strong when-to-use and when-not-to-use 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?

No annotations are provided, so the description carries the full disclosure burden. It does disclose the dual read/write nature (list vs. switch) and clarifies the scope of each resource via parentheticals. However, it omits important behavioral details such as whether switching persists across restarts, whether changes affect the active stream immediately, and what the return payload looks like when listing.

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 efficient sentence, front-loaded with the action verbs, that conveys both operations and defines both entity types in parentheticals. Zero wasted words.

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 low-complexity tool (2 optional string params, no annotations, no output schema), the description covers the essentials: what operations exist and what entities they act on. Slightly more detail on inter-parameter behavior (can both be set in one call?) or expected value format would round it out, but this is nearly complete for 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 description coverage is 0%, so the description must compensate. The parentheticals do map naturally to the two parameters (setProfile → encoder + streaming settings; setSceneCollection → scene layouts), and 'List / switch' implies param-presence semantics. However, the mapping is implicit rather than explicit — a comment like 'omit params to list, provide to switch' would strengthen it.

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?

Uses specific verbs ('List / switch') and clearly identified resources ('OBS profiles', 'scene collections') with helpful parenthetical clarifications ('encoder + streaming settings', 'scene layouts'). No sibling overlaps with profiles/collections, so differentiation isn't critical here. Loses a point for not explaining the relationship (or lack thereof) between the two actions.

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?

No explicit when-to-use guidance, no exclusions, and no mention of alternatives. The intended usage pattern (no args = list, args present = switch) is only implied by the 'List / switch' verbs, and no guidance is given on when to switch profiles vs. scene collections despite the existence of related tools like obs_switch_scene and obs_video_settings.

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?

With no annotations provided, the description carries full behavioral burden and exceeds it. It discloses the default WINDOW behavior, that fullscreen covers the entire screen, and critically warns that 'obs-websocket cannot close or enumerate projectors - this window stays until someone closes it in the OBS UI.' This is exactly the kind of side-effect transparency agents need.

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?

Three well-organized paragraphs: what it does, per-use-case guidance, and window/fullscreen warnings. While long, every sentence earns its place and the core purpose is front-loaded in the first sentence. Slightly dense but never wasteful.

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?

This is a high-risk tool (unrecoverable fullscreen state, non-enumerable projectors) and the description steps up to that complexity with all critical warnings. No output schema exists, so none is expected. It covers prerequisites (obs_monitor_list), failure modes, and edge cases like monitorIndex=-1 for windowed mode.

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 100% so the baseline is 3, but the description adds meaningful context beyond schema: it explains when monitorIndex is appropriate (only if you can afford to lose the display) and demystifies projectorGeometry (undocumented Qt base64 format, copy from elsewhere). Only videoMixType gets lighter treatment since the schema already explains its enum values well.

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 opens with a specific verb+resource phrase: 'Open a projector showing a whole video mix' and enumerates the three mix types (program, preview, multiview). It clearly distinguishes itself from sibling obs_projector_open_source by scoping this tool to mix views.

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?

Excellent per-value usage guidance: each enum value gets a use case ('program... is the standard clean-feed trick', 'preview is the confidence monitor', 'multiview is for a director'). It also gives explicit when-not-to guidance: 'Pass monitorIndex only when obs_monitor_list shows a display you can afford to lose.'

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?

No annotations are provided, so the description carries the full burden. It discloses that the projector defaults to a window, that obs-websocket cannot close or enumerate projectors, that it shows only the source alone (overlays from other scenes are excluded), and that it does not re-encode. These are key behavioral details 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.

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

The description is well-structured with clear paragraphs, each serving a distinct purpose: the core action, use cases, behavioral nuances, and limitations. Every sentence adds value without redundancy, balancing detail and brevity.

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 parameters and no output schema, the description covers essential context: the distinction between sources and scenes, the practical use cases, the exclusion of overlays, the window behavior, and the alternative for the program mix. It is complete enough for an agent to decide when and how to call it.

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 100%, so baseline is 3. The description adds meaning by explaining that sourceName accepts scene names as readily as input names, and provides guidance on projectorGeometry ('omit it unless you are reusing a known value') and monitorIndex ('Omit, or use -1, for a normal window'). These clarifications exceed the schema's descriptions.

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 tool's purpose: 'Open a projector showing ONE source on its own, rather than the whole mix.' It explicitly distinguishes from obs_projector_open_mix and explains that sourceName can be a scene or input, making the scope 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?

The description gives explicit use cases ('feeding one specific picture to hardware or to a person') and a clear alternative: 'If you want what the audience sees, that is the program mix, not a source - use obs_projector_open_mix.' This provides both when-to-use and when-not-to-use 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal the raw, direct-by-name nature of the request invocation, but it omits warnings about potentially destructive or state-changing actions, authentication requirements, error handling, or the fact that raw payloads may be unvalidated. The 'ESCAPE HATCH' label hints at advanced use but does not explicitly disclose risks.

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 three short, purposeful sentences: a label, a definition, and a pointer to the protocol reference. It is front-loaded with the 'ESCAPE HATCH' tag and contains no filler or redundant information.

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 generic raw pass-through tool with two parameters, no output schema, and no annotations, the description covers the essential context: what it is, what it does, its scope relative to sibling tools, and where to find request names. It does not elaborate on response formats or validation, but for an escape hatch that intentionally mirrors arbitrary protocol requests, the description is reasonably complete.

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 100%: requestType includes examples ('GetHotkeyList', 'TriggerHotkeyByName') and requestData is described as 'Payload for that request.' The tool description adds the notion of a 'raw payload' and 'by name,' but it does not provide additional per-parameter semantics or request-specific structure beyond what the schema already offers, matching the baseline when schema coverage is high.

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 defines the tool as an 'ESCAPE HATCH' that can 'call any obs-websocket v5 request directly by name with a raw payload.' It explicitly states the scope (any request) and distinguishes itself from siblings by covering 'everything the wrapped tools do not, including plugin-provided vendor requests.'

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 implicitly provides usage guidance by stating it covers 'everything the wrapped tools do not,' indicating the user should use the wrapped tools for typical operations and turn to obs_raw for anything else. It also directs users to 'the obs-websocket protocol reference for request names,' but does not explicitly enumerate when-not-to-use cases or list alternative tools.

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?

The description discloses three traps: requires active recording, requires Hybrid MP4 format, and that the marker lands at the current time. Since no annotations are provided, this fully covers behavioral traits.

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 lengthy but well-structured with a clear opening sentence and a numbered trap list. However, some redundancy exists between the description and the parameter schema text, making it slightly less concise.

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?

The description covers the tool's purpose, usage context, and all failure conditions. No output schema is provided, but the description doesn't need to explain returns since there is none. The traps cover edge cases comprehensively.

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 schema already fully describes the parameter (optional name, omit and OBS numbers it, names the segment that starts). The description adds phrasing about 'starting' vs 'ending' but it is redundant with the schema, providing no new semantic information.

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 explicitly states the tool drops a named chapter marker into the local recording at the current instant, with the clear purpose of enabling VOD navigation. It also distinguishes from clipping, which clarifies its role.

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 provides explicit guidance on when to use this tool (as a cheaper alternative to clipping) and lists traps that indicate when it cannot be used (inactive recording, wrong format). This gives clear conditions and alternatives.

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?

No annotations are provided, so the description carries the full burden, but it mostly restates the action enum values. It adds the 'local backup / VOD master' framing but does not disclose what 'query' returns, whether actions are idempotent, or what side effects occur when stopping or pausing.

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 compact sentence with front-loaded verbs and a clarifying parenthetical. Every word earns its place, and no unnecessary detail is included.

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 simple one-parameter control tool, the description is largely sufficient: it names the operations and clarifies which recording target is affected. It could add details about status output or failure modes, but the low complexity keeps the gap minor.

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 single 'action' parameter is fully described by its enum in the schema, and the description paraphrases those values in prose. However, with 0% schema description coverage, the description only minimally compensates; it does not add parameter-specific meaning such as what each action does beyond its name.

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 uses a specific verb set — start, stop, pause, resume, query — tied to a clear resource: local recording. The parenthetical 'local backup / VOD master' distinguishes it from sibling tools like obs_stream_control or obs_replay_buffer.

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 clearly identifies the domain ('local recording') and implies separation from streaming or replay-buffer tools. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for selection among the many OBS siblings.

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?

With no annotations, the description carries full burden and excels: it discloses the error condition (recording must be active), the irreversible nature (no undo, no rejoin), the file naming behavior (not user-chosen), and the container boundary implications. It also states that the stream is untouched, which is critical for user expectations.

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 longer than average but well-structured with a clear purpose statement and a TRAPS section. Every sentence contributes essential information (purpose, usage context, stream untouched, four traps). It is front-loaded with the primary action. While somewhat verbose, it is not redundant or wasteful.

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?

The description is comprehensive for a tool with no parameters and no output schema. It covers the operation's effect, prerequisites (active recording), error behavior (code 501), limitations (no undo, split boundary), and naming behavior. It leaves no critical aspect unexplained 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?

There are no parameters, and the schema is empty. The baseline for zero parameters is 4, and the description adds value by explaining precisely what the tool does without needing parameters. It also informs the user that the output file name is not user-controlled, which is key semantic information beyond the schema.

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 explicitly states the action: 'Close the recording file being written right now and immediately start the next one, without stopping the recording.' It also clarifies the resource (local recording) and differentiates from other OBS control tools by focusing on the splitting behavior, which is distinct from start/stop controls.

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 provides clear context for when to use: 'Use it to cut a long show into pieces you can upload or hand off while the show is still going.' It does not explicitly mention alternative tools, but the context implies that waiting for one file is the alternative, and it lists traps that cover when not to use (e.g., recording must be active).

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?

This description is exceptionally transparent about internal behavior and side effects: the 'trap' where OBS retains references, the vertical-canvas plugin example, and the tool's self-verification ('re-reads the input list afterwards') are detailed. It also discloses non-obvious consequences like loss of filters, audio routing, and sync offset, fully carrying the burden in the absence of annotations.

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 lengthy (~250 words) but each paragraph serves a purpose: the action, the trap, the alternatives, and the precautionary advice. It is well-organized with clear topics, though a few sentences could be tightened. Overall, it earns its length for a destructive operation.

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?

Given the tool's destructive nature, no output schema, and single parameter, the description covers all necessary context: what it does, why it might fail, when to avoid it, and what data cannot be recovered. The advice to read settings first completes the picture for safe usage.

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 schema already provides a clear description for 'inputName' ('Exact input name. Removal is permanent and affects every scene containing it.') at 100% coverage, so the tool description adds little beyond restating the parameter's importance. It does not introduce new syntax or format details, thus meeting but not exceeding the baseline.

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 opens with 'Delete a source outright, removing it from every scene it appears in at once,' which clearly states the verb (delete) and resource (source) with a scope qualifier. It also differentiates from siblings like obs_rename_input and obs_remove_scene_item by emphasizing the global, permanent nature of deletion.

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?

Explicitly states when NOT to use: 'if the goal is to stop something DECODING rather than to delete it, do not use this at all: take it out of every scene, or hide it.' It also names a concrete alternative (obs_get_input_settings) and explains why this tool is irreversible, providing strong decision support.

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?

With no annotations provided, the description carries the full behavioral disclosure burden. It explains internal safety, external silent breakage, delayed symptoms, uniqueness constraints, and failure behavior when the new name is already in use. This is exceptionally transparent.

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 front-loaded with the core purpose, then organized into internal safety, external risk, and uniqueness. Though longer than average, every sentence contributes necessary guidance for a deceptively risky operation.

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 2-parameter tool with no annotations and no output schema, the description fully covers purpose, effect, risk, failure modes, alternatives, and naming constraints. No critical context 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 100%, so baseline is 3. The description adds meaningful context beyond the schema by explaining why the new name matters for external automation and reinforcing that duplicate names fail. This elevates the score above baseline.

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 opens with a clear, specific verb+object statement: 'Rename a source.' It also distinguishes this tool from the broader OBS tool family by clarifying exactly what is renamed and why the rename behaves differently internally vs externally.

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 provides explicit when-not-to-use guidance: renaming a source breaks external automation that references sources by name. It recommends renaming the scene or leaving the source name alone, giving clear alternatives and a strong risk assessment.

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?

With no annotations provided, the description carries the full transparency burden and does so admirably: it discloses asynchronous saves, the `pathChanged` flag, the previous-clip pitfall, 501 failures unless running, CPU cost, and the separate 'Vertical Backtrack' buffer.

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 long but appropriately organized: purpose is front-loaded, the key action is highlighted, and the numbered TRAPS make the complex failure modes scannable. Every sentence adds actionable information.

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?

Given that there is no output schema and the tool has asynchronous behavior plus multiple failure modes, this description is unusually complete. It explains what save returns, how to verify it, when actions will fail, and resource implications.

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 schema already describes both parameters well, so the baseline is 3; the description adds meaning beyond that by explaining the behavior of the `save` action and why the returned path must not be trusted without checking `pathChanged`. It does not explicitly discuss `waitMs` in the prose, but the schema covers it.

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 defines the replay buffer as a backwards-in-time capture primitive and identifies `save` as the operation that writes the buffer to a file. It distinguishes itself from sibling capture tools by explaining that this is the only primitive that works backwards in time.

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 explicitly states when to use the tool: after the fact, when a moment is only recognizable after it happens. It also gives when-not guidance, such as the 20-second buffer window, and warns to check status before other actions because the buffer does not start itself.

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?

With no annotations to convey safety or behavior, the description carries the full disclosure burden and excels. It reveals that OBS itself writes the file (so paths resolve on the OBS machine), warns about black/stale frames when sources aren't rendering, explains the 'scale to inner' dimension behavior, and notes format compilation caveats. These are non-obvious behavioral traits an agent must know, all disclosed in an organized 'TRAPS' section.

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 tightly organized: purpose in the first sentence, usage rationale in the next, then a clearly labeled 'TRAPS' list. Every sentence adds value—no fluff. The use of numbered points for edge cases keeps it scannable despite its length, making it highly usable for an agent parsing quickly.

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?

Given the tool's complexity (6 params, no output schema, no annotations), the description covers all critical aspects: return value (path), file-system implications, dimension behavior, format constraints, and failure modes (black/stale frames). It even hints at performance trade-offs with compression formats. The only minor omission is error handling, but that does not detract from an otherwise thorough treatment.

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?

Although schema coverage is 100% (baseline 3), the description adds meaningful semantic layers: it explains the interplay of width/height via 'scale to inner,' warns that imageFilePath must be absolute and point to an existing directory, clarifies that format support is build-dependent (with GetVersion as the source of truth), and gives compression-quality guidance ('0 = smallest file, 100 = uncompressed'). This goes well beyond the schema's terse field notes.

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 opens with a precise verb+resource pair: "Write a frame of a scene or source straight to a file on disk, and return the path." It immediately distinguishes itself from the sibling tool by contrasting with "the image-returning screenshot tool," clearly positioning this as the file-oriented alternative. This is unambiguous and specific.

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 provides explicit when-to-use guidance: "Use this instead of the image-returning screenshot tool whenever the picture is for a FILE - a thumbnail, a clip poster, a before/after pair, anything sampled on a loop." It also tells when NOT to use it: "Keep using the other one when you personally need to SEE the frame to judge framing or spot a black camera." This directly addresses alternative selection.

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?

With no annotations provided, the description carries the full burden and excels. It discloses z-order placement ('lands at the TOP'), default enabled behavior, and clarifies the difference between being enabled and being off-canvas, plus the need for obs_scene_item_order for repositioning.

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 well-structured and front-loaded with the primary purpose, then elaborates with examples and behavioral notes. Every sentence adds value; there is no fluff or redundancy, and it is appropriately sized for the tool's complexity.

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 3 params, no annotations, and no output schema, the description is remarkably complete. It covers purpose, usage alternatives, z-order behavior, default states, and interactions with other tools (obs_scene_item_order). The only minor gap is lack of error scenarios, but given the rich context, it feels sufficient.

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 100%, so baseline is 3. The description adds meaningful context beyond schema by explaining the semantic of 'existing source' and the implications of reuse, as well as the enabled default and response index behavior. This goes beyond simple parameter descriptions.

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 specific action: 'Add an EXISTING source to a scene, as a new scene item.' It differentiates from obs_create_input by explaining the distinction ('missing half') and provides context on reuse, making it distinct from sibling tools.

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?

Explicit guidance on when to use this tool vs creating new inputs: 'Reusing a source is almost always what you want...' It also gives concrete examples of scene nesting and warns against rebuilding overlays, providing clear when-to-use and when-not-to-use 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the visual effects of each blend mode, how the mode depends on stacking order, and why an item at index 0 might appear unchanged. It does not discuss return shape or error behavior, but the core runtime behavior is well covered.

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 front-loaded with a one-sentence purpose, then organizes additional detail by theme: mode semantics, z-order interaction, and read behavior. Every sentence contributes meaningful information with no repetition of schema contents or filler. The length is justified by the complexity of the blend-mode concepts.

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?

The description covers the main behavioral nuances: read versus write, blend-mode semantics, z-order dependence, and the index-0 pitfall. It does not formally describe the output of a read, and there is no output schema to fill that gap, but the tool's domain is narrow and the provided guidance is enough for an agent to invoke it correctly in most cases.

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 100%, establishing a baseline of 3. The description adds substantial meaning beyond the schema by explaining what each blend mode does (additive/screen dropping black, multiply/darken dropping white), and clarifies that omitting blendMode means a read. This elevates the parameter documentation beyond the bare enum list.

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 opens with a specific verb-resource pair: 'Read or set how a scene item composites with the layers under it.' This distinguishes it from sibling scene-item tools like transform, order, or lock, and clearly identifies the property being manipulated.

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 gives clear guidance on when to use the tool and how to use it correctly, including the 'Omit blendMode to read' pattern and the z-order interaction caveat. It does not name explicit alternatives, but no direct sibling offers blend-mode functionality, so the contextual guidance is strong.

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?

With no annotations, the description carries the safety/side-effect burden and does this well: it discloses that the duplicate references the same underlying source, that this duplicates audio playback, and that OBS allows duplicate placements of the same source. It also clarifies that transform/crop/blend are copied, which is not inferable from 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.

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

The description is front-loaded with a one-sentence core operation, followed by concise conceptual and caveat paragraphs. Every sentence adds non-obvious value; no filler.

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 mutating tool with no annotations and no output schema, the description covers operation, use case, and side effects unusually well. The only notable omission is what the tool returns (e.g., the new item ID), which would help an agent chain follow-up operations on the duplicated item.

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 100%, so the baseline is 3. The description repeats optional toScene semantics but does not materially add parameter-level meaning beyond the schema entries.

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 first sentence names a specific verb ('Copy a scene item') plus the intact transform/crop/blend mode and destination options, so the tool's core action is unmistakable. The phrase 'clones the placement, not the camera' separates it from source-adding or source-duplicating siblings.

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 explicitly recommends this for building matching layouts and warns about audio-carrying sources producing doubled audio and no-deduplication behavior. It does not name a specific alternative tool or an explicit 'do-not-use' case, so it falls just short of full 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?

The description thoroughly discloses behavior: locked items cannot be dragged/transformed, SetSceneItemTransform fails on locked items, and omitting 'locked' reads the current state. This is transparent without annotations.

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 slightly verbose but every sentence adds meaningful value, avoiding redundancy while covering all necessary aspects. It is well-structured and easy to scan.

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?

Given no output schema, the description explains the read behavior when omitting 'locked', potential failure mode, and typical use cases, making it contextually complete for a user.

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 descriptions cover each parameter, and the tool description adds extra nuance (e.g., 'true = lock, false = unlock, omit to read'), fully clarifying parameter meaning and optionality.

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 'Lock or unlock a scene item' and explains the specific action and its effect, distinguishing it from other scene item operations.

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 explicitly advises when to use the tool ('Worth using on the pieces that must not drift') and clarifies what it does not affect (visibility, audio), guiding appropriate usage.

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?

With no annotations provided, the description fully carries the burden. It discloses critical behavioral traits: index 0 is bottom (inverted from OBS UI), the risk of vanishing layers, the return of the full order on every call, and contiguous reindexing after a move. It also includes a detailed gotcha about BG layers, which is 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.

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

The description is long but every sentence is purposeful. It front-loads the core purpose, then packs critical warnings and usage details efficiently. No filler; each paragraph adds distinct value, making it dense without being bloated.

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 read/write tool with no output schema, the description covers all essential aspects: how to invoke, what the return gives (full order), the indexing quirk, the reindexing caveat, and a practical troubleshooting tip. It is complete for an agent to use correctly without external context.

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 100%, so parameters are already documented. The description adds meaningful semantics: clarifies index 0 meaning, explains sceneItemId requires index, and notes that reads are bottom-first. It goes beyond basic schema descriptions by explaining the indexing behavior and the necessity of re-reading after moves.

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 it reads or changes z-order, specifying the exact resource (scene items) and the action (ordering). It distinguishes from sibling tools like obs_scene_item_add or obs_set_source_visible by focusing on layer ordering, and even differentiates read vs. move modes within the same tool.

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?

Explicitly explains when to use read (sceneName only) vs. move (add sceneItemId and index) and warns to re-read after a move. It provides clear operational context, though it doesn't name alternative tools for similar tasks, relying on the obvious distinction from its purpose.

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?

With no annotations, the description carries full burden and excels: it explains that only the placement is removed, the source remains intact in other scenes, settings/filters persist until the last placement is removed, and there is no undo over the websocket. This is rich, non-obvious behavioral 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?

Three dense paragraphs, each earning its place: the action, the placement-vs-source distinction with a concrete example, and the irreversibility warning with an alternative. Slightly verbose but well-structured and front-loaded with the core action.

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 tool with no output schema, the description fully covers the side-effect model, the last-reference behavior, and the lack of undo. There are no meaningful gaps regarding what the tool does or what the agent should consider before invoking it.

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 input schema already describes both parameters at 100% coverage, with sceneItemId referencing obs_list_sources_in_scene and noting scene-unique scope. The description adds no additional parameter-level detail, so the baseline of 3 for high schema coverage is appropriate.

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 opens with 'Remove one scene item from its scene,' a specific verb+resource statement. It further distinguishes the tool from source deletion and from obs_set_source_visible by clarifying it removes the placement, not the underlying input.

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?

Explicitly provides when-not-to-use guidance: 'If the goal is just to get something off screen, obs_set_source_visible is reversible and this is not.' It also implies the tool is for permanent placement removal with no undo.

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?

With no annotations, the description carries the full load and does so exceptionally. It reveals that calling with only sceneName and sceneItemId reads the current transform, that only passed fields change, that bounds are ignored without boundsType, that alignment is a bitmask causing teleport-like behavior, that crop is in source pixels, and that read-only fields cannot be written. The off-canvas audio gotcha is an invaluable behavioral disclosure not derivable from any schema.

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 long but every sentence earns its place, covering complex interactions and critical warnings without repetition. Clear section breaks (BOUNDS, ALIGNMENT, Crop, off-canvas) front-load the most important constraints. The summary sentence, read/write usage note, and warnings are each purposeful and non-redundant.

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 17-parameter tool with no annotations and no output schema, this description is exceptionally complete. It covers parameter interactions, read vs. write behavior, units, edge cases (e.g., off-canvas audio), and provides real-world examples. Nothing important is left unexplained for an agent to safely invoke this 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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It explains the alignment bitmask's teleport effect, the dependency of boundsWidth/boundsHeight/boundsAlignment on boundsType, why scaleX/scaleY become irrelevant after bounds activation, and the precise meaning of crop units. It also introduces read-only derived fields (width/height/sourceWidth/sourceHeight) not present in the schema.

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 opens with 'The complete transform: position, scale, rotation, alignment, crop and bounds,' naming the exact verb and resource scope. It also clearly distinguishes itself from the sibling obs_set_source_transform, which 'covers position, scale and crop only; this one reaches the rest.' This is a specific, differentiating purpose statement.

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 guidance is explicit and practical. It tells the agent when to use this tool instead of obs_set_source_transform (when rotation, alignment, or bounds are needed) and when to use obs_set_source_visible instead of off-canvas positioning (hiding cuts audio, parking does not). It also advises that bounds are appropriate for a fixed-size slot and that scaleX/scaleY stop being the thing to adjust once bounds are active.

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?

No annotations are present, so the description carries the behavioral burden. It discloses that the capture is immediate ('RIGHT NOW'), returns an image, and helps detect black-frame/dead-source states, which is useful behavioral context. Minor gaps like error behavior on invalid sourceName are not covered, but they are not critical for this simple read-only operation.

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, front-loaded with the core behavior and outcome, and every sentence adds value: one defines the capture action and the other explains its intended diagnostic use. No fluff or repetition.

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 low-complexity, two-parameter tool with no output schema, the description adequately covers purpose, return type, and key use case. It does not explicitly address how this differs from obs_save_screenshot, but its emphasis on returning the image to Claude makes the distinction reasonably clear.

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 100% and already explains width and sourceName. The description adds valuable parameter context by advising to use the current program scene to see what viewers see, which goes beyond the raw schema.

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?

Description clearly states it captures a scene/source's current visual state and returns it as an image, which is specific and action-oriented. It does not explicitly contrast with sibling obs_save_screenshot, so it lacks direct sibling differentiation.

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 explicitly frames usage around visual verification of framing, layout, and camera liveness ('This is how Claude visually verifies...'). It provides clear context but does not list exclusions or point to alternative tools like obs_save_screenshot.

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?

With no annotations, the description carries the full burden. It discloses the important partial-update behavior ('Pass only the keys you want to change'), implying unspecified settings are preserved. However, it does not mention potential side effects, permissions, or return values, and for a mutation tool this is a moderate gap.

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 two sentences, front-loaded with the action verb, and provides a crucial usage tip ('Pass only the keys you want to change') without any unnecessary words. It is highly concise and well-structured.

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?

Given the tool's moderate complexity and lack of output schema, the description covers the essential aspects: what it does, how to use it (partial merge), and examples. It does not enumerate all possible settings or mention integration with sibling tools like obs_input_property_items, but for a setter tool this is fairly complete.

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 schema covers 50% with the 'settings' parameter described as a partial object to merge. The description adds significant semantic value by listing example settings (device, URL, resolution, FPS), helping the agent understand what keys to pass. The inputName parameter remains underdocumented, but its meaning is clear from context.

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 tool's purpose with a specific verb ('Change settings') and resource ('an input'), and provides concrete examples like swapping a webcam's device or changing a media source URL. This clearly distinguishes it from sibling tools like obs_get_input_settings (read) and obs_create_input (create).

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: 'Change settings on an input' indicates this is for modifying existing inputs. However, it does not explicitly state when to use this tool versus alternatives (e.g., obs_get_input_settings for reading, obs_create_input for creation) or provide exclusion criteria, so guidance is implied but not explicit.

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?

No annotations are provided, so the description carries full burden. It discloses the critical behavior that the settings object is REPLACED, not merged, and explains the consequence of sending partial objects. It also warns about the timing issue with running outputs and the risk of taking down a live connection, which is rich behavioral context beyond what any schema could 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 description is well-structured with three paragraphs, each addressing a distinct aspect: the replacement behavior, what is not included, and timing/verification. Every sentence adds critical information with no fluff. It is front-loaded with the most important warning about replacement, making it easy for an agent to grasp the key risk immediately.

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?

Given the tool's complexity (replacement semantics, timing constraints, safety risks) and the absence of annotations and output schema, the description is remarkably complete. It covers the critical behavioral nuances, provides clear usage guidance, and warns about potential pitfalls. The agent has everything needed to use this tool correctly and avoid common mistakes.

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 100% and both parameters are described in the schema. The description adds value by emphasizing that outputSettings must be the COMPLETE object and instructing to start from obs_get_output_settings, which reinforces the schema's note about omitted keys. This goes slightly beyond the schema's description, so a 4 is appropriate.

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 tool writes an output's settings, with a specific verb ('Write') and resource ('output's settings'). It distinguishes from siblings by explicitly noting that destination/stream key/bitrate/encoder are not part of output settings and belong to obs_profile_and_collection, which differentiates it from related tools.

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 provides explicit when-to-use guidance: it warns against using this for destination/quality changes, directs to obs_profile_and_collection for those, and instructs to read obs_get_output_settings first. It also gives timing guidance (change while output is stopped) and verification advice (use obs_output_status afterwards), which is comprehensive.

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?

With no annotations provided, the description is responsible for deciding behavioral expectations. It adds a genuinely useful fact—'Coordinates are in canvas pixels'—which helps the agent understand the coordinate frame. But it does not disclose whether unspecified transform parameters are preserved or reset, nor does it explain any prerequisites or side effects beyond the obvious 'set' operation.

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 two sentences, front-loaded with the primary action and an explicit use case. It avoids filler and every sentence contributes meaningful information.

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?

This is a 10-parameter, mutation-oriented tool with no annotations and no output schema, which places a heavy responsibility on the description. The short text offers only high-level guidance and does not explain the interaction of parameters, the coordinate origin, units as they apply to crops/scale, or the behavior for omitted values. It is not adequate for an agent to confidently select and invoke the tool across the full parameter space.

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?

There are 10 parameters and the input schema provides 0% description coverage, so the tool description must compensate. It broadly signals that position and size are controlled, and the canvas-pixel coordinate note assists with position parameters, but scale fields, crop values, and their units/meaning are left entirely to names. This is not enough to support correct usage of the full parameter set.

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 operation with specific verbs ('position and size') and a concrete resource ('a source inside a scene'), and it adds a practical use case ('picture-in-picture and side-by-side layouts'). It is not quite a 5 because the sibling tool `obs_scene_item_transform` likely overlaps in functionality, and the description does not explicitly distinguish when to use one over the other.

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 gives a clear intended context by mentioning picture-in-picture and side-by-side layouts, which tells the agent when to consider this tool. However, it gives no exclusions or alternatives, and the existence of a sibling named `obs_scene_item_transform` makes the absence of explicit comparison guidance more impactful.

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?

With no annotations, the description must convey the tool's effect, and 'show or hide' does that simply. However, it does not disclose additional traits such as reversibility, persistence of the visibility change, or behavior if the sceneItemId is invalid—though for this simple setter the core behavior is clear.

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 well-worded sentence with an example, front-loading the action immediately. There is no redundant content or padding.

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 simple three-parameter mutation with fully described schema, the description provides sufficient context: what the tool does, the targeted entity, and examples. No output schema exists, but none is expected; the only minor gap is not explicitly clarifying that this action does not create or remove sources.

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 input schema already covers all three parameters with 100% coverage, including the meaning of the `visible` boolean and the provenance of `scene_item_id`. The description adds no extra semantic value beyond what is in 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 uses a specific verb ('show or hide') with a clear resource ('one source inside a scene') and provides relatable examples ('drop the overlay, hide a camera'). This clearly distinguishes it from sibling tools like obs_scene_item_remove, obs_scene_item_lock, or obs_set_source_transform.

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 gives clear context about the operation but does not explicitly state when to prefer it over alternatives such as removing, duplicating, or locking a scene item. The schema's reference to getting the ID from obs_list_sources_in_scene implies workflow, but there is no explicit exclusion of other scene-item tools.

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?

With no annotations provided, the description carries the full burden, and it excels: it carefully explains the complete null semantics ('Any slot a user never configured comes back null... all six are null') and explicitly disambiguates what six nulls do NOT mean ('NOT 'this OBS has no audio' and NOT 'the request failed''). It also discloses the read-only nature. No annotation contradiction exists.

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?

At roughly 130 words, the description is on the longer side, but nearly every clause earns its place by resolving genuine ambiguities (the scaffolding script scenario, the 'named input' clarification, the explicit error misreads). It front-loads the purpose sentence and then builds a logical trap-to-resolution arc. Only minor parenthetical asides, like 'which is every rig built by a script,' could be tightened without significant loss.

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?

Given there is no output schema and no annotations, the description effectively carries all explanatory weight, and it covers the highest-risk failure modes (null interpretation, false-negative reads) that would otherwise cause an agent to misroute troubleshooting. The only minor gap is that it never shows an explicit example of the return structure, but for a 0-parameter read of six slot names, the description is nearly complete. This is a small gap given the extensive behavioral coverage.

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 has zero parameters, so the schema carries no parameter information; the rubric sets a baseline of 4 in this case. The description adds appropriate semantic value by clarifying the meaning of the values the tool returns (the six slot names and their null states), which is the relevant 'parameter-like' semantic here. No parameter details are missing or needed.

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 uses a specific, unique verb+resource framing: 'Names of OBS's six built-in audio slots: Desktop Audio, Desktop Audio 2, and Mic/Aux 1-4' plus 'Read-only,' making the tool's function unmistakable. It also distinguishes itself from the sibling obs_audio_routing_map by directing users there to find microphones, which explicitly differentiates it from a closely related tool (obs_audio_ricing_map is also named as the alternative).

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 gives explicit when-to-use guidance ('Use this to resolve the two names OBS itself uses in its settings UI') AND names a concrete alternative ('use obs_audio_routing_map to actually find the microphones'). It explains the critical decision point for when to read this vs. another tool. This exceeds the rubric's bar for explicit alternatives.

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?

With no annotations, the description reveals a critical behavioral consequence: stopping ends the broadcast for all viewers on every platform. This is essential safety information beyond what the schema provides, making the impact of actions transparent.

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 crisp sentences deliver purpose, usage caution, and behavioral impact. Every word carries weight; it's front-loaded with the action and immediately provides the key warning.

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?

Given the tool's simplicity (one parameter), the description fully covers what the tool does, when to use it carefully, and the main side effect. No gaps remain for an agent to misuse the 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?

The single 'action' parameter is an enum without a description in the schemaudder. The description adds meaning by clarifying what each action does (start, stop, status) and emphasizes the caution around stop, thus compensating fully for low schema coverage.

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 states the tool starts, stops, or checks status of a live stream. It uses a specific verb and resource, and clearly distinguishes from siblings like obs_record_control or obs_output_control by focusing on the broadcast stream.

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 provides clear guidance: use 'status' freely but be deliberate with start/stop due to impact. It doesn't explicitly mention alternatives or when not to use, but the context of 'deliberate' implies caution. Sibling names suggest other control tools, but no explicit comparison is 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?

With no annotations present, the description carries full responsibility for behavioral disclosure. It does this thoroughly: changing studio mode has no viewer-visible effect, it can be enabled mid-broadcast, it affects the operator's OBS window, disabling silently discards the staged preview, and preview requests fail with code 506 while studio mode is off.

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 longer than a minimal tool description, but every sentence earns its place. It is front-loaded with purpose, then explains when to use it, then clearly structures edge cases and traps in a way that is easy for an agent to consume.

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?

Given the simple boolean parameter and no output schema, the description is complete enough for reliable tool use. It not only explains the main operation but also provides critical workflow context about preview deletion, direct cuts, and preview request failures, leaving almost no ambiguity for an autonomous 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?

The schema already fully covers the single parameter: omit to read, true to enable, false to disable. The description adds good behavioral context about consequences, but it does not add much new meaning to the parameter itself, so the high schema coverage baseline of 3 is appropriate.

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 opens with a precise verb and object: 'Read or set whether OBS is in studio mode.' It explains the PREVIEW/PROGRAM distinction and clearly differentiates this tool from scene-switching tools like obs_switch_scene by emphasizing the reviewed path.

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 gives explicit operational guidance: 'If you are going to move scenes automatically, turn this on first.' It also tells the agent when this tool is not sufficient — studio mode does not block direct cuts via obs_switch_scene — and warns about disabling it, including the lost preview and 506 failures.

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?

With no annotations, the description fully carries the behavioral burden. It discloses the studio-mode requirement and error code 506, the asynchronous return before the transition finishes, the inability to override the selected transition, and the preview/program swap trap when called twice in a row. This is exceptionally transparent.

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 front-loaded with the action, uses bold 'TRAPS' structure for readability, and every sentence provides necessary safety or timing guidance. Despite its length, no sentence is wasted, and the numbered trap list makes the critical warnings 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 an irreversible, parameterless, async studio-mode action with no output schema and no annotations, the description covers prerequisites, error conditions, post-call verification timing, transition-selection constraints, and repeated-call behavior. It is fully complete for safe 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?

The tool has zero parameters, so the schema already defines everything; the baseline is 4. The description adds meaningful explanation by explicitly stating that the request 'takes no parameters and cannot override' the transition, reinforcing and explaining why the empty schema is correct.

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 opens with a vivid 'CUT TO AIR' and immediately states the precise action: 'Runs the current transition, taking whatever is in preview to program.' It clearly distinguishes this from direct scene switching by explaining it is the studio-mode equivalent, so the agent knows the resource and effect.

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 gives strong usage context: read obs_preview_scene, view a screenshot before calling, and treat the call as seriously as a direct program switch. It does not explicitly name an alternative tool to use instead, but it clearly frames when this tool applies and what prerequisites exist.

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?

With no annotations provided, the description carries the behavioral transparency burden. It discloses a key trait beyond the schema: the operation never interrupts the stream and viewers just see a camera change. This is valuable, though it omits details like behavior on invalid scene names or error handling.

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