Server Quality Checklist

Tool Scores

• start_streamingC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, yet the description fails to disclose behavioral traits: whether this is idempotent, what happens if already streaming, network requirements, or if it triggers external platform connections. No mention of side effects or return value.

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

  Conciseness3/5

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

  Extremely terse at three words. While not verbose, this level of brevity constitutes under-specification for a state-changing operation rather than effective conciseness. No wasted sentences, but insufficient content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool initiating external broadcast with no output schema and no annotations, the description is incomplete. It omits success/failure indicators, state management details, and interaction with the streaming lifecycle (toggle behavior).

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

  Parameters4/5

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

  Input schema has zero parameters. As per scoring rules, 0 parameters equates to a baseline score of 4.

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

  Purpose3/5

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

  The description states the basic action (Start) and domain (OBS streaming), but barely escapes tautology by adding 'OBS'. It does not explicitly distinguish from sibling 'start_recording' or clarify streaming scope/destination.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance provided on when to use this versus 'start_recording', prerequisites (e.g., scene setup), or when to check status first using 'get_status'. No mention of error conditions.

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

• rename_sceneC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, yet the description fails to disclose mutation side effects: whether references to the scene name are updated throughout the system, uniqueness constraints on 'new_name', or behavior when 'scene_name' does not exist. The agent knows only that a rename occurs, not how it fails or impacts other state.

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

  Conciseness4/5

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

  Extremely efficient at four words with no redundancy. However, given the lack of annotations and behavioral context, this brevity arguably underserves the agent's needs—efficient but potentially insufficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with zero annotations and no output schema, the description lacks critical operational context: success indicators, error conditions, or referential integrity guarantees. It meets only the absolute minimum definition of stating intent.

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

  Parameters3/5

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

  Schema coverage is 100% with both parameters fully self-documented ('Current name', 'New name'). The description adds no validation rules, character limits, or format requirements beyond the schema, warranting the baseline score.

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

  Purpose4/5

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

  States a specific verb (rename) and resource (scene) clearly. The word 'existing' implicitly signals this operates on current assets vs. creating new ones. However, it does not differentiate from sibling 'set_scene' (which likely activates a scene rather than renaming it).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides no guidance on when to use this versus alternatives like 'create_scene' or 'remove_scene', nor prerequisites such as scene existence verification. Offers no 'when-not-to-use' constraints.

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

• set_muteC
  2.9/5.0
  Behavior2/5

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

  No annotations provided, so the description carries the full disclosure burden. It states the core mutation but omits critical behavioral details: whether changes persist across sessions, error conditions if the input_name doesn't exist, idempotency properties, or success indicators.

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

  Conciseness4/5

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

  Extremely concise at four words. While efficient and front-loaded with the action, this brevity is insufficient given the lack of annotations and sibling tool context. However, the sentence structure is direct and contains no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for a simple 2-parameter mutation with complete schema coverage, but leaves significant gaps regarding the relationship to `toggle_mute` and runtime behavior expectations. No output schema exists, but for a boolean setter this is acceptable.

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

  Parameters3/5

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

  With 100% schema description coverage documenting both parameters clearly, the baseline is 3. The description adds minimal semantic value beyond the schema—essentially restating the `muted` parameter's boolean purpose and confirming the resource type as 'audio input' (already implied by the parameter name).

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

  Purpose4/5

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

  The description states a specific action (mute/unmute) on a specific resource (audio input). However, it fails to distinguish from the sibling tool `toggle_mute`, which performs a similar function using a different mechanism (toggling vs. explicit boolean setting).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use `set_mute` versus the sibling `toggle_mute`, or when to prefer this over `set_volume` (setting volume to 0). The schema parameter description references `list_audio_inputs` as a prerequisite, but the main description provides no usage context.

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

• start_recordingB
  3/5.0
  Behavior2/5

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

  No annotations provided, yet description fails to disclose idempotency rules (does it error if already recording?), file output location/format, or side effects. 'Start' implies state mutation but lacks behavioral specifics.

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

  Conciseness5/5

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

  Three words with zero redundancy. Appropriately sized for a no-parameter action command; every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Minimally sufficient for a simple command with no parameters or output schema, but lacks critical details about error conditions and interaction with stop_recording/toggle_recording siblings.

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

  Parameters4/5

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

  Zero parameters present; per guidelines this establishes a baseline of 4. Description appropriately reflects the empty parameter schema.

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

  Purpose3/5

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

  States specific verb (Start) and resource (OBS recording), but fails to distinguish from sibling tool toggle_recording. Doesn't clarify behavior when recording is already active.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides no guidance on when to use this tool versus toggle_recording or start_streaming. No mention of prerequisites like active OBS connection or scene setup.

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

• create_profileB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, the description fails to disclose: whether creation automatically switches to the new profile, what happens if the name already exists (error vs overwrite), or what the return value indicates.

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

  Conciseness5/5

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

  The single sentence is front-loaded with the action ('Create') and contains no redundant words. Given the simplicity of the tool (one required string parameter), this length is appropriate and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter creation tool with no output schema and no annotations, the description is minimally sufficient. However, gaps remain regarding side effects (auto-switching behavior) and collision handling that would comport with the complexity of profile management implied by the sibling tools.

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

  Parameters3/5

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

  Input schema has 100% description coverage ('Name for the new profile'), so the schema fully documents the parameter. The description adds no additional semantic information about constraints, naming rules, or validation, which is acceptable given the baseline of 3 for high schema coverage.

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

  Purpose4/5

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

  The description provides a clear verb ('Create') and resource ('OBS profile') with scope ('new'). It implicitly distinguishes from sibling 'set_profile' through the 'create' vs 'set' verb distinction, though it doesn't explicitly clarify when to choose this over alternatives like renaming existing profiles.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance provided on when to use this tool versus alternatives like 'set_profile' (which switches profiles) or error handling if the profile already exists. The agent must infer usage solely from the verb choice.

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

• save_screenshotB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. While 'current OBS output' clarifies the capture target, critical safety and behavioral details are missing: file overwrite behavior, whether the operation is synchronous, error conditions (invalid paths, disk full), and return value indications.

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

  Conciseness5/5

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

  The single 11-word sentence is efficiently front-loaded with the action and object. There is no redundancy or wasted space; every word serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description adequately covers the core intent but leaves significant gaps regarding success/failure feedback (since return structure is undefined) and file system safety implications inherent to write operations.

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

  Parameters3/5

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

  The input schema has 100% description coverage with clear documentation of the file_path and image_format parameters including defaults and examples. The description provides the baseline context ('to a file') but adds no additional semantic 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.

  Purpose4/5

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

  The description uses a specific verb ('Save') and resource ('screenshot of the current OBS output'), clearly distinguishing this as an image capture operation versus the video recording functions (start_recording, stop_recording) present in siblings. However, it doesn't explicitly clarify the single-frame nature versus continuous recording.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives (e.g., 'use this for single images instead of start_recording for video'), no prerequisites mentioned (OBS must be running), and no caution about file overwrites.

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

• set_source_visibilityB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It fails to indicate that this is an immediate state mutation (not buffered), whether the change affects active recordings/streams, idempotency characteristics, or error conditions (e.g., invalid scene_item_id). The user must infer this is a write operation from the verb 'set' in the tool name.

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

  Conciseness5/5

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

  At seven words, the description is appropriately terse with zero redundancy. It front-loads the action ('Show or hide') immediately followed by the target ('a source'), achieving maximum information density without extraneous phrases.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a three-parameter mutation tool with 100% input schema coverage but no output schema and no annotations, the description provides minimum viable context. However, given the lack of annotations, it should disclose immediate side effects or persistence guarantees to reach completeness.

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

  Parameters3/5

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

  Given 100% schema description coverage where scene_item_id references list_sources and visible explains the boolean mapping (true=show, false=hide), the schema adequately documents parameters. The description adds no semantic clarifications beyond the schema, warranting the baseline score of 3 for high-coverage schemas.

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

  Purpose4/5

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

  The description 'Show or hide a source in a scene' provides a specific verb+resource combination that clarifies the boolean nature of the operation (show vs hide) and scopes it to scene contexts. While it clearly distinguishes from sibling scene-switching tools (set_scene), it could be elevated to a 5 by explicitly differentiating from other source-manipulation operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as obtaining scene_item_id from list_sources (though the schema documents this). There are no warnings about omitting scene_name or behavior when targeting the current program scene.

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

• create_sceneB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full disclosure burden. It adds 'empty' indicating the scene starts without sources, but omits mutation side effects, idempotency behavior (duplicate names), auth requirements, and return value structure.

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

  Conciseness4/5

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

  Extremely concise at 7 words with zero redundancy. However, extreme brevity contributes to under-specification for a mutation tool; one additional sentence covering error cases or sibling distinction would improve utility without harming structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for a single-parameter creation tool with complete schema coverage, but bare minimum. Missing: error behavior for duplicate names, confirmation of return value (void vs object), and relationship to 'set_scene' workflow.

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

  Parameters3/5

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

  Schema coverage is 100% with the parameter 'scene_name' fully described in the schema ('Name for the new scene'). The description provides no additional parameter semantics beyond the schema, warranting the baseline score of 3.

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

  Purpose4/5

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

  The description uses specific verb 'Create' and resource 'scene', and specifies 'empty' and 'OBS' context. However, it does not explicitly distinguish from sibling tools like 'set_scene' (which activates existing scenes) or 'rename_scene'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance provided on when to use this versus siblings like 'set_scene' or error handling if scene name already exists. No prerequisites or workflow context (e.g., 'create before switching') mentioned.

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

• stop_recordingB
  3.2/5.0
  Behavior2/5

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

  With no provided annotations, the description carries the full burden of behavioral disclosure but fails to indicate side effects, idempotency, error conditions (e.g., if called when not recording), or return implications.

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

  Conciseness5/5

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

  The three-word sentence is front-loaded with zero waste, efficiently conveying the tool's function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the basic action is described, the lack of output schema and absence of behavioral details (success/failure states, file saving behavior) leave gaps for a control operation with multiple related siblings.

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

  Parameters4/5

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

  Zero parameters exist, establishing a baseline of 4. The description appropriately requires no additional parameter clarification.

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

  Purpose4/5

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

  The description uses a specific verb ('Stop') and resource ('OBS recording'), clearly distinguishing it from siblings like 'stop_streaming' (different target) and 'start_recording' (opposite action).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this versus siblings like 'toggle_recording' or prerequisites such as requiring an active recording session.

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

• toggle_muteB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. The word 'Toggle' successfully conveys the state-flipping behavior (distinct from setting), but omits other mutation details like side effects, error conditions, or what determines current state.

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

  Conciseness4/5

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

  Extremely concise at 6 words with no filler. Front-loaded with the action verb. However, given zero annotations and the existence of `set_mute`, the brevity underserves the agent's need for behavioral context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for a single-parameter toggle operation with complete schema coverage, but lacks critical sibling differentiation (`set_mute`) and output guidance given no output schema exists. Minimum viable but clear gaps remain.

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

  Parameters3/5

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

  Schema coverage is 100% with the `input_name` parameter fully documented. Description mentions 'audio input' aligning with the schema but adds no additional semantic details (format constraints, validation rules) beyond what the schema already provides.

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

  Purpose4/5

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

  The description uses specific verb 'Toggle' and resource 'audio input', clearly stating the operation. However, it fails to explicitly distinguish from sibling tool `set_mute` (toggle implies flipping state vs setting explicitly), preventing a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Description provides no guidance on when to use this tool versus `set_mute` or prerequisites like calling `list_audio_inputs` first. No contextual usage hints are provided.

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

• create_scene_collectionB
  3.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full disclosure burden. It successfully communicates the initial empty state, but omits other behavioral traits: whether the collection becomes active automatically, what is returned, error conditions (e.g., duplicate names), or persistence guarantees. Adequate but incomplete.

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

  Conciseness5/5

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

  Extremely concise single sentence with verb-first structure. Every word earns its place: 'Create' establishes operation, 'new scene collection' identifies resource, '(starts empty)' provides essential behavioral context without verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Appropriate for low-complexity tool with single well-documented parameter and no output schema. Covers core creation functionality but gaps remain regarding side effects (auto-switching behavior) and success/failure indicators. Sufficient but not comprehensive.

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

  Parameters3/5

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

  Schema coverage is 100% with 'collection_name' fully described in the schema. Description does not add parameter-specific semantics (e.g., naming constraints, uniqueness requirements, max length). Baseline score appropriate given schema completeness.

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

  Purpose4/5

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

  Clear specific verb 'Create' and resource 'scene collection'. The parenthetical '(starts empty)' adds valuable specificity about initial state. Implicitly distinguishes from sibling 'create_scene' by specifying 'collection' and from 'set_scene_collection' by using 'Create' versus 'set', though explicit distinction would strengthen further.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use guidance or comparison to alternatives like 'set_scene_collection'. The 'starts empty' phrase implies post-creation requirements but does not state prerequisites (e.g., name uniqueness) or clarify whether this automatically switches to the new collection versus merely creating it.

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

• set_sceneB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose whether the switch is immediate or deferred, what happens if OBS is not running, or how it affects ongoing recordings/streams.

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

  Conciseness5/5

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

  Single sentence of five words with zero redundancy. Front-loaded with action verb and scope (OBS), earning its place efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Minimally viable for a single-parameter tool with full schema coverage, but gaps remain given lack of annotations and output schema. Could benefit from context about error conditions or state persistence.

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

  Parameters3/5

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

  Schema has 100% description coverage for the single parameter ('Exact name of the scene to switch to'). Description adds no additional param semantics, but baseline 3 applies when schema coverage is complete.

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

  Purpose5/5

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

  Specific verb 'Switch' + resource 'scene' clearly identifies the action. Distinguishes from siblings like 'create_scene', 'remove_scene', and 'list_scenes' which handle CRUD operations rather than activation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance provided on when to use this versus 'set_scene_collection' (which changes the entire scene collection) or how it interacts with active streaming/recording. No mention of prerequisites like requiring the scene to exist.

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

• set_scene_collectionB
  3.3/5.0
  Behavior3/5

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

  Annotations are absent, so description carries full burden. Adds valuable behavioral context with 'OBS will reload its scenes,' indicating a disruptive refresh operation. However, lacks critical safety details like whether unsaved changes are discarded, if the operation is atomic, or required permissions.

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

  Conciseness5/5

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

  Two efficient sentences with zero redundancy. Action and side effect are front-loaded; no filler words. Appropriate density for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for a single-parameter state-change tool, covering the core operation and reload side effect. However, missing error handling behavior (e.g., invalid collection names) and return value description expected for a tool with no output schema and no annotations to provide safety hints.

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

  Parameters3/5

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

  Schema coverage is 100% with the 'collection_name' parameter fully documented. Description contributes minimal additional semantics beyond the schema, though 'different' implies a state change. Baseline 3 appropriate when schema does heavy lifting.

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

  Purpose4/5

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

  Clear verb 'Switch' and resource 'scene collection' identify the operation precisely. Uses specific OBS terminology that implicitly distinguishes from sibling 'set_scene' (which handles individual scenes) and 'set_profile' (which handles OBS profiles), though lacks explicit contrast.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides no guidance on when to use this versus sibling tools like 'set_scene' or prerequisites such as whether streaming/recording must be stopped first. No mention of error conditions or valid states for invocation.

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

• toggle_recordingB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses the toggle behavior (on/off switching) but lacks details on state transitions, idempotency, or side effects (e.g., whether stopping finalizes a file, whether starting creates a new one).

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

  Conciseness5/5

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

  Single sentence with zero redundancy. Action verb front-loaded. Appropriate length for a zero-parameter state toggle.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for basic invocation but incomplete given the sibling tool ecosystem. Missing guidance on toggle-vs-explicit usage patterns and lacks disclosure of what happens to recording files during state transitions.

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

  Parameters4/5

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

  Zero parameters exist in the schema, establishing baseline 4 per rubric. No parameter documentation is required or expected.

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

  Purpose4/5

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

  The description clearly states the action ('Toggle') and resource ('OBS recording'). However, it fails to distinguish from siblings 'start_recording' and 'stop_recording', leaving ambiguity about when to use the toggle pattern versus explicit control.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to prefer this tool over the explicit 'start_recording' or 'stop_recording' alternatives, nor are prerequisites mentioned (e.g., OBS must be running).

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

• list_audio_inputsA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of disclosure. It provides examples of what constitutes an audio input (mics, desktop audio) but fails to mention behavioral traits like read-only safety, caching behavior, response format, or what happens when no inputs are available.

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

  Conciseness5/5

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

  The description is a single efficient sentence with the action and resource front-loaded. The parenthetical examples add value without excessive length, and there is no redundant or wasted language.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (zero parameters, no nested objects) and the absence of an output schema, the description adequately covers the tool's function. While mentioning the return format (e.g., array of device names) would be helpful, it is sufficient for agent selection.

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

  Parameters4/5

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

  Per scoring rules, tools with 0 parameters receive a baseline score of 4. The input schema is empty and the description correctly implies no configuration is needed, requiring no additional parameter semantic clarification.

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

  Purpose4/5

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

  The description provides a specific verb (List) and resource (audio input sources) with concrete examples (mics, desktop audio). However, it does not explicitly differentiate from the sibling tool `list_sources`, leaving some ambiguity about whether this is a filtered view of sources or a distinct system enumeration.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to select this tool versus alternatives. Specifically, it does not clarify when to use `list_audio_inputs` versus the sibling `list_sources`, nor does it mention prerequisites like an active session or streaming state.

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

• list_sourcesA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates the default behavior (current scene), but fails to describe the return structure, what constitutes a 'source' (media types, hierarchy), or error conditions for invalid scene names.

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

  Conciseness5/5

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

  The description consists of two efficient sentences with zero waste. The primary purpose is front-loaded in the first sentence, while the second sentence provides necessary default behavior context without verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a single optional parameter and no output schema, the description is minimally viable but has clear gaps. It fails to clarify the data model relationship between scenes and sources or hint at the return value structure, which is critical given the absence of an output schema.

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

  Parameters3/5

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

  Schema description coverage is 100%, establishing a baseline of 3. The description states 'Defaults to the current scene,' but this merely echoes the schema's description ('Omit to use the current program scene'), adding no new semantic information about the parameter's usage or format.

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

  Purpose4/5

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

  The description clearly states the action ('List') and resource ('sources' defined as 'scene items'), distinguishing it from siblings like 'list_scenes' (which lists scenes) and 'list_audio_inputs' (which lists specific input types). The scope is explicit ('in a scene').

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description mentions that it 'Defaults to the current scene,' implying when to omit the parameter, but lacks explicit guidance on when to use this versus alternatives like 'list_audio_inputs' or prerequisites for specifying a scene name.

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

• set_canvas_resolutionA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses scope impact ('affects all scenes') but omits critical mutation details like effects on active streams/recordings, validation rules, or whether changes are immediate.

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

  Conciseness5/5

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

  Two tightly written sentences with zero waste. Critical information (global scope) is front-loaded in the second sentence. No repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for a 3-parameter configuration tool with complete schema coverage, but gaps remain given no output schema and no annotations. Missing safety warnings appropriate for a global state mutation (e.g., streaming interruption risks).

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

  Parameters3/5

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

  Schema has 100% coverage with clear descriptions. The description adds minimal semantic value beyond the schema, merely grouping width/height as 'canvas' and 'output resolution' without adding format constraints or example usage patterns.

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

  Purpose4/5

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

  Clear verb 'Set' and specific resources 'OBS canvas (base) and output resolution'. The phrase 'Applies globally — affects all scenes' effectively distinguishes this from scene-specific siblings like set_scene or set_source_visibility.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides implicit usage context via 'Applies globally' which signals when to use (global resolution changes), but lacks explicit when-not guidance, prerequisites (e.g., connection state), or named alternatives.

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

• set_volumeA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full disclosure burden. It adds valuable mathematical context ('linear mul') and valid range, but lacks critical behavioral details: whether changes persist across sessions, if they apply immediately to active recordings/streams, or failure modes when 'input_name' is invalid.

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

  Conciseness5/5

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

  Every element earns its place in a single dense sentence: the verb establishes the operation, the parenthetical supplies the precise range and scaling semantics without redundant explanation, and there is no extraneous text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (two primitive parameters with complete schema coverage) and lack of output schema, the description is reasonably complete for invocation. It appropriately delegates specific input requirements to the schema while providing the essential domain context (linear 0.0–1.0 scale).

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

  Parameters4/5

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

  With 100% schema coverage, the baseline is 3. The description adds meaningful semantic value beyond the schema by specifying the 'linear mul' scaling behavior, which clarifies how the numeric value maps to audio gain (as opposed to logarithmic/decibel scaling).

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

  Purpose4/5

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

  The description clearly states the specific action (set) and resource (volume of an audio input), using precise terminology. However, it does not explicitly distinguish this from siblings like 'set_mute' or 'toggle_mute', which control similar but distinct aspects of audio inputs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  While the parenthetical provides valid parameter constraints (0.0–1.0 range), it offers no guidance on when to select this tool versus alternatives like 'set_mute' (silencing) or 'toggle_mute', nor does it mention prerequisites such as verifying the input exists via 'list_audio_inputs'.

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

• stop_streamingA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full disclosure burden but fails to document error states (what happens if called when not streaming?), side effects on recording if active, or success indicators.

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

  Conciseness5/5

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

  The three-word description is appropriately sized for a zero-parameter control command. No redundancy exists and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While adequate for identifying the tool's basic function, the description leaves gaps regarding behavioral specifics (failure modes, state requirements) that would be important given the absence of annotations and output schema documentation.

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

  Parameters4/5

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

  The input schema contains zero parameters. Per rubric, baseline is 4 for parameter-less tools.

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

  Purpose5/5

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

  The description uses a specific verb ('Stop') and clearly identifies the resource ('OBS streaming'). Given siblings like 'stop_recording' and 'start_streaming', it effectively distinguishes this tool's specific scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., only valid when streaming is active) or idempotency concerns.

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

• set_profileA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses what configuration domains get affected (stream settings, encoder config), but omits operational details like whether this interrupts active streams, requires specific OBS states, or confirmation behavior.

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

  Conciseness5/5

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

  Ultra-concise at 11 words. The single sentence is front-loaded with the action verb, and the parenthetical efficiently adds scope context without waste. Every element earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for a single-parameter switching tool with no output schema. The description covers the functional purpose, but given the lack of annotations and the potentially disruptive nature of switching encoder configs mid-stream, it lacks behavioral completeness regarding side effects or safety.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description implies the 'profile_name' parameter by mentioning 'a different OBS profile' but does not add syntax, format constraints, or usage details beyond what the schema already provides.

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

  Purpose5/5

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

  The description uses a specific verb ('Switch') and resource ('OBS profile'), and the parenthetical clarifies what profiles contain ('stream settings, encoder config, etc.'), clearly distinguishing this from sibling scene/source operations like set_scene or set_source_visibility.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The verb 'Switch' and the profile-specific context implicitly guide usage, but there is no explicit guidance on when to use this versus create_profile or list_profiles, nor any prerequisites mentioned (e.g., whether the profile must exist).

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

• get_statusA
  4/5.0
  Behavior3/5

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

  With no annotations provided, description must carry full behavioral burden. 'Get' implies read-only operation, establishing safety profile. However, lacks disclosure of return format/types (booleans vs strings), potential error states, or caching behavior. Meets minimum expectations but provides no additional behavioral context beyond the implied read-only nature.

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

  Conciseness5/5

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

  Single sentence, nine words. Action-verb front-loaded with colon-separated enumeration of status components. No redundancy, tautology, or filler. Every word contributes essential information about tool capability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless status retrieval tool without output schema, description adequately covers functional scope by enumerating the three specific status components returned. Could be improved by hinting at return structure or value types (e.g., boolean for states), but sufficient given low complexity.

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

  Parameters4/5

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

  Input schema contains zero parameters. Per scoring guidelines, zero-parameter tools receive baseline score of 4. Description appropriately makes no parameter claims, requiring no semantic clarification beyond what the empty schema already conveys.

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

  Purpose5/5

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

  Excellent specificity: verb 'Get' + resource 'OBS status' + explicit scope enumeration ('active scene, streaming state, recording state'). Effectively distinguishes from action-oriented siblings like start_streaming/stop_recording and from list-oriented siblings like list_scenes by emphasizing current/active state retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use guidance or alternative recommendations provided. However, the enumeration of returned status fields implicitly signals this is for monitoring current state vs. the mutation tools (set_scene, start_streaming). Adequate but lacks explicit guidance.

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

• list_profilesA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full disclosure burden. It adds valuable behavioral context by specifying the tool reveals active/inactive status, but omits other behavioral traits like error conditions, caching behavior, or response structure.

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

  Conciseness5/5

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

  Single 11-word sentence with zero redundancy. Immediately establishes resource (profiles), action (list), and key differentiator (active status) with optimal front-loading.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Appropriately complete for a zero-parameter read operation. The mention of 'active' status covers the essential behavioral output despite absence of output schema.

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

  Parameters4/5

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

  Zero parameters present in schema, which per guidelines establishes a baseline score of 4. Description appropriately requires no parameter explanation.

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

  Purpose5/5

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

  Description uses specific verb 'List' with resource 'OBS profiles' and adds distinguishing scope 'show which one is active,' clearly differentiating from sibling mutation tools (set_profile, create_profile, remove_profile).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative recommendations provided. Usage is only implied by the read-only verb 'List' contrasting with siblings using action verbs (set, create, remove).

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

• list_scene_collectionsA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses one key behavioral trait (identifies the active collection) but does not mention read-only safety guarantees, error cases, or return format details that would help the agent understand execution constraints.

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

  Conciseness5/5

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

  Eleven words with zero waste. Front-loaded with the action verb, includes essential scope (all), and ends with the critical differentiator (active status). Every clause earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given zero parameters and no output schema, the description adequately covers the tool's core behavior. However, it omits the return structure/format which would help the agent understand what data it receives back.

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

  Parameters4/5

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

  The input schema contains zero parameters, which establishes a baseline score of 4. The description appropriately does not invent parameters.

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

  Purpose5/5

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

  The description uses a specific verb 'List' with clear resource 'scene collections' and adds scope 'all'. It distinguishes effectively from siblings like create_scene_collection and set_scene_collection by specifying this is a retrieval/listing operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'show which one is active' provides implied usage context (use when you need to identify the current active collection), but lacks explicit when/when-not guidance or named alternatives.

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

• list_scenesA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. 'List' implies read-only safety, but description omits return format, pagination, or OBS-specific scope (current scene collection vs all).

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

  Conciseness5/5

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

  Single 6-word sentence with zero waste. Purpose front-loaded immediately.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for 0-param complexity despite lacking output schema. Could briefly note relationship to set_scene or scene collections, but sufficient for tool selection.

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

  Parameters4/5

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

  Zero parameters per input schema with 100% coverage; baseline score applies as no parameter documentation is required.

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

  Purpose5/5

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

  Clear specific verb 'List' + resource 'scenes' + context 'in OBS'. Distinct from siblings create_scene, remove_scene, rename_scene, and set_scene through verb choice.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides implied usage through read operation verb distinguishing from write siblings (create/remove/set), but lacks explicit when-to-use guidance or relationship to set_scene workflow.

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

• remove_profileA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full disclosure burden. It usefully reveals the active-profile constraint (behavioral limitation), but omits other critical destructive-operation details: whether deletion is permanent, error behavior if constraint is violated, or impact on associated scene collections.

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

  Conciseness5/5

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

  Two sentences, zero waste. Purpose front-loaded in first sentence; constraint follows immediately. Appropriate density for a single-parameter destructive operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for low complexity (1 param, flat schema, no output). The active-profile constraint captures the primary business logic gotcha. Missing output/error details but acceptable given simple domain and 100% schema coverage.

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

  Parameters3/5

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

  Schema has 100% coverage (profile_name fully described). With schema doing the heavy lifting, baseline is 3. Description adds implicit validation rule (cannot be active profile) but doesn't add syntax/format details beyond schema.

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

  Purpose5/5

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

  Clear specific verb ('Delete') + resource ('OBS profile') combination. Effectively distinguishes from siblings: vs create_profile (creates), vs set_profile (switches), vs list_profiles (reads). The scope is immediately obvious.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit critical constraint 'Cannot remove the currently active profile' which functions as a when-not-to-use guardrail. Lacks explicit mention of alternatives (e.g., 'use set_profile to switch first') or positive 'when to use' guidance, preventing a 5.

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

• remove_sceneA
  4/5.0
  Behavior3/5

  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 the critical behavioral constraint regarding active scenes and implies destructiveness via 'Delete', but lacks other behavioral details like error modes, side effects on contained sources, or reversibility.

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

  Conciseness5/5

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

  Extremely concise with two efficient sentences. The first states the action, the second states the critical constraint. No filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple single-parameter operation and lack of output schema, the description is appropriately complete. It covers the essential functional constraint. Could be improved by mentioning error behavior if the scene doesn't exist, but adequate for the complexity level.

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

  Parameters3/5

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

  Schema description coverage is 100% ('Name of the scene to delete'), establishing baseline 3. The description implies the parameter's purpose by stating the action but does not add semantic details beyond what the schema already provides.

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

  Purpose5/5

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

  The description states a specific verb ('Delete'), resource ('scene'), and context ('OBS'). It effectively distinguishes from sibling tools like 'set_scene' or 'rename_scene' by including the unique constraint about the currently active scene.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides a clear when-not constraint ('Cannot remove the currently active scene'), which guides the agent away from error conditions. However, it does not explicitly name the alternative workflow (e.g., 'use set_scene first to switch away').

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